实时OPC系统的设计考虑因素

Question

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

现有的基本架构是：

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

对于重写，强烈推动WPF，除了学习曲线之外，我没有问题。我的问题更关注底层架构：

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

是否有人有类似系统的经验，并愿意分享一些课程或设计指南？

Answer 1

我有一些从OPC服务器获取数据的风险，虽然我认为我实施的应用程序并不像你那么大。对于我的应用程序，我有一个基于发布 - 订阅架构的消息传递层，根据我的经验，我的建议是

1）对于实时数据采集，您需要基于发布 - 订阅机制的东西，Biz talk服务器是ESB的微软答案。所以我会看看这个。
2）你的windows表单应用程序需要直接查看数据库吗？我的意思是它可以看一个中间体，可以说看看数据库是出于历史目的还是订阅实时数据，如果所有它关心的是实时信息

Answer 2

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

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

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

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