NServiceBus Опубликовать / подписаться

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

Мы изучали проект NServiceBus и задавались вопросом, будет ли он соответствовать нашим требованиям, глядя на образец PubSub (http://docs.particular.net/samples/pubsub/) мы заметили, что он не помог решить следующие два сценария:

  1. Все издатели публикуют сообщения одного и того же типа.
  2. Подписчик не должен требовать знания конечных точек издателя.

Нам удалось выполнить эти требования, но мы не уверены в правильности конфигурации. Вот наши решения:

  1. Все издатели используют одну и ту же конфигурацию хранилища подписки (DBSubscriptionStorage), которая является общей базой данных, как описано в разделе «Хранилище подписки» документации http://docs.particular.net/nservicebus/messaging/publish-subscribe/

  2. Все издатели / подписчики настроены на использование дистрибьютора, как описано в документации на веб-сайте nservicebus.

Мы хотели бы знать, является ли это правильной реализацией модели публикации / подписки NServiceBus или может быть другое решение, которое достигнет наших целей?


person Matt    schedule 08.06.2010    source источник


Ответы (2)


Это обсуждалось в дискуссионной группе здесь:

http://nservicebus.grouply.com/message/7059

Короче говоря, каждый узел должен отправлять, а не публиковать в одной конечной точке.

Надеюсь, это поможет.

person Udi Dahan    schedule 08.06.2010
comment
Спасибо за ответ, в чем основная разница между IBus.Publish и IBus.Send? - person Matt; 10.06.2010
comment
Если на минуту проигнорировать наш сценарий ошибки, возможно, рассмотрим систему обработки заказов, в которой группа служб публикует уведомления об обработанных ими заказах. Если бы мы собирались публиковать одно и то же сообщение с уведомлением о заказе от нескольких издателей для нескольких подписчиков, было бы правильной реализацией совместное использование хранилища подписки. Когда подписчики подписываются на наше сообщение, подписки добавляются в общее хранилище, и все издатели этого конкретного сообщения начинают публикацию для наших подписчиков. Кажется, это работает, но правильно ли это? - person Matt; 10.06.2010
comment
Мэтт - Я думаю, вы объединяете идею нескольких физических узлов публикации с несколькими логическими службами публикации. NServiceBus обеспечивает единую службу логической публикации, но в этой службе позволяет использовать столько физических узлов, сколько вы хотите (устанавливается автоматически в производственном профиле, сделайте это вручную, если бы вы использовали DbSubscriptionStorage). Кроме того, IBus.Publish используется для передачи событий, которые уже произошли, тогда как Send используется для запроса того, что мы хотим, чтобы произошло (но может быть отклонено). События не могут быть отклонены (так как они уже произошли). - person Udi Dahan; 13.06.2010

Вы можете записывать сообщения в журнал событий Windows и использовать такой инструмент, как OpManger, для отслеживания ошибок / предупреждений в журналах.

Дополнительные преимущества: OpManager может отслеживать процессы и сетевые порты, чтобы вы могли обнаруживать другие сбои. Он также поддерживает оповещения по электронной почте и имеет приятный веб-интерфейс.

person Charlie.Barker    schedule 08.06.2010