#masstransit
#masstransit
Вопрос:
все новички в Masstransit и в настоящее время оценивают его для более крупного проекта и задаются вопросом, может ли кто-нибудь помочь лучше понять следующие проблемы:
«Единый потребитель событий в среде с балансировкой нагрузки»
В процессе производства наши сервисы будут запускаться в нескольких экземплярах для обеспечения масштабируемости и отказоустойчивости и станут частью более широкой экосистемы микросервисов. Общая архитектура основана на эталонной реализации Microsoft eshoponcontainers, в которой различные микросервисы взаимодействуют друг с другом через «integrationevents». При публикации IntegrationEvent для других сервисов, которые, как я полагаю, должны выполняться, как описано в Masstransit Producers / Publish , https://masstransit-project.com/usage/producers.html#publish , как я могу гарантировать, что только ОДИН экземпляр в конкретном микросервисе обрабатывает событие, но, конечно, событие достигает ВСЕЙ микросистемы, которая зависит от события? Когда мы делали аналогичные решения на основе функций Azure, это требование было решено с помощью атрибута «Singelton» (https://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#singleton-attribute ).
Служебная шина Azure
Читая документацию, у меня сложилось впечатление, что Masstransit очень ориентирован на RabbitMQ. Поскольку мы будем подключены к служебной шине Azure при переходе на производство, существуют ли какие-либо ограничения или функции, недоступные для этого «транспорта»?
С уважением, Никлас
Ответ №1:
Что касается первого вопроса, это обычная публикация-подписка с конкурирующими потребителями. Это работает так из коробки, для достижения этого ничего не нужно делать.
При запуске нескольких экземпляров одной и той же службы
- Используйте одно и то же имя очереди для каждого экземпляра
- Сообщения из очереди будут сбалансированы по нагрузке во всех экземплярах (шаблон конкурирующего потребителя)
Это из руководств RMQ, но это похоже на это для всех транспортов.
Что касается Azure Service Bus transport, он работает должным образом и имеет много производственных пользователей. Это также должным образом задокументировано.
Я бы сказал, что на оба ваших вопроса ответ «это просто работает«.
Комментарии:
1. Привет, Алексей, и спасибо, что нашли время ответить на мой вопрос! Я сомневаюсь, достаточно ли хорошо объяснил свои требования, когда прочитал ваш ответ. События интеграции должны достигать ВСЕХ микросистем, но только один экземпляр в каждой из этих микросистем должен обрабатывать событие / сообщение (событие интеграции). Я прочитал ваш ответ как решение, основанное на очередях (конкурирующих), а не на тематическом подходе, где модель представляет собой одно сообщение для многих подписчиков. Публикация одного сообщения многим — это не настоящая проблема, это как гарантировать, что событие обрабатывается только одним экземпляром в каждой микросистеме.
2. Терминология темы и очереди зависит от транспорта. Как я уже сказал, как только запущено несколько экземпляров одной и той же службы, сообщение получит только один. Я не уверен, откуда берется сомнение. Довольно сложно быстро создать прототип и убедиться в этом самостоятельно.
3. Вы правы, я попробую и испачкаю руки! Спасибо за вашу помощь, Алексей!