В рабочем стартапе мы наконец-то начали приходить к микросервисам. Одно из ключевых ПО (API и все что с ними связано) уже на микросервисах, но еще на хостовой машине.
Однако, мой рабочий интеграционный проект во всю контейнеризируется и разворачивается на кластере с Docker Swarm :)
К слову, у нас в команде микросервисы и контейнеризация это веселый холивар ⚔️, которые длится уже полгода.
В обоих проектах используется общение между службами, где-то REST, а где то брокер сообщений 🎊 (там где не требуется синхронный ответ). В качестве брокера сообщений использовалась Apache Kafka.
Но недавно я познакомился с RabbitMQ и он мне понравился.
Теперь у нас зарождается новый холивар 😅
Но давайте подробнее что не так и почему так ...
Почему не Kafka?
Пока Kafka не касалась меня - я был лоялен, а использование даже нравилось. Но когда дело дошло до обслуживания все изменилось. 😐
Моя основная работа - разработка, а точнее программирование. Все остальные работы собственная инициатива и расширение профессиональных возможностей, а значит есть пробелы.
В этот же момент произошел уход офисного сисадмина, и все вопросы касаемо системной архитектуры легли на меня. Сроки поджимали, нужно было искать более простые пути решения. Удаленный сисадмин дал четко понять что нужна альтернатива Kafka. 😐 🤔 😏
Это стало ключевым фактором против Kafka, потому что:
На хост машину Kafka устанавливается не из официального репозитория, а при контейнеризации требует 2 контейнера на основное ПО (zookeeper, kafka) и 1 на web интерфейс (kowl), а тут еще это.
В оправдание Kafka, хочу сказать что со стороны пользователя она удобна, красивый и удобный web интерфейс kowl, библиотека swoole/phpkafka проста и понятна, к тому же с примерами использования. Есть громоздкая экосистема.
Почему RabbitMQ?
В нашем стартапе уже был кейс использования использования RabbitMQ (еще до моего прихода), аргументы против были стерты временем 😔, а текущая ситуация подсказывала дать еще один шанс кролику.
В обслуживании RabbitMQ оказался достаточно простым, устанавливается из официального репозитория, там же есть свой web интерфейс, а можно вообще поднять все в одном контейнере вместе с web интерфейсом. 😀
Web интерфейс не такой удобный и красивый (субьективно) как kowl, однако охватывает все аспекты обслуживания MQ в отличии от kowl.
Библиотека php-amqplib вполне понятна и даже есть туториалы (под несколько языков программирования).
RabbitMQ это продукт с централизованной экосистемой в которой легко разобраться при знакомстве с продуктом. После Kafka мне было проще понять и начать работать с RabbitMQ.
Но глупо было бы ставить это единственным фактором при принятии решения. Поэтому RabbitMQ был рассмотрен в предполагаемом контексте работы и полностью удовлетворил все необходимые нужды. А именно требовалось одноразовая гарантированная доставка.
Подводя итог ...
Kafka сложна на начальном этапе знакомства, в отличии от RabbitMQ, который достаточно прост.
Мы только начали использовать RabbitMQ и рассматривать его как альтернативу Apache Kafka, однако он уже радует. Будем пробовать, наблюдать, но Kafka у нас все еще остается в некоторых проектах, неизвестно может быть еще мигрируем обратно. Время покажет.
Аналогичная статья на моем сайте.