Межпроцессный обмен сообщениями - MSMQ, Service Broker?

Question

Я нахожусь на стадии планирования службы .NET, которая постоянно обрабатывает входящие сообщения, что включает в себя различные преобразования, вставки и обновления базы данных и т. Д. В целом, служба огромна и сложна, но отдельные задачи, которые она выполняет маленькие, простые и четкие.

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

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

Я всегда использовал очереди сообщений для такого типа вещей, но недавно мне стало известно о SQL Service Broker, который, похоже, делает нечто подобное. Является ли SQLSB жизнеспособной альтернативой для этого сценария, и если да, я бы увидел какие-либо преимущества в производительности, если использовать его вместо стандартной очереди сообщений?

Спасибо

Answer 1

Это звучит так, как будто вы можете быть после архитектуры служебной шины.Это обеспечит вам необходимую координацию и отказоустойчивость.Я наиболее знаком и неравнодушен к NServiceBus, но есть и другие, включая Mass Transit и Rhino Service Bus.

Answer 2

Если большинство этих шагов начинаются из состояния базы данных и заканчиваются обновлением базы данных, то объединение хранилища сообщений с хранилищем данных имеет большой смысл:

• один продукт для резервного копирования / восстановления
• резервных копий в согласованном состоянии
• единое решение высокой доступности / восстановления после сбоев (зеркалирование БД, кластеризация, доставка журналов и т. Д.)
• хранилище масштаба базы данных (возможности ввода-вывода, ограничения размера и емкости и т. Д. В соответствии с характеристиками продукта базы данных, а не с ограничениями продуктов хранилища сообщений).
• один продукт для настройки, устранения неполадок, администрирования

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

Кроме того, использование хранилища сообщений в базе данных по сравнению с внешним хранилищем имеет такие преимущества, как возможность запроса (запуск SELECT по очередям сообщений).

Теперь, если мы переведем абстрактные термины «хранилище сообщений в базе данных как сервис-брокер», а «хранилище сообщений не в базе данных» как MSMQ, вы поймете, почему SSB в любой момент будет обходить MSMQ.

Answer 3

Мой недавний опыт использования обоих подходов (начиная с Sql Server Service Broker) привел меня к ситуации, в которой я плачу за получение сообщений от SQL-сервера.Проблема квазиполитическая, но вы, возможно, захотите рассмотреть ее: SQL-сервер в моей организации управляется специализированным администратором баз данных, а серверы приложений (например, обмен сообщениями, такие как NServiceBus) - разработчиками и сетевой командой.Любые изменения в серверах баз данных требуют тщательного анализа производительности от администратора базы данных и погружены в страх, что мы можем снизить стандартные обязанности SQL с помощью нашего механизма очередей, живущего в одном и том же пространстве.

Управлять SSSB довольно сложно (в отличие от обмена сообщениями)промежуточное программное обеспечение), но разница в том, что мне больше позволено что-то испортить в мире обмена сообщениями (самое худшее, что может случиться, это когда-то накапливается куча сообщений и заполнение журналов), и я не могу позволить себе никаких ошибок в мире SQLгде данные о транзакциях клиента живут и имеют жизненно важное значение для бизнеса (включая данные из устаревших систем).Я действительно не хочу больше получать эти «неожиданный рост базы данных» или «предупреждение о времени ожидания» или «почему мои временные базы данных растут без конца».

Я узнал, что серверы приложений дешевы.Просто добавьте обработчики сообщений, добавьте машины ... просто.Практически нет лицензионных расходов.С SQL-сервером все наоборот.Теперь мне кажется, что использование Service Broker для обмена сообщениями похоже на использование дорогой машины для вспашки картофельного поля.Это намного лучше для других вещей.