Что нужно знать про асинхронные интеграции

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

Зачем нужна асинхронная интеграция

✅ Слабая связанность сервисов

Наиболее часто применяется паттерн "издатель-подписчик". Сервис-издатель публикует сообщения в очереди и далее судьбой сообщений не интересуется. Количество подписчиков и алгоритм использования сообщений сервис-издатель никак не задевают. В любой момент времени сообщения может читать один подписчик, тысяча, миллион или даже вообще никто не читать.

✅ Легкость масштабирования

Архитектура "издатель-подписчик" позволяет нам в любой момент поменять архитектуру приложения, изменить количество микросервисов, но при этом не менять код сервиса(ов)-публикатора(ов). Сервисы-потребители, при этом, никак не влияют на работу друг друга. Наоборот, это также работает: можно увеличить количество публикаторов и их логику, подписчики, при этом, разницы не почувствуют.

✅ Повышение надежности

Выход из строя одного из компонентов не сказывается на работе всей системы: при восстановлении он обработает сообщение, находящееся в очереди. Ваш веб-сайт по-прежнему может работать, даже если задерживается часть обработки заказа, например, из-за проблем с сервером БД или системой электронной почты. Правда, при этом очередь сама приобретает статус SPoF (Single Point Of Failure), поэтому необходимо заранее предусмотреть действия на случай ее аварийного отключения.

Когда асинхронное взаимодействие лучше не использовать

⛔️ Простая архитектура и функции

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

⛔️ Монолитные системы

Если вы не планируете разбивать монолит на микросервисы, но вам требуется асинхронность, для ее реализации обычно достаточно стандартной многопоточной модели.

Важные моменты

1. Очередь – это ещё одна система, которую необходимо поддерживать и на которую нужны мощности.
2. Если брокер выйдет из строя, это может остановить работу многих систем, взаимодействующих с ним. Как минимум необходимо позаботиться о резервном копировании данных.
3. Усложняется отладка. Необходимо позаботиться о системе трассировки для обнаружения причин ошибок.

Как понять, следует ли выбрать асинхронную интеграцию?

Правильный выбор подхода зависит от следующих факторов:

• Время отклика. Если требуется мгновенный отклик и задержки недопустимы, синхронное взаимодействие может быть предпочтительным. Асинхронное взаимодействие подходит, когда не требуется немедленный ответ или подтверждение от получателя.
• Надежность. Если надежность и отказоустойчивость критичны, асинхронное взаимодействие может быть предпочтительным, так как избегает блокировок и позволяет более гибко обрабатывать ошибки и отказы.
• Производительность. Если система требует высокой производительности и параллельной обработки запросов, асинхронное взаимодействие может быть более эффективным.

📄 Статьи

1. Асинхронная интеграция. Что это такое и как её дружить
2. Зачем нужны очереди сообщений в микросервисной архитектуре
3. Что такое очереди сообщений и почему они широко используются в распределенных системах?
4. Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры
5. Брокеры сообщений
6. Стратегии доставки и дедупликации сообщений — статья на Хабре от OTUS.
7. Асинхронное взаимодействие. Брокеры сообщений — чуть глубже по брокерам сообщений и немного про Кафку.
8. Apache Kafka: основы технологии — от Слёрм.
9. RabbitMQ для аналитика: практический ликбез — BABOK School.
10. AMQP на примере RabbitMQ: как же «готовить кролика»? — простым языком о RabbitMQ.
11. Соседняя очередь всегда движется быстрее — углубленная статья на Хабре про то, как устроены очереди и какие есть решения.
12. Угнать за 5 миллисекунд: как мы наладили быструю доставку данных в сложной биржевой системе с помощью Tarantool — практический кейс проекта для Московской биржи.
13. Как построить систему, способную выдерживать нагрузку в 5 млн rps — практический пример от Ozon. Тут будет про gRPC-прокси перед Кафкой.

▶️ Видео и вебинары

1. Принципы и приёмы обработки очередей / Константин Осипов (то же, только статья).
2. Интеграция распределенных систем через обмен сообщениями — базовый вебинар.
3. Реализация геораспределенной персистентной очереди сообщений / Василий Богонатов (Яндекс).
4. Микросервисы: Коммуникации через очередь сообщений.
5. Очереди сообщений с RabbitMQ: что такое, когда нужно, какие проблемы решает.
6. Как правильно выбирать очередь / Владимир Перепелица (Mail.Ru Group).
7. Битва брокеров сообщений: Kafka, RabbitMQ, SQS — Яндекс.Практикум.

📖 Книги

1. Гайвин Рой. RabbitMQ для профессионалов — онлайн книга на русском.
2. Emil Koutanov. Effective Kafka: A Hands-On Guide to Building Robust and Scalable Event-Driven Applications with Code Examples — одна из лучших книг по Кафке.
3. Дилан Скотт, Виктор Гамов, Дейв Клейн. Kafka в действии — на русском.
4. Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka.