При использовании микросервисной архитектуры необходимо решить ряд задач. Одна из них — успешная доставка каждого сообщения. Давайте разберемся, как они решают эту задачу и как их внедрить.
Зачем нужны брокеры сообщений
Взаимодействие между компонентами вашего приложения может быть синхронным или асинхронным. Обычно связь на основе HTTP представляет собой синхронную связь, при которой вызывающая сторона блокирует следующий шаг до тех пор, пока вызов службы не будет завершен, как вы можете видеть на рисунке:
При реализации синхронного взаимодействия вы должны учитывать несколько обстоятельств, при которых пункт назначения сервиса может быть недоступен или иметь низкую производительность, медленный отклик. Делать это необходимо, поскольку эти обстоятельства приведут к серьезным проблемам с производительностью вашего приложения.
Для решения этих проблем можно использовать общение на основе сообщений. В этом помогут брокеры сообщений. С брокером сообщений связь будет асинхронной.
Какие бывают брокеры сообщений
Брокеров сообщений есть множество, но сегодня я хотел бы выделить два вида: Apache Kafka и RabbitMQ, так как они являются промышленными стандартами и используются во многих высоконагруженных системах.
Apache Kafka и RabbitMQ — это две коммерчески поддерживаемые системы публикации и подписки с открытым исходным кодом, которые легко внедряются предприятиями. RabbitMQ — был выпущен в 2007 году. Он является основным компонентом систем обмена сообщениями и SOA. Среди областей его применения также потоковая передача. Kafka же был создан изначально для потоковых сценариев в 2011 году.
Важным отличием Kafka от RabbitMQ является то, что первый основан на pull, а второй — на push. В чем суть? Системы, основанные на pull предполагают ожидание брокерами запроса данных со стороны потребителя — так называемое «вытягивание». Системы же базирующиеся на push-уведомлениях отправляют сообщения сразу всем подписанным потребителям. Это различие ведет к тому, что брокеры ведут себя по-разному.
Так, Kafka допускает создание длинных пулов, что предотвращает зацикливание, когда нет сообщения после смещения, и агрессивно группирует сообщения для поддержки этого. Подобная модель является логичной для этого брокера сообщений из-за секционированной структуры данных. Kafka обеспечивает порядок сообщений в разделе без конкурирующих потребителей. Благодаря этому пользователи могут использовать пакетную обработку сообщений для их эффективной доставки и повышения пропускной способности.
Модель push-уведомлений RabbitMQ предотвращает перегрузку потребителей за счет ограничения предварительной выборки. Цель такого брокера сообщений заключается в индивидуальном распространение сообщений без задержек для обеспечения равномерной работы и обработки сообщений в порядке их поступления. Это может создать проблемы в случаях, когда потребители «умерли» и перестали получать сообщения.
Как внедрить брокеры сообщений
Давайте реализуем два приложения. Для простоты будем использовать spring cloud stream. Первое приложение будет публиковать сообщения о фильмах. Второе — слушать и складировать фильмы.
Для начала добавим зависимости:
Нам также нужно запустить экземпляры Kafka. Есть несколько способов сделать это, но я предпочел бы запустить Kafka с помощью Docker compose.
Для приложений будет общая модель:
Добавим контроллер для первого приложения:
Мы аннотируем наш класс контроллера с помощью @EnableBinding. Здесь мы делаем привязку к Source (публикующая сторона) и используем объект класса Source для публикации объекта Message в Apache Kafka.
Добавим также файл с настройками:
Следующий шаг — указываем, что output — это наш Source у издателя (некий выходной канал).
Отлично! Для второго приложения будем использовать ту же модель и добавим слой бизнес логики:
Тут также аннотируем наш класс с помощью @EnableBinding. Только уже делаем привязку к Sink (принимающая сторона).
Файл с настройками будет выглядеть следующим образом:
Необходимо указать input — это входной канал у брокера
Все готово. Теперь запускаем наши приложения и с помощью Postman добавляем фильм:
И видим сообщение об успешном добавлении фильма в топик:
Риски внедрения брокеров сообщений
Внедрение брокера сообщений может сопряжено со следующими рисками:
- Неправильный выбор брокера сообщений: неподходящий вариант может привести к проблемам с производительностью и надежностью системы.
- Неправильная настройка: неправильная настройка брокера сообщений может привести к сбоям и потере данных.
- Сложность интеграции: интеграция брокера сообщений с другими компонентами системы может быть сложной и требовать дополнительных ресурсов.
Рекомендации по использованию
Для успешного использования брокера сообщений рекомендуется:
- Анализировать требования и выбирать подходящий вариант.
- Тщательно настраивать брокер сообщений, учитывая особенности системы.
