🐰 Одна из причин выбрать RabbitMQ

30.06.2022

Организуя микросервисную архитектуру при помощи Docker Swarm потребовалось общение между службами. Вариант REST не устраивал, так как возможна цепочка http запросов с синхронным ожиданием, что для некоторых служб может быть критично. А вот MQ вполне подходит.

В нашем стартапе уже используется Apache Kafka, но не всех нас она устраивает, и это дало мне возможность найти альтернативу, одной из которых стал RabbitMQ.

Эта статья всего-лишь одна из историй почему был выбран тот или иной продукт и ни в коем случае не претендует на исключительную истину. Думайте своей головой и принимайте решения исходя из своих условий.

Что не так с Kafka?

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

  • самооблуживание, к сожалению в проекте на тот момент произошел уход офисного сисадмина, а удаленный был загружен работой, поэтому обслуживание MQ ложилось полностью на меня. Можно было бы подождать пока сисадмин освободиться, но ждать было непозволительно
Это стало ключевым фактором против Kafka, потому что:

На хост машину Kafka устанавливается не из официального репозитория, а при контейнеризации требует 2 контейнера на основное ПО (zookeeper, kafka) и 1 на web интерфейс (kowl), а тут еще это.

К тому же занятый сисадмин посоветовал подыскать альтернативу, так как его тоже не устраивало обслуживание.

В оправдание Kafka, хочу сказать что со стороны пользователя она удобна, красивый и удобный web интерфейс kowl, библиотека swoole/phpkafka проста и понятна, к тому же с примерами использования.

Kowl - web интерфейс для Kafka
Kowl - web интерфейс для Kafka

Но было решено искать альтернативу.

Почему RabbitMQ?

В нашем стартапе уже был кейс использования использования RabbitMQ (еще до моего прихода), аргументы против были стерты временем, а текущая ситуация подсказывала дать еще один шанс кролику.

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

Web интерфейс не такой удобный и красивый (субьективно) как kowl, однако охватывает все аспекты обслуживания MQ в отличии от kowl.

RabbitMQ Management - web интерфейс для RabbitMQ
RabbitMQ Management - web интерфейс для RabbitMQ

Библиотека php-amqplib вполне понятна и даже есть туториалы (под несколько языков программирования).

RabbitMQ это продукт с централизованной экосистемой в которой легко разобраться при знакомстве с продуктом.

Кстати, у Kafka тоже есть громоздкая экосистема.

Но глупо было бы ставить это единственным фактором при принятии решения. Поэтому RabbitMQ был рассмотрен в предполагаемом контексте работы и полностью удовлетворил все необходимые нужды. А именно требовалось одноразовая гарантированная доставка.

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

Итог

Мы только начали использовать RabbitMQ, однако он уже радует. Будем пробовать, наблюдать, но Kafka у нас все еще остается в некоторых проектах, неизвестно может быть еще мигрируем обратно. Время покажет.

Кстати, недавно я писал про организацию исключений, к сожалению обе рассмотреные библиотеки-клиенты MQ не везде в PHPDoc комментариях объявляют обо всех выбрасываемых исключениях, поэтому кроме изучения документации пришлось лезть в исходный код, что весьма не удобно.