Брокеры сообщений

menu icon

Брокеры сообщений

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

Что такое брокер сообщений?

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

Брокеры сообщений — это программные модули или решения промежуточного ПО, ориентированного на обмен сообщениями (MOM). Промежуточное ПО такого типа предоставляет стандартизованные средства обработки потока данных между компонентами приложения, позволяя разработчикам не отвлекаться на это и заниматься основной логикой программ. Также брокер может выступать в качестве распределенного уровня связи, позволяющего приложениям, охватывающим несколько платформ, взаимодействовать друг с другом.

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

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

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

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

Модели брокеров сообщений

Брокеры сообщений работают по двум основным шаблонам (стилям) обмена сообщениями:

  • Двухточечный обмен сообщениями: этот шаблон используется в очередях сообщений с прямой взаимосвязью между отправителем и получателем. Каждое сообщение в очереди отправляется только одному получателю, который получает его только один раз. Двухточечный обмен сообщениями предполагает только однократную обработку сообщения. В качестве варианта применения такого стиля может служить обработка платежей и финансовых транзакций. В таких системах и отправителю, и получателю нужна гарантия, что каждый платеж будет отправлен один и только один раз.
  • Модель издатель/подписчик: этот шаблон обмена сообщениями часто сокращается до «pub/sub». Автор каждого сообщения публикует его в теме, а получатели (которых может быть несколько) подписываются на темы, из которых они хотят получать сообщения. Все опубликованные в теме сообщения отправляются во все подписанные на эту тему приложения. Это чем-то похоже на широковещание, когда между издателем и получателями сообщения установлена связь «один ко многим». Например, если авиакомпания будет рассылать новости о времени посадки или сроках задержки рейсов, то этой информацией могли бы пользоваться несколько сторон: наземные бригады, выполняющие техническое обслуживание и заправку самолетов, работники багажных служб, бортпроводники и пилоты, готовящиеся к следующему рейсу, и операторы табло для информирования пассажиров. Для таких ситуаций лучше всего подходит стиль издатель/подписчик.

Брокеры сообщений в облачных архитектурах

Облачные приложения позволяют реализовать преимущества, присущие облачным вычислениям: это гибкость, масштабируемость и быстрое развертывание. Эти приложения состоят из отдельных маленьких, многократно используемых компонентов, которые называются микросервисами. Каждый микросервис развертывается и работает независимо от остальных. То есть, любой из них можно обновлять, масштабировать или перезапускать, не затрагивая другие сервисы в системе. Микросервисы часто упаковываются в контейнеры и работают как единое целое в составе приложения, однако у каждого из них может быть свой, отличный от других, стек технологий, включающий базу данных и модель управления данными.

Чтобы работать в связке с другими компонентами, микросервисам нужны средства обмена информацией друг с другом. Один из механизмов для создания общей магистрали обмена сообщениями — брокеры сообщений.

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

Брокеры сообщений и API

Для связи между микросервисами обычно используются REST API. Термин «репрезентативная передача состояния» (Representational State Transfer или REST) определяет набор принципов и ограничений, учитываемых разработчиками при разработке веб-служб. Любые службы, созданные с учетом этих ограничений, впоследствии смогут взаимодействовать друг с другом с помощью набора унифицированных общих операторов и запросов без сохранения состояния. Программный интерфейс приложений (API) указывает базовый код, который при условии соответствия правилам REST обеспечивает взаимодействие служб друг с другом.

REST API взаимодействуют по протоколу HTTP. Поскольку HTTP является стандартным транспортным интернет-протоколом, REST API широко известны, часто используются и отлично сочетаются друг с другом. Но так как HTTP — это протокол запроса/ответа, то он лучше всего подходит для ситуаций, когда нужен асинхронный запрос/ответ. Это означает, что службы, отправляющие запросы через REST API, должны разрабатываться с расчетом на немедленный ответ. Если клиент не сможет принять ответ, то сервис, отправивший запрос, окажется заблокирован в ожидании ответа. В обе службы должна быть встроена логика аварийного переключения ресурсов и обработки ошибок.

Брокеры сообщений обеспечивают асинхронный обмен сообщениями между службами, при котором отправителю не нужно ждать ответа получателя. Это повышает отказоустойчивость и надежность систем, в которых реализованы такие службы. Также использование брокеров сообщений упрощает масштабирование систем, так как шаблон издатель/подписчик с легкостью допускает изменение числа служб. Кроме этого, брокеры сообщений отслеживают состояние приемника.

Брокеры сообщений и платформы потоковой обработки событий

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

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

Подробнее об архитектуре, управляемой событиями.

Брокер сообщений и ESB (сервисная шина предприятия)

Сервисная шина предприятия (ESB) — это архитектурный шаблон, иногда используемый в организациях в архитектурах на основе служб. ESB представляет собой централизованную программную платформу, объединяющую протоколы обмена и форматы данных в общий «язык», который могут использовать все службы и приложения в архитектуре. Например, она может переводить запросы, поступившие по одному протоколу (допустим, XML) в другой (допустим, JSON). Преобразование полезной нагрузки сообщений в ESB осуществляется автоматически. Также централизованная платформа обрабатывает и другую логику координации, например обеспечение связи, маршрутизация и обработка запросов.

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

Брокеры сообщений — это «облегченная» альтернатива ESB практически с тем же функционалом (обмен информацией между службами), но гораздо проще и дешевле. Они хорошо подходят для архитектур на основе микросервисов, которые сейчас распространяются все больше, тогда как ESB теряют популярность.

Варианты использования брокеров сообщений

Брокеры сообщений можно реализовать для широкого ряда задач в самых разных отраслях и корпоративных вычислительных средах. Они полезны в тех случаях, когда требуется надежная связь между приложениями и гарантированная доставка сообщений.

Чаще всего брокеры сообщений используются для следующих задач:

  • Финансовые транзакции и обработка платежей: крайне важно быть уверенным, что платеж будет отправлен один и только один раз. Обработка таких транзакционных данных с использованием брокера сообщений дает гарантию, что платежная информация не будет ни потеряна, ни случайно продублирована; обеспечивает подтверждение получения и позволяет системам надежно взаимодействовать даже при сбоях в промежуточных сетях.
  • Обработка и выполнение заказов в электронной коммерции если у вас есть интернет-магазин, то репутация вашего бренда напрямую зависит от надежности вашего веб-сайта и платформы электронной коммерции. Способность брокеров сообщений повышать отказоустойчивость, а также гарантия однократного получения сообщений делают их самым очевидным вариантом для обработки онлайн-заказов.
  • Защита конфиденциальных данных во время хранения и передачи: если ваша отрасль строго регулируется или ваш бизнес постоянно сталкивается с серьезными угрозами безопасности, выбирайте решение для обмена сообщениями с функциями сквозного шифрования.

Брокеры сообщений и IBM Cloud

По мере того как организации модернизируют приложения в ходе освоения облака, брокеры сообщений приобретают все более важное значение и открываются с новой стороны. Многие из самых успешных компаний мира, в том числе 85% компаний из списка Fortune 100, используют брокер сообщений IBM, предназначенный для поддержки современных сред гибкой разработки, архитектур на основе микросервисов и гибридного облака, а также широкого ряда разнообразных систем и требований к связи.

Сделайте следующий шаг: узнайте об IBM Cloud Pak for Integration, в основе которого лежат функции ведущего решения для корпоративного обмена сообщениями IBM MQ.

Начните работать с учетной записью IBM Cloud уже сегодня.