RabbitMQ Microservices - Параллельная обработка - PullRequest
1 голос
/ 12 февраля 2020

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

вызовы между микроуслугами являются асинхронными HTTP-запросами, и каждая служба подписывается на определенные c очереди

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

Ответы [ 2 ]

0 голосов
/ 24 февраля 2020

Извините за двусмысленность, я пытаюсь объяснить далее:

Сценарий таков, что мы находимся в микросервисной архитектуре, из-за большого отклика данных служба вызова получит ответ в слушателе rabbitmq queue.

Итак, давайте представим, что два вызова выполняются одновременно, и оба запроса начинают загружать данные в одну и ту же очередь, вызывающая служба ожидает сообщения и добавляет полученные сообщения, но не может различить данные вызывающего абонента 1 и вызывающий абонент 2.

Есть ли лучшая реализация для слушателя

0 голосов
/ 15 февраля 2020

Не уверен, что я полностью понял вопрос, но вот что я могу предложить, основываясь на описании:

Если каждая служба подключена к определенному слушателю, и вы не хотите ассоциировать ключ маршрутизации для интеграции Queue + Listener, вы можете попробовать использовать аргументы заголовка. [Вы можете использовать API QueueBuilder.withArguments для установки указанных c значений заголовка, которые должна прослушивать очередь]. Должен существовать механизм, посредством которого обмен будет связываться с определенной очередью и, следовательно, со службой прослушивания.

Publisher -> Exchange ---> (с заголовками) привязывается к очереди -> Слушатель

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...