Разделение MSMQ путем отправки сообщений через службу WCF

Я как раз заканчиваю огромный проект для компании, в которой я работаю, похожую на вашу.

Он полагается исключительно на WCF, использующий NetTcpBinding и сохраняющий всю информацию в базе данных Sql Server.

Основная служба WCF отвечает за сохранение информации в базе данных. Другие службы wcf возвращают данные клиентам, которые в них нуждаются (32-дюймовый сенсорный экран, висящий на стене, настольные гаджеты, смартфоны).

Существует общая библиотека, содержащая определения контрактов и все связанные с клиентом вещи, которые используются всеми приложениями здесь (10+). Все эти приложения регистрируют все, что связано со службой wcf (всегда в асинхронных операциях): исключения, предупреждения, тактовые импульсы, даже отладочную информацию. Количество клиентов здесь невелико, это порядка 60 компьютеров, на которых одновременно работают 1 или 2 приложения.

Панель управления - это приложение WPF, которое постоянно связывается со службой wcf, чтобы узнать, есть ли обновления в зависимости от приоритета, а затем отображать их в красивом пользовательском интерфейсе.

Между более чем 60 клиентами у нас есть 15 RTU, которые отправляют температуру (ºC) и давление (бар) в трубопроводах природного газа из 3 разных городов на один и тот же сервер, эта информация принимается службой Windows через Tcp, а затем отправляется в службу wcf. (на том же сервере). Все эти данные критичны !! У нас даже есть еще одна служба Windows, которая постоянно запрашивает службу wcf, чтобы найти важные события и отправить SMS людям, связанным с этим типом событий.

Ууууу, IMO wcf - отличная технология для достижения ваших целей!

Если вы хотите избежать тесной связи с MSMQ, я бы предложил использовать что-то вроде самодельной абстракции шины, которая принимает сообщение и затем отправляет его в MSMQ любым способом, которым вы хотите это сделать. Таким образом, вы всегда можете подключить другую реализацию, которая использует все, что вы хотите (RabbitMQ, некоторая прямая сохраняемость db или что-то еще, о чем вы можете подумать). В противном случае лично я бы постарался сделать обработку сообщений как можно менее затратной и короткой. Вы также можете прочитать статьи о производительности msmq, например, этой.

Невозможно полностью изолировать себя от последствий выбора технологии, и в какой-то момент, пытаясь сделать это, вы получите убывающую отдачу.

Я знаю, что всех нас учат избегать спаривания любой ценой, как будто это какая-то болезнь, но одно из преимуществ использования WCF в первую очередь заключается в том, что вы не жестко привязаны к конкретному транспорту. Вы можете заменить MSMQ на TCP только с изменениями конфигурации.

Как предполагает @nieve, создавая абстракцию, вы действительно отделяете себя от деталей реализации, в данном случае от WCF. Тем не менее, лучше ли связать себя с представлением абстрактной шины? Вы можете получить меньше "сцепления", но, возможно, за счет большей запутывания.

Вызов MSMQ через WCF имеет то преимущество, что это небольшой объем кода, и его могут легко подхватить другие разработчики с почти нулевыми накладными расходами на анализ. Я бы робко предположил, что вы, возможно, чрезмерно изобретаете решение проблемы, которой на самом деле не существует.

Подумайте о разработчиках, которые начнут работать над вашим проектом, скажем, через 12 месяцев. Вы хотите создать систему, в которой они не будут тратить первые два месяца на ее изучение, прежде чем они смогут стать продуктивными. Использование знакомых фреймворков, которые были разработаны, чтобы в какой-то степени вас развязать, может в некоторой степени помочь в достижении этого.

В моих тестах WCF и NetTcpBinding работают довольно быстро (‹1 мсек и обратно).
Используя async, вы избегаете блокировки приложения при сбое некоторых соединений.
AsyncWcfLib может помочь повысить уровень абстракции.