Недавно успешно сдали пользователям в эксплуатацию систему обработки обращений граждан. Суть такая, что когда у вас нет дома воды, отопления или рядом с вашим домом огромная яма на дороге, вы можете пожаловаться на проблему в гос.органы. Есть разные площадки, где можно подать заявку с жалобой: сайты гос.учреждений, странички в соц.сетях, колл-центры.
Нашей задачей было создать единый трубопровод обработки заявок для всех ведомств.
Главная цель системы — максимально ускорить процесс обработки обращений: автоматизировать все автоматизируемое, контролировать сроки на каждом этапе процесса, информировать жителей о каждом шаге.
Одной из специфичных задач проекта был вопрос интеграции с большим числом внешних систем.
- Нужно было научиться с разных площадок забирать весь поток жалоб, уметь с ними общаться по всем изменениям с заявками, вести переписки между гос.служащими и гражданами по уточнениям деталей жалоб.
- Помимо это часть функций мы отдали на откуп сторонним сервисам.
Т.к. данных поступало много, часто приходилось работать в асинхронном режиме, то проектной команде пришлось решать вопрос, как бы не заддосить себя и сторонние системы. Решение нашли в программном брокере сообщений Rabbit MQ. Это была новая технология для команды на тот момент.
Ниже интервью с разработчиком бэкенда проекта, Александром Щегловым WilyLynx, который разбирался с вопросом и реализовывал интеграцию.
— Саш, привет! Расскажи пожалуйста в двух словах что собой представляет Rabbit MQ?
ПО предназначенное, в основном, для реализации отложенного обмена сообщениями между различными клиентами, т.е. когда тебе не нужен ответ непосредственно сейчас.
— Правильно понимаю, что в общем это работает так: передающий сервис в созданную очередь кладет данные по мере их генерации, принимающий сервис по мере необходимости эту информацию забирает?
Именно так и работает.
— Почему вы (группа разработки) выбрали это решение для проекта?
По нескольким причинам. Во-первых, в нашем случае синхронная обработка (получили и в тот же момент обработали) сообщения не критична, т.е. сообщение может повисеть в очереди некоторое время. К тому же простота использования: для приема сообщений нужно только объявить имя очереди и нет необходимости писать свои сервисы. Ну и наличие библиотек для распространенных ЯП. Не нужно что-то изобретать для работы с RabbitMQ.
— Правильно понимаю, что Rabbit MQ позволяет управлять обменом данными между системами и веб-сервисами?
Скорее все-таки управляем обменом мы, а вот “кролик” является отличным инструментом для организации данного обмена. Тут тебе и время жизни сообщений в очередях, и максимальная длина очереди, и настройка доступа, и кластеризация, и различные протоколы обмена, и система плагинов и прочее.
— Как определяется, что сообщение доставлено? — то есть как определяется, что клиент что-то продолбил после получения или повис в процессе?
Считается доставленным если за определенный промежуток времени приходит отклик от клиента. В нем, собственно, и говорится, что получил и доволен жизнью. Клиент может отправить отклик сразу как получил, а потом попытаться обработать сообщение. Может, наоборот, сначала попытаться обработать и при успешной обработке отправить отклик. А можно заранее сказать кролику чтоб он от тебя не ждал подтверждения о доставке и просто получать сообщения. Все отправленные будут автоматически считаться доставленными.
— Можно ли например каким-то образом получать сообщения не все, а например подписаться только на сообщения по конкретной заявке?
Тут немного другая ситуация. Есть вариант отправки сообщений, при котором сообщения приходят всем клиентам. Этот вариант носит название «publish/subscribe». Наглядный пример: новое сообщение в твоем паблике. Ты отправила, все подписанты получили. А уже при получении подумали, читать или не читать. А вообще никто тебе не мешает создать для себя отдельную очередь и работать только с ней. В этом случае уже маршрутизация будет на уровне приложения, а кролик как канал связи.
— Саша, скажи, есть вариант не создавать тысячи очередей, а делать фильтрацию, маршрутизацию для одной?
Из одной не получится, но некоторую маршрутизацию Rabbit сделать позволит.
— Расскажи, пожалуйста, подробнее.
Из одной нет, но есть такие понятия “exchange" и «routing key”:
P — producer, отправитель сообщения в exchange(обмен)
Х — сам обмен
Красные полоски — очереди
С1 и С2 — получатели
Pabbit может отправить сообщение в обмен с определенным ключом(на примере error/info/warning). И как видно разные получатели заточены на получение сообщений с разными routing key. Причем сообщение с ключом „info“ получит только С2, а с ключом „error“ получат оба. Так же есть возможность получать сообщения по шаблону для ключа. Это для другого типа обмена „Publish/Subscribe“, про который я ранее уже говорил.
Как сама видишь в любом случае для каждого из получателей в этих типах обмена есть своя очередь, но по итогу мы все-таки имеем некоторое подобие фильтрации/маршрутизации.
— Какие можешь вспомнить проблемы, которые возникали в процессе изучения и внедрения Rabbitа?
Кроме лени никаких. Если серьезно, то понятная документация, большое кол-во примеров.
— Вы уже все обмены с сервисам и внешними системами на него перевели?
У нас сейчас 38 очередей: обмен между контурами, внешними системами, BI. Но к сожалению, некоторые сервисы (читай ведомства) сопротивляются. т.к. у них реализован rest. К тому же некоторые виды взаимодействий подразумевают синхронное получение ответов на запросы.
— Как считаешь, насколько удачным было это решение?
Для межведомственного взаимодействия, не требующего синхронного ответа? По мне, так отличный вариант.
Список использованных материалов
Автор: sobole4ik_1
