Организуя микросервисную архитектуру при помощи Docker Swarm потребовалось общение между службами. Вариант REST не устраивал, так как возможна цепочка http запросов с синхронным ожиданием, что для некоторых служб может быть критично. А вот MQ вполне подходит.
В нашем стартапе уже используется Apache Kafka, но не всех нас она устраивает, и это дало мне возможность найти альтернативу, одной из которых стал RabbitMQ.
Что не так с Kafka?
Пока Kafka не касалась меня - я был лоялен, а использование даже нравилась. Но когда дело дошло до обслуживания все изменилось. Точнее дело было в условиях, которые стояли передо мной на тот момент, а именно:
- самооблуживание, к сожалению в проекте на тот момент произошел уход офисного сисадмина, а удаленный был загружен работой, поэтому обслуживание MQ ложилось полностью на меня. Можно было бы подождать пока сисадмин освободиться, но ждать было непозволительно
К тому же занятый сисадмин посоветовал подыскать альтернативу, так как его тоже не устраивало обслуживание.
В оправдание Kafka, хочу сказать что со стороны пользователя она удобна, красивый и удобный web интерфейс kowl, библиотека swoole/phpkafka проста и понятна, к тому же с примерами использования.
Но было решено искать альтернативу.
Почему RabbitMQ?
В нашем стартапе уже был кейс использования использования RabbitMQ (еще до моего прихода), аргументы против были стерты временем, а текущая ситуация подсказывала дать еще один шанс кролику.
Web интерфейс не такой удобный и красивый (субьективно) как kowl, однако охватывает все аспекты обслуживания MQ в отличии от kowl.
Библиотека php-amqplib вполне понятна и даже есть туториалы (под несколько языков программирования).
Кстати, у Kafka тоже есть громоздкая экосистема.
Но глупо было бы ставить это единственным фактором при принятии решения. Поэтому RabbitMQ был рассмотрен в предполагаемом контексте работы и полностью удовлетворил все необходимые нужды. А именно требовалось одноразовая гарантированная доставка.
Но в то же время это более сложный MQ за счет своих возможностей, например того же роутинга. Что может быть избыточным в тривиальной организации очереди сообщений (как в Kafka), но может оказаться полезным в сложной логике распределения и доставки сообщений потребителям.
Итог
Мы только начали использовать RabbitMQ, однако он уже радует. Будем пробовать, наблюдать, но Kafka у нас все еще остается в некоторых проектах, неизвестно может быть еще мигрируем обратно. Время покажет.
Кстати, недавно я писал про организацию исключений, к сожалению обе рассмотреные библиотеки-клиенты MQ не везде в PHPDoc комментариях объявляют обо всех выбрасываемых исключениях, поэтому кроме изучения документации пришлось лезть в исходный код, что весьма не удобно.