1

我们正在重新设计一个脱节的实时 OPC 系统，该系统已被证明很麻烦。我们的技术堆栈是 C#、.NET 4 和 SQL Server 2008 R2，托管在 32 位 Windows Server 2003 上。物理架构目前规定所有层都托管在单个服务器上，尽管有足够的动力（阅读：ROI）这可能增加到2。

现有的基本架构是：

  • 外部 OPC 设备调用我们的 Web 服务以使用实时数据填充 SQL，大约每秒 300 个事件。我们在这里无法控制容量或批处理，尽管在重写时我想在 Web 服务中实现批处理，以使 SQL 免受每秒 300 个插入语句的影响。
  • SQL 被用作执行从警报到报告的任务的各种组件（总共大约 9 个，全部重新设计）的中心资源。这是目前现有设计的最大问题，因为所有这些组件都没有通过单个 BLL 甚至 DAL 来消费/操作数据或管理行为。
  • 组件范围从 Windows 服务到 Web 服务再到 Windows 应用程序。CPU 时间和 SQL 连接的最大消耗者是一个 Windows 窗体应用程序，它监视所有实时数据并根据需要发出警报。它还可以生成实时趋势图，运行起来非常昂贵。

对于重写，对 WPF 的推动力很大，除了学习曲线之外，我没有任何问题。我的问题更关心底层架构：

  • 我目前正在研究如何实现单个 DAL 和 BLL。对于 DAL，我倾向于 EF 或 nHibernate，Linq-to-SQL 也是一种可能。
  • 对于 BLL，我只有 CSLA.NET 方面的经验，我担心这对于速度和资源消耗至关重要的系统来说可能有点过头了。

是否有人对类似系统有任何经验，并愿意分享一些经验教训或设计指南？

4

2 回答 2

1

我有一些从 OPC 服务器获取数据的经验，尽管我相信我实现的应用程序没有你的规模那么大。对于我的应用程序，我有一个基于发布 - 订阅架构的消息传递层，根据我的经验，我的建议是

1) 对于您的实时数据采集，您需要基于发布-订阅机制的东西，Biz talk server 是微软对 ESB 的回答。所以我会看看这个。
2) 您的 Windows 窗体应用程序是否需要直接查看数据库？我的意思是它是否可以查看一个中间件，可以说查看数据库以用于历史目的，或者如果它只关心实时信息，则可以订阅实时提要

于 2011-04-12T13:39:00.907 回答
0

我不确定我是否喜欢将 SQL 服务器作为系统中心点的想法。该服务器将受到重创 - 每次设备上的数据更改时，它都会写入数据库。然后，每个客户端都会以恒定的速率不断刷新，以检测是否有任何变化。这将是 SQL 服务器的大量工作。

OPC 协议涉及订阅服务器的客户端，因此可以在任何数据更改时通知他们。在中间使用 SQL 可以防止这种情况。

使用/创建一个 OPC 服务器从设备中检索所有数据，然后允许每个客户端连接到该服务器不是更好吗？这样他们只会在数据发生变化时接收数据，而不必不断检查更新？

如果您出于历史原因需要记录，您总是可以创建一个额外的客户端，然后将数据记录到 SQL 数据库中。

于 2011-04-12T13:39:25.197 回答