实时OPC系统的设计考虑

Question

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

现有的基本架构是：

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

对于重写，有一个强大的推动WPF，与此，除了学习曲线，我没有问题。我的问题更关心的是底层架构：

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

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

Answer 1

我对从OPC服务器获取数据有一些了解，尽管我所实现的应用程序没有您的大。对于我的应用程序，我有一个基于发布-订阅架构的消息层，根据我当时的经验，我的建议是

1)对于您的实时数据采集，您需要基于发布-订阅机制的东西，Biz服务器是microsoft对ESB的回答。所以我会看看这个。

2) windows窗体应用程序是否需要直接查看数据库？我的意思是，如果它只关心实时信息的话，它是否可以查看一个中间程序，比如为历史目的查看数据库，或者订阅实时提要？

Answer 2

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

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

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

如果由于历史原因需要进行日志记录，则始终可以创建一个额外的客户端，然后将数据记录到SQL数据库。