¶ 300 Интеграционная шина
¶ Предисловие
Перед тем как задуматься о интеграции с шиной стоит осмысленно оценить задачу и понять нужен ли для неё брокер сообщений. Никто из нас не является профессиональным архитектором, но прекрасно понимает к чему может привести over-engineering в проекте.
- Примеры кейсов, когда вам нужен брокер сообщений
- Сбор потоковых событий в аналитическую СУБД для последующего анализа посещаемости веб-сайта
- Репликация данных между сервисами в связи с высокой загруженностью системы, которая эти данные выдаёт. Например вместо частых походов в API тайги за пользователями можно из этой тайги их проливать в очередь, а на стороне вашего сервиса их вычитывать и сохранять.
- Вам нужно оптимизировать логику, выполняемую в распределённой системе асинхронно, например, у вас есть сервис A, который совершает тяжёлые запросы в базу, формируя большой ответ и отправляет его в сервис B. При этом запросы не являются частыми, а скорее рутинными. Можно в сервисе А исполнять их по джобе, а после отправлять в очередь, из которой сервис B их достанет и сохранит к себе
¶ Особенности нашей шины
- Мы используем RabbitMQ
- Схемы данных описаны в формате open-api
- Мы работаем с JSON форматом, для простоты использования
- Шина не гарантирует корректность данных внутри брокера
В данный момент реализован сбор данных о событиях происшодящих в трекере Taiga
¶ Основные сущности в RabbitMQ
- producer - клиент, отправляющий сообщения в exchange
- consumer - клиент, вычитывающий сообщения из queue (очередям)
- exchange - входная точка для сообщений, распределяющая их по очередям
- binding - привязка сообщений из exchange по определённым очередям
- queue - очередь с сообщениями
Настоятельно рекомендуется ознакомиться с документацией, в ней разбираются основные способы работы с RabbitMQ, много примеров кода и ссылки на бибилотеки для большинства языков.
¶ Как интегрироваться с шиной
- Ваш проект оформляет заявку и отправляет нам в 300 проект
- Мы создаём нужные для вас топики/эксченджи и биндинги
- Создаём для вашего сервиса пользователя и выдаём права на чтение/запись и так далее
¶ Примечания по интеграции
У нас есть правила по именованию топиков и эксченджей.
- Если вы хотите новый exchange, определите его тип, рекомендуем называть exchange общим образом, а через девис указывать его тип:
taiga-direct-exchangeилиtaiga-topic-exchange, - Очереди стоит называть в формате
{exchange}.{subject}-queue, например у вас естьtaiga-topic-exchangeи ваше приложение должно отслеживать все сообщения, по эпикам, тогда лучше назвать очередьtaiga-topic-exchange.epic-queue, а если только создание эпиков, тоtaiga-topic-exchange.epic.create-queue - Рекомендуем не писать из нескольких exchange в одну очередь, так как идея скорее в том, чтобы делить exchange на множество очередей в зависимости от bindings
- Учтите, что RabbitMQ удаляет сообщения после прочтения, если у вас несколько инстансов одного сервиса, то не гарантируется порядок чтения! Если вам нужно читать, но не удалять сообщения, например вы читаете их в нескольких разных сервисах, то вы можете:
- Подменить callback в API RabbitMQ и не оповещать брокер о том, что вы прочитали сообщение
- Создать ещё один топик и писать в него аналогичные сообщения, например
taiga-topic-exchange.epic-queue-serviceA,taiga-topic-exchange.epic-queue-serviceB
- Если у вас получаются сложные и длинные названия очередей и эксченджей, то это нормально. Явное лучше неявного.
¶ Наглядные How-To для администраторов шины данных
¶ Как создать новый exchange
- Зайти на страничку с RabbitMQ management и залогиниться
- Открыть вкладку exchanges
- Аккуратно заполнить формочку с exchange'ем,