Что использовать для реализации EDA в микросервисной архитектуре?

Строим с коллегами кубернетес-кластер. Идея такая, что фронт общается с бэком через наутилус, а бэк между собой - через брокер сообщений, или что-то вроде того. Сейчас поставили rabbitMQ, и поняли что видимо промахнулись с выбором.

Как мы это видим:
Один микросервис выполняет какое-то действие, пришедшее с наутилуса. Этот микросервис оповещает все остальные микросервисы о произведенных изменениях, путем размещения в брокере уведомления. Типа "Пользователь 113 - удалён". Следовательно другие микросервисы, видя это уведомление, читают его и у себя производят нужные действия (например удаляют связанные объекты).

В чем проблема с Рэббитом:
Как только первый консьюмер (микросервис) читает сообщение в очереди - оно удаляется.

В чем вопрос:
Мы что-то не так настроили? Нам надо чтобы сообщение не удалялось. Если рэббит не подходит, что использовать лучше? Посматриваем в сторону Рэдиса или Кафки.
Про хайлоад вопрос не стоит.
  • Вопрос задан
  • 103 просмотра
Пригласить эксперта
Ответы на вопрос 1
@yarkin
RabbitMQ это про очереди, если у вас есть очередь задач, то не думаю, что захотите чтобы все воркеры выполняли одно и тоже действие. Если нужно, чтобы каждый сервис получал копию сообщения, они должны иметь независимые очереди, которые могут быть подписаны на один эксчендж.
Если у вас может быть по N инстансов одного сервиса, то все N подписываются на одну и ту же очередь (иначе см. выше что будет), но каждый сервис должен иметь свою очередь.
Почитайте базовые мануалы по RabbitMQ - https://www.rabbitmq.com/getstarted.html - там много полезного найдёте (на хабре есть переводы на русский, если надо)

Например, для простоты возмём что эксчендж всего один - events. Есть два сервиса - S1 и S2. У каждого из них по 3 инстанса. Сервисы хотят получать все сообщения которые публикуются в events.
Получаем (допусти ещё ничего нет):
- создаём эксчендж events (лучше до запуска всего) с типом fanout
- первый инстанс S1 при запуске создаёт очередь - events-s1; создаёт биндинг этой очереди на эксчендж events; подписывается на эту очередь
- второй и третий инстансы S1 при запуске видят, что очередь есть и просто подписываться на неё
- всё тоже самое повторяется для S2

При росте сервисов, одного эксченджа может не очень хватить, тогда одна очередь может имеет более одного биндинга к нужным ей эксченджам. Или тип эксченджа можно поменять на topic и управлять тем кто получит сообщения уже через ключи биндингов и заголовки сообщений, а не имена эксченджей.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы