#c# #.net #architecture #real-time #business-logic-layer
#c# #.net #архитектура #в режиме реального времени #уровень бизнес-логики
Вопрос:
Мы находимся в процессе редизайна разрозненной OPC-системы реального времени, которая оказалась громоздкой. Наш технологический стек — это C #, .NET 4 и SQL Server 2008 R2, размещенный на 32-разрядной версии Windows Server 2003. Физическая архитектура в настоящее время диктует, что все уровни должны размещаться на одном сервере, хотя при достаточной мотивации (читай: рентабельности инвестиций) это может быть увеличено до 2.
Базовая существующая архитектура является:
- Внешние OPC-устройства вызывают наш веб-сервис для заполнения SQL данными в реальном времени, примерно 300 событий в секунду. Здесь у нас нет контроля над объемом или пакетной обработкой, хотя при перезаписи я хотел бы реализовать пакетную обработку в веб-службе, чтобы избавить SQL от 300 инструкций insert в секунду.
- SQL используется в качестве центрального ресурса для различных компонентов (всего около 9, все будут переработаны), которые выполняют задачи, начиная от аварийных сигналов и заканчивая отчетностью. В настоящее время это самая большая проблема с существующим дизайном, поскольку нет единого BLL или даже DAL, через который все эти компоненты потребляют / манипулируют данными или управляют поведением.
- Компоненты варьируются от служб Windows до веб-служб и приложений Windows. Крупнейшим потребителем процессорного времени и подключений к SQL является приложение Windows Forms, которое отслеживает все данные в реальном времени и выдает сигналы тревоги по мере необходимости. Он также создает графики тенденций в реальном времени, что довольно дорого для запуска.
При перезаписи наблюдается сильный толчок в сторону WPF, с которым, помимо кривой обучения, у меня нет проблем. Мой вопрос больше касается базовой архитектуры:
- В настоящее время я провожу некоторые исследования о том, как реализовать единый DAL и BLL. Для DAL я склоняюсь к EF или NHibernate, с возможностью Linq-to-SQL.
- Для BLL у меня есть опыт только в CSLA.NET и я боюсь, что это может быть немного чрезмерно для системы, в которой скорость и потребление ресурсов имеют решающее значение.
Есть ли у кого-нибудь опыт работы с подобной системой, и готовы ли они поделиться несколькими уроками или рекомендациями по проектированию?
Комментарии:
1. Если я правильно понимаю, у вас много программных приложений Microsoft, все базы данных которых размещены на одном сервере Microsoft SQL Server, система становится «капризной». Я бы увидел реализацию ESB поверх всего, даже если у вас есть только одна технология. Это помогло бы вам лучше распределять данные между приложениями, но теперь есть способ заставить это работать без дополнительных экземпляров SQL Server и по крайней мере двух серверных машин. Отчетность должна выполняться на складе, разумном для вашего случая, другие приложения должны быть расставлены по приоритетам и организованы в зависимости от их уровня «реального времени».
2. @Catalin: Не просто один сервер — единая база данных, а в некоторых случаях и единая таблица. Это будет должным образом переработано при перезаписи.
3. В настоящее время я работаю над переписыванием старого программного обеспечения с рабочего стола на веб, с Delphi на PHP. Бизнес на 100% обрабатывается хранимыми процедурами. Если бы вы могли дать мне некоторые подробности относительно приложений, которые у вас есть в настоящее время, и их использования, я мог бы помочь.
4. вы ознакомились с существующим SDK для OPC UA?
Ответ №1:
У меня есть некоторый опыт получения данных с OPC-серверов, хотя приложения, которые я реализовал, я полагаю, были не такими масштабными, как ваши. Для моего приложения у меня был уровень обмена сообщениями на основе архитектуры публикации и подписки, мое предложение, основанное на моем опыте, тогда было бы
1) Для сбора данных в реальном времени вам понадобится что-то, основанное на механизме публикации — подписки, Biz talk server — это ответ Microsoft на ESB. Итак, я бы посмотрел на это.
2) Нужно ли вашему приложению Windows forms напрямую обращаться к базе данных? Я имею в виду, может ли он взглянуть на промежуточное звено, которое может, скажем, просмотреть базу данных для исторических целей или подписаться на канал в режиме реального времени, если все, что его волнует, — это информация в режиме реального времени
Комментарии:
1. Сервер Biztalk, вероятно, немного перегибает палку, не обращая внимания на финансовые последствия. Однако мы разрабатываем решение для публикации / подписки, возможно, используя pubsub.codeplex.com .
Ответ №2:
Я не уверен, что мне нравится идея использования SQL Server в качестве центральной точки в системе. этот сервер будет перегружен — каждый раз, когда данные изменяются на устройстве, он будет записывать данные в базу данных. Затем каждый клиент будет постоянно обновляться с постоянной скоростью, чтобы определить, есть ли какие-либо изменения. это будет большая работа для SQL server.
Протокол OPC предполагает, что клиенты подписываются на сервер, поэтому они могут получать уведомления об изменении любых данных. Использование SQL в середине предотвращает это.
Не было бы намного лучше использовать / создать OPC-сервер для извлечения всех данных с устройства, а затем разрешить каждому клиенту подключаться к этому? Таким образом, они получают данные только при их изменении, вместо того, чтобы постоянно проверять наличие обновлений?
Если вам нужно вести журнал по историческим причинам, вы всегда можете создать дополнительный клиент, который затем записывает данные в базу данных SQL.