实时OPC系统的设计考虑
我们正在重新设计一个脱节的实时 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 方面的经验，我担心这对于速度和资源消耗至关重要的系统来说可能有点过分了。
有没有人有类似系统的经验，并愿意分享一些经验教训或设计指南？
We are in the process of redesigning a disjointed realtime OPC system which has proven to be cumbersome. Our technology stack is C#, .NET 4 and SQL Server 2008 R2, hosted on 32 bit Windows Server 2003. Physical archtecture currently dictates that all tiers are to be hosted on a single server, although with sufficient motivation (read: ROI) this could be increased to 2.
The basic existing architecture is:
- External OPC devices call our webservice to populate SQL with realtime data, approxomately 300 events per second. We have no control over volume or batch processing here, although in the rewrite I would like to implement batching in the web service to spare SQL from 300 insert statements per second.
- SQL is used as a central resource for various components (about 9 in total, all to be redesigned) that perform tasks ranging from alarms to reporting. This is currently the biggest problem with the existing design, in that there is no single BLL or even DAL through which all these components consume/manipulate data or govern behavior.
- Components range from Windows Services to Web Services to Windows Applications. The biggest consumer of CPU time and SQL connections is a Windows Forms application that monitors all realtime data and raises alarms as required. It also does realtime trend graphs, which is quite expensive to run.
For the rewrite there is a strong push towards WPF with which, apart from the learning curve, I have no problem. My question is more concerned with the underlying architecture:
- I am currently doing some research on how to implement a single DAL and BLL. For the DAL I am leaning towards EF or nHibernate, with Linq-to-SQL also a possibility.
- For the BLL I only have experience in CSLA.NET, and I fear this may be a bit over the top for a system in which speed and resource consumption is crucial.
Does anybody have any experience with a similiar system, and are willing to share a few lessons or design guidelines?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对从 OPC 服务器获取数据有一定的了解，尽管我认为我实现的应用程序规模没有您的那么大。对于我的应用程序，我有一个基于发布-订阅架构的消息传递层，根据我的经验，我的建议是：
1）对于实时数据采集，您需要基于发布-订阅机制的东西，Biz talk 服务器是微软的答案到 ESB。所以我会看看这个。
2）您的Windows窗体应用程序是否需要直接查看数据库？我的意思是，它是否可以查看一个中间体，该中间体可以出于历史目的查看数据库，或者如果它关心的是实时信息，则可以订阅实时提要
I have some exposure to acquiring data from OPC servers, though the applications I implemented I believe were not as large scale as yours. For my application I had a publish - subscribe architecture based messaging layer, my suggestion based on my experience then would be
1) For your real time data acquisition you would need something based on a publish - subscribe mechanism, Biz talk server is the microsoft answer to ESB. So I would look at this.
2) Does your windows forms application need to look at the database directly ? I mean can it look at an intermediate that can say look at the db for historical purposes or subscribe to the real time feed if all it cares is real time information
我不确定我是否喜欢将 SQL 服务器作为系统中心点的想法。该服务器将受到重创 - 每次设备上的数据发生更改时，它都会写入数据库。然后每个客户端都会以恒定的速率不断刷新以检测是否有任何变化。这对于 SQL 服务器来说将是大量的工作。
OPC 协议涉及客户端订阅服务器，因此可以在任何数据更改时通知它们。在中间使用 SQL 可以防止这种情况发生。
使用/创建 OPC 服务器从设备检索所有数据，然后允许每个客户端连接到该服务器不是更好吗？这样他们只在数据发生变化时接收数据，而不必不断检查更新？
如果由于历史原因需要记录，您始终可以创建一个额外的客户端，然后将数据记录到 SQL 数据库。
Im not sure I like the idea of having an SQL server as a central point in the system. this server is going to get hammered - every time data changes on a device, it will write to the database. Every client will then continually refresh at a constant rate to detect if there are any changes. this is going to be a lot of work for the SQL server.
The OPC protocol involves clients subscribing to a server, so they can then be notified on change of any data. Using SQL in the middle prevents this.
Would you not be far better off using/creating an OPC server to retrieve all data from the device, then allowing each client to connect to this? That way they are only recieving data when it changes, rather than having to constantly check for updates?
If you need to log for historical reasons, you can always make an extra client which then logs the data to an SQL database.