Контакты+7 (495) 788 74 17



RabbitMQ


Вернуться к списку статей


Внедрение RabbitMQ - это пожалуй один из самых длинных наших “долгостроев”. Начиналось все как всегда в наивной надежде, что сейчас мы применим популярную технологию, которая позволит нам с легкостью решить некоторые наши проблемы. Тем более RabbitMQ написан на Erlang, который славится своей надежностью. На деле все получилось как обычно… Суммарно внедрение заняло у нас порядка 1 года. Если не изменяет память год тогда был 2011-ый.

Для тех кто еще не знаком с этой технологией краткая справка: RabbiMQ - это брокер сообщений. Основная его задача - принять сообщение из источника и доставить его в приемник (подписчику). Приемников может быть несколько, RabbitMQ позволяет гибко настраивать маршрутизацию сообщений. Например одно сообщение в зависимости от условий может быть направлено одному подписчику в группе, или всей группе сразу.

Изначально мы планировали внедрить RabbitMQ, для проекта TopHotels. Это может быть не очевидным, но TopHotels - это не просто описания отелей. Внутри него происходит множество скрытых бизнес-процессов. Один из них взаимодействие с отельерами: для некоторых отелей существует возможность напрямую задать вопрос отельеру и получить ответ. Но далеко не все из этих отелей имеют консультанта и далеко не все консультанты русскоязычные. В случае если консультант отеля не русскоязычный, вопрос нужно предварительно перевести на английский и затем перевести ответ. Если у отеля нет консультанта, с ним может связаться наш сотрудник.

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

Теперь представьте ситуацию - на проекте TopHotels пользователь задает вопрос, в зависимости от перечисленных выше условий уведомление (например на email) об этом должен получить либо отельер, либо переводчик, либо сотрудник техподдержки. Вопрос - какой проект должен отправить это уведомление? Если это сам TopHotels, то его (и его разработчиков) это во первых обязывает знать о существовании других проектов, во вторых - по сути реализовывать их бизнес-логику. Кто сталкивался с этим в реальности поймет, что на деле это не только усложняет разработку, но также требует четкой координации работы с другими группами, что на порядок сложнее. По этому правильное решение - уведомление (да и вообще всю обработку сообщения) должен осуществлять тот проект, которому оно “адресовано”. Остается вопрос какую технологию использовать для доставки сообщения проекту?

И тут наш выбор пал на RabbitMQ.

Казалось что он должен решить все наши проблемы, но на деле получилось несколько сложнее. RabbitMQ использует AMQP протокол. По сути клиенты для него, это не клиенты RabbitMQ, а различные реализации протокола AMQP. Под PHP есть готовый клиент, который использует готовую PECL библиотеку AMQP. И вот она то как раз отказалась собираться в нашей серверной конфигурации. Было ощущение что там что-то не доделано. Что мы только не пробовали :) В какой-то момент мы хотели даже написать свою версию клиента, но вовремя остановились.

К сожалению процесс проб и ошибок, писем разработчикам библиотеки и бесконечных обращений к системным администраторам оказался очень долгим. За это время для нашей задачи пришлось выбрать другое решение. А через пол года вышло обновление библиотеки и все заработало “из коробки”.

Сам RabbitMQ кажется сразу тоже не завелся, но за то время пока мы возились с клиентом мы успели его завести.

После этого он порадовал нас относительной стабильностью и приятным административным интерфейсом, который поставляется вместе с ним. “Относительной”, потому что он иногда все-таки падает по неизвестным нам причинам. Но это случается достаточно редко. В остальное время он работает хорошо, и очень хорошо держит нагрузку. А нагрузили мы его недавно по полной :)

Сейчас мы используем RabbitMQ в двух основных задачах, и очень довольны результатами:

1. Сборка статистики и логирование. Это операции которые не являются основной бизнес-логикой приложения, по этому должны занимать максимально короткое время и ни в коем случае не должны влиять на стабильность работы приложения. Это означает что хорошее решение - когда этим занимается отдельный сервис. Встает вопрос как доставить ему сообщение. Ребята из Badoo, когда-то демонстрировали решение на основе UPD протокола. Это хороший вариант. Но ряде случаем нам нужна гарантия получения сообщения. По этому здесь мы используем RabbitMQ.

2. Взаимодействие межу “микросервисами”. Да, да. В какой-то момент мы обнаружили что архитектурные решения, которые мы использовали уже с давних времен вдруг стали трендом с модным названием “микросервисы”. Одна из интересных задач связанных с ними выглядит так: есть большой и сложный механизм поиска туров, через который в день проходит много предложений. И есть скажем отдельный микросервис, которому нужно что-то из этого потока выцепить - может статистику посчитать, или кешик какой-то построить. RabbitMQ оказался очень удобным для организации такого потока и “подписки” на него. Мы назвали его TourStream. Механизм поиска предложений отправляет данные в поток не заботясь о получателях, а те кто хочет их получать просто в нужный момент на него подписываются. Не смотря на большие объемы данных кролик отлично справился с ними.

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



Оставить заявку
Приложите файл резюме или ссылку на резюме
Файл резюме

Вычислите значение выражения:

CAPTCHA Image [обновить]

ок