Масштабируемая публикация с масштабируемым подписчиком с NServiceBus

Я пытаюсь разделить два приложения с помощью EDA и NServiceBus. В настоящее время у меня есть МТ продаж и МТ инвентаризации. Каждый раз, когда через Sales MT запрашивается продажа, до того, как она будет одобрена, Sales MT вызовет Inventory MT, чтобы убедиться в наличии свободных запасов. Я хочу изменить способ, которым это работает, чтобы Sales MT просто автоматически одобряла его и публиковала асинхронное событие «SaleCreated», на которое затем подписываются Inventory MT и Billing MT. Затем Inventory MT может пометить продажу в автономном процессе, если есть какие-либо товары, отсутствующие на складе.

Моя проблема в том, что у меня есть 10 экземпляров моего Sales MT, 5 экземпляров моего Inventory MT и 3 экземпляра моего Billing MT. Все 3 приложения имеют свой собственный виртуальный IP-адрес поверх LoadBalancer, который находится перед серверами 10/5/3. Итак, в основном у меня есть 1 виртуальная публикация (события SaleCreated) и 2 виртуальные подписки (подписчики Inventory и Billing). В идеале продажа, которая обрабатывается модулем Sales MT, должна создавать сообщение о событии SaleCreated, которое будет отправлено на 1 и только 1 Inventory MT и 1 и только на один Billing MT. Я действительно не понимаю, как это будет работать, поскольку я не видел примеров этого сценария на сайте NServiceBus. Кроме того, я не хочу, чтобы все сообщения отправлялись одному дистрибьютору для каждой подписки, так как это приведет к тому, что одна машина станет узким местом.

Есть какой-либо способ сделать это?


person skb    schedule 07.07.2010    source источник


Ответы (1)


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

person Udi Dahan    schedule 08.07.2010
comment
Спасибо, Уди. Что помогает. У меня есть несколько замечаний: 1. Что вы имеете в виду под словом «найдено в производственном профиле» 2. Каким образом публикующий экземпляр получает уведомление о новых подписчиках в базе данных подписки, похоже, что проверка каждый раз была бы плохой. 3. Похоже, что еще может быть лучший способ распространения среди подписчиков. При этом каждое сообщение, созданное издателем, направляется через один ящик (даже если у вас 100 ящиков публикации). - person skb; 13.07.2010
comment
Чтобы узнать больше о профилях (и, в частности, о рабочем профиле), перейдите на страницу nservicebus.com/Profiles.aspx При работе с БД экземплярам издателя не нужно знать о новых подписчиках - они обращаются к БД при каждой публикации. Если вы не хотите, чтобы все дистрибьюторы были в одной коробке, хорошо - поместите их в разные коробки. Обычно вы разбиваете на разделы в зависимости от типа сообщения, чтобы можно было легко создать отдельный маршрут распространения для каждого типа сообщения. - person Udi Dahan; 14.07.2010
comment
Значит, для каждой публикации требуется обратный путь к БД подписки? - person skb; 15.07.2010
comment
При использовании производственного профиля / хранилища DbSubscriptionStorage - да. Тем не менее, он является подключаемым, поэтому вы можете предоставить свою собственную реализацию ISubscriptionStorage, скажем, через распределенный кеш для повышения производительности в масштабируемой среде. - person Udi Dahan; 15.07.2010