NServiceBus для настройки публикации событий CQRS
В настоящее время мы настраиваем проект на основе CQRS. Каждый экземпляр веб-проекта запускает NEventStore, однако все они имеют одинаковое постоянство EventStore (базовая база данных).
Теперь мы хотим опубликовать сохраненные события: не только в нашей модели ReadModel (по одному для каждого экземпляра веб-проекта), но и для дополнительных потребителей событий (например, унаследованные приложения, которые также должны быть каким-то образом проинформированы о событиях из нашей системы, и многие другие). Больше).
Поэтому у нас есть x потребителей событий (= обработчики событий) и y издателей событий, но только один "реальный источник" событий (базовая база данных EventStore).
В1: Есть ли сейчас лучший способ подключения этих систем через публикацию / подписку?
Мы думали о публикации событий из EventStore через NServiceBus. Все потребители должны подписаться на нужные им типы событий - поэтому каждый потребитель также должен подписаться, вероятно, на более чем одного издателя. В2: Возможно ли это? Мы прочитали, что вы не можете подписаться на одно и то же событие в нескольких местах, см.: Дэвид Бойк: "После того, как вы подпишетесь на Message1 на QueueName@WebServer1, вы также не сможете подписаться на Message1, полученное с QueueName@WebServer2".
Дополнительные открытые вопросы:Q3: Как определить, что потребитель был отключен навсегда (если он не успешно отписался от шины). -> Очередь заполнена?! Как отличить это от ситуации, когда он потерял только сетевое соединение на некоторое время?
Q4: Что произойдет, если соединение между службой подписки и EventStore ненадежно и не работает? Потребители успешно регистрируются в службе подписки, но EventStore не знает о новой подписке и не доставляет сообщения...
Q5: в целом: как NServiceBus обрабатывает очереди? Что происходит, когда потребитель недоступен в течение длительного периода времени (например, несколько дней)?
1 ответ
Q1: Это зависит от того, как вы подписываетесь на сообщения. NServiceBus был построен с учетом того, что существуют бизнес-сервисы (ограниченные контексты), которые не могут обмениваться данными. Однако в CQRS имеются жирные события, которые содержат много данных, которые публикуются, чтобы подписчики могли хранить информацию в своей модели чтения. Эта модель чтения используется, например, в пользовательском интерфейсе. Либо через обычный пользовательский интерфейс, либо через составной пользовательский интерфейс (который собирает информацию из нескольких бизнес-сервисов). Так что это зависит от того, что вы ищете.
Q2: можно подписаться на несколько событий. Однако есть только один логический издатель события. Таким образом, событие "CustomerWasBilled" не может исходить от ComponentA и ComponentB. Однако вы можете подписаться на множество разных событий, и у каждого издателя может быть много разных подписчиков.
[Udi] Данный издатель может быть масштабирован на нескольких серверах, и NServiceBus справится с этим за вас - нет необходимости подписываться на каждую машину.
Q3: я думаю, что это чистая администрация. Если он должен оставаться в сети и получать сообщения, очереди будут заполняться. Если он должен быть постоянно отключен / отключен и сообщения не обрабатываются, то вы узнаете довольно быстро после того, как компонент был отключен. Но я настоятельно рекомендую документировать, какие подписчики и издатели связаны друг с другом и что произойдет, если вы измените сообщение или компонент.
[Udi] Если это упорядоченное отключение, то оно должно включать отписку. Если это сбой, то есть временный, вы обнаружите это с помощью стандартного мониторинга (WMI). Чтобы защитить свою очередь от заполнения, вы можете определить, когда сообщение следует отбрасывать, используя атрибут TimeToBeReceived.
Q4: это обрабатывается в NServiceBus. Он хранит подписки в хранилище данных, которое может быть SQL Server, RavenDB & InMemory. Но он также сохраняет подписки в памяти и регулярно проверяет, были ли добавлены новые подписки. Не должно быть проблем с NServiceBus.
Q5: MSMQ сам по себе надежен по своей природе. Конечно, если весь ваш сервер выходит из строя и все сообщения были на жарком HD, это проблема. Если компонент недоступен в течение более длительного количества дней, это может зависеть от SLA. Вы можете отслеживать количество сообщений во входящей очереди или очереди ошибок. Не забудьте также DeadLetterQueue. Но NServiceBus позволяет вам также отслеживать, сколько времени занимает обработка сообщений.
Когда компонент недоступен в течение длительного периода времени (например, дней), бизнес должен решить, что делать. Если это важные сообщения обрабатываются, введите кластеризацию и т. Д.
Надеюсь это поможет