исследуй
проектируй
Улучшай

Попытаемся разобраться с тем, что есть брокер, почему на них все помешались, и если уж досталось работать с брокером, то какой выбрать и как.
Неисчерпывающий список выглядит примерно так:

1. Apache Kafka
2. RabbitMQ
3. ActiveMQ
4. Amazon SQS
5. Google Cloud Pub/Sub
6. Microsoft Azure Service Bus
7. Redis (используемый как брокер сообщений)
8. NATS
9. ZeroMQ
10. IBM MQ
11. Pulsar (Apache Pulsar)
12. RocketMQ
13. Mosquitto (для MQTT)
14. EMQX (для MQTT)

Довольно внушительный список, сравнивать каждый с каждым - это перебор, попытаемся как-то иначе подойти к этой задаче.

Чтобы разобраться, для чего используются брокеры, давайте разберемся, что это такое.

Первое, что приходит на ум, когда мы слышим "брокер" - это специалист, работающий в финансовой сфере, некий посредник, кто-то мутный в галстуке, с сорванными голосовыми связками, кто-то похожий на героя фильма "Волк с Уолл-Стрит".

Пожалуй, единственное, что можно взять из этого представления брокера в определение брокера в контексте IT сервисов и систем - это посредничество. Брокер на языке разработки по-прежнему посредник. Суть посредничества - это передача информации от сервиса к сервису в форме сообщений.
Уже этого понимания достаточно, чтобы определить, что брокеры оправданы в сложных архитектурных решениях, когда информация должна быть поставлена нескольким потребителям и/или от нескольких отправителей.

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

Участники процесса

Мы разбираем процесс передачи информации через сообщения.
Рассуждаем, что, вероятно:

• должна быть сторона, которая информацию сгенерировала или создала и нуждается в отправке; на языке брокера - это Издатель (Publisher);
• должна быть сторона, в адрес которой должно быть доставлена информация; на языке брокера - это Потребитель (Consumer);
• должен быть канал передачи информации и какие-то правила, которые позволяют информации безошибочно попасть от определенного отправителя определенному получателю. Exchange - некий обменник, в который попадают сообщения Издателя. Binding - набор правил, по которым сообщение попадает в определенную очередь. Queue - собственно, очередь сообщений (мы исходим из того, что мутить целый сервис ради отправки одного сообщения - это, объектино, перебор).

Как всё работает

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

2.За счет правил или "привязок" сообщение попадает в нужную очередь.

3.Когда Потребитель (Consumer) готов обработать сообщение, он получает копию события, полученного от Издателя (Publisher).

Важно, что Consumer может находиться в неактивном состоянии, или обрабатывать ранее пришедшее сообщение.

4.Consumer на своей стороне как-то обрабатывает сообщение, и дает обратную связь брокеру о результате. На языке брокера это ACK (от acknowledgment - подтверждение)

5.Брокер получает и интерпретирует ответ от Consumer, и удаляет доставленное сообщение из очереди.

На самом деле, разные брокеры поступают с успешно доставленными сообщениями по-разному: одни, как RabbitMQ, удаляют, другие хранят, и далее удаляют по расписанию или через вручную отправленную команду.

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

Как выбрать брокер

По факту, ориентируясь на возможности и ограничения, выбираем брокер под задачу.

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

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

Вопросы, которые могут нам помочь:
1.Глобально в решение какой задачи должен быть встроен брокер и почему. Есть ли иное (без брокера) решение, возможно уже сегодня задача решается как-то иначе, какие профиты бизнес рассчитывает получить при переходе на брокер. У нас должна быть карта бизнес процесса как он есть.
Иначе говоря, как работает уже, и что не так.
2.Какое масштабирование мы должны предусмотреть: количество и качество издателей и потребителей
3.Какое количество сообщений в единицу времени должно обеспечить
4.Какие требования к хранению и переиспользованию данных сообщений
5.Какие протоколы должен поддерживать брокер.
6.Какие требования к надежности доставки.