0

业务场景：

想象一下有Construction。施工可以是新建筑、桥梁等。施工场地上可能会发生各种物理和环境变化。这些变化可能是例如温度变化。

我们为我们的客户构建了应用程序，该应用程序从施工场收集不同类型的数据，然后用于：

  1. 显示时间变化图表
  2. 为施工经理和其他决策者提供见解、警报和通知

当前状态：

应用程序已构建并正在运行。

  1. 广告。1 - 收集所有数据并使用图表进行可视化
  2. 广告。2 -我们仍在为这个模块的正确设计而绞尽脑汁

问题：

如何正确设计使用 WCF 服务和套接字进程收集数据的异常数据通知模块？

整体架构设计：

架构设计

我们的难题有 4 个主要部分：

  1. 后端数据库 - SQL Server 2008 (Azure SQL)
  2. 前端 Web 应用程序 - ASP.NET MVC 3（Azure 的 WebRole）。
  3. 由向我们发送数据的 ZigBee 设备调用的 WCF 4.0 服务（Azure 的 WebRole）。
  4. Windows 进程使用 Socket IP（用于 Azure 的 WorkerRole）以配置的频率调用 Rfid 读取器。

在数据库中，我们有 2 个单独的表格用于 Rfid 读数和 ZigBee 读数。为了性能，存储结果的表被刻意去规范化：通过多个索引进行更快的查询和分组。我们在前端应用程序中使用 Entity Framework 和带有 Projection 的 Linq 进行数据访问，它运行良好。

异常数据通知模块：

我们的通知模块功能要求是：

  1. 在以下情况下，向特定施工场地的通知订阅者发送短信和电子邮件：
  2. 测量数据的值高于阈值 x 出现次数
  3. 参数有：最小值、最大值、阈值、重复次数、重复时间窗口、传感器类型

例如，我们为特定的施工场地添加了通知/警报。此警报已配置：

  • 最小值 = -5
  • 最大值 = 40
  • 阈值 = 5
  • 重复次数 = 5
  • 重复时间窗口 = 5min
  • 传感器类型 = 温度

所以现在当 ZigBee WCF 或 Rfid Windows Process 获取数据时，可以触发通知/警报。例如：

  • 日期：2012-08-19 10:00 值：30 OK
  • 日期：2012-08-19 10:01 值：28 OK
  • 日期：2012-08-19 10:02 值：40 OK（仍低于 Max + Threshold）
  • 日期：2012-08-19 10:03 值：41 OK（仍低于 Max + Threshold）
  • 日期：2012-08-19 10:04 值：39 OK
  • 日期：2012-08-19 10:05 值：46 OK（高于阈值，重复计数 1）
  • 日期：2012-08-19 10:06 值：39 OK
  • 日期：2012-08-19 10:07 值：38 OK
  • 日期：2012-08-19 10:08 值：39 OK
  • 日期：2012-08-19 10:09 值：38 OK
  • 日期：2012-08-19 10:10 值：39 OK
  • 日期：2012-08-19 10:11 值：38 OK（上次异常发生 > 重复时间窗口，重复计数 0）
  • 日期：2012-08-19 10:12 值：41 OK（仍低于 Max + Threshold）
  • 日期：2012-08-19 10:13 值：46 OK（高于阈值，重复计数 1）
  • 日期：2012-08-19 10:14 值：47 OK（高于阈值，重复计数 2）
  • 日期：2012-08-19 10:15 值：46 OK（高于阈值，重复计数 3）
  • 日期：2012-08-19 10:16 值：47 OK（高于阈值，重复计数 4）
  • 日期：2012-08-19 10:17 值：46 OK（高于阈值，重复计数 5）-> ALERT！

架构设计要求：

所有逻辑都必须在业务层内，这意味着我们不能使用存储过程和触发器

可能的解决方案1：

我们的第一个想法是为 ZigBee 和 Rfid 服务附加模块逻辑，但这可能会导致性能堵塞。如果我们调用 DB 最后检查 Service 的每个请求，我们会生成大量计算事务，这些事务甚至可能以死锁结束。我们可以在这里使用 WCF 队列机制，但是我们仍然看不到任何可以解决此问题的好处。

对此解决方案的任何建议表示赞赏。

可能的解决方案2：

第二个想法是部署另一个 Windows 进程，该进程将在后台以配置的频率扫描数据库，如果发生“高于阈值”，则将此信息保存到单独的“缓存”表中，并在数据库中“标记”已检查特定的该行通知/警报。所以以后它不会被添加到扫描中。

这意味着：

  1. 另一个“缓存”表
  2. 我们将“扫描仪”配置为 30 分钟频率的传递通知/警报的延迟
  3. 为“特定通知”“标记”行的某种方式，我们不能简单地添加 Bool 标志，因为许多定义的通知可能会计算 1 行的读数（建筑场的 3-4 个通知）
  4. 有多少“流程”、“后台工作人员”应该同时工作？与现有通知配置相同，或者所有通知配置一个，使用堆栈？

对此解决方案的任何建议表示赞赏。

结论：

如果您有任何想法、经验、了解现有解决方案 (dll)、处理此类问题的模式并与我们分享，我们将不胜感激。

4

2 回答 2

0

您应该Topics在Windows Azure Service Bus中查看其他解决方案。由于您实际上是在谈论来自传感器/设备的数据，我建议您阅读 Clemens Vasters 在 MSDN 杂志中的文章：使用 Windows Azure 服务总线处理……事物！

在此处输入图像描述

开，您正在谈论在数据库中存储非规范化。为什么不使用表存储呢？

于 2012-08-19T20:01:38.780 回答
0

你说“如果你有任何想法”，那么就到这里吧。希望不会离题。。

从图表和描述看来，每个应用程序/数据接收器都直接写入数据库。如果您将数据库放在接收器推送数据并通过前端发送警报规范的专用应用程序后面，您可以在将数据保存到数据库时实时更新警报信息。也就是说，您将存储每个警报的状态，并在新的“有趣”值出现时进行更新。这样您就不必标记数据。这是不断更新的警报。当最终触发警报时，您会启动一些异步进程以发送该警报的通知。

这类似于 sagas 使用消息传递的想法。

于 2012-08-19T20:58:00.450 回答