для чего нужны брокеры сообщений
Установка и управление RabbitMQ
Любой опытный системный администратор знает, что иногда откладывание задач на потом очень полезно и даже необходимо, особенно если задача трудоёмкая и отнимает много ресурсов. Для этого необходим брокер сообщений – программа, которая принимает сообщения (задачи) от различных отправителей (веб-приложений), формирует из них очередь, а затем распределяет их между рабочими процессами.
В данной статье речь пойдёт о проекте RabbitMQ – связке открытых приложений для осуществления функций брокера сообщений, которая реализует протокол Advanced Message Queuing Protocol (AMQP).
Сообщения, брокеры сообщений и очерёдность
Обмен сообщениями – это способ обмена определёнными данными между процессами, приложениями, виртуальными и физическими серверами. Эти сообщения, выполняющие некоторые вычислительные функции, могут содержать практически что угодно, от простого текста до больших блоков двоичных данных. Для корректного выполнения этого процесса необходима сторонняя программа – это и есть брокер сообщений (англ. Message Broker).
Брокер сообщений – это, как правило, группа приложений, каждый отдельный компонент которой предназначен для обработки определённого этапа обмена сообщениями: дл приёма сообщения, определении его в очередь и передаче сообщения рабочему процессу, ответственному за его выполнение. Часто вместо полноценных решений используются программы, изначально не предназначенные для этой работы (базы данных, демон cron, и т.д.); они просто создают очередь сообщений (что технически представляет бесконечные буферы), а затем передают их дл автоматической обработки либо для опроса.
Зачем нужны брокеры сообщений?
Брокеры сообщений выступают в роли посредника между различными сервисами (веб-приложениями). Они существенно снижают нагрузку и сокращают время доставки сообщений, поскольку задачи, на обработку которых уходит некоторое время, распределяются между рабочими процессами, предназначенными исключительно для выполнения этих задач. Они обеспечивают надёжный канал передачи сообщений от одного приложения другому.
Когда нужны брокеры сообщений?
В целом, основная функциональность брокеров сообщений охватывает множество областей, в том числе, но не ограничиваясь:
Краткий обзор RabbitMQ
RabbitMQ (вышел в 2007) – это один из наиболее популярных брокеров сообщений с открытым исходным кодом, который поставляется по лицензии Mozilla Public License v1.1 как реализация протокола Advanced Message Queuing Protocol. Разработанный на языке Erlang, RabbitMQ довольно прост в использовании и установке.
Как работает RabbitMQ?
RabbitMQ предоставляет интерфейс, соединяющий отправителей (Publishers) с получателями (Consumers) при помощи брокера, который распределяет данные в соответствующие списки – очереди сообщений (Message Queues).
Преимущества RabbitMQ
В отличие от других решений, RabbitMQ является полноценным стеком приложений, а не простой базой для применения выбранных вами приложений. Он предоставляет все необходимые инструменты в комплексе.
Краткий обзор AMQP
AMQP (Advanced Message Queuing Protocol) – это широко распространённый открытый стандарт для распространения и передачи сообщений. Как протокол и стандарт, он устанавливает общую основу для взаимодействия различных приложений и брокеров сообщений и устраняет проблемы, вызванные индивидуальным проектированием программ.
Установка RabbitMQ
Пакеты RabbitMQ поставляются системами CentOS/RHEL и Ubuntu/Debian. Но, как правило, такие пакеты устаревшие. Потому рекомендуется скачать и установить RabbitMQ вручную.
Примечание: Все действия руководства рекомендуется выполнять на свежем сервере, чтобы не нарушить работу запущенных ранее приложений и не вызвать сбой настроек.
Установка RabbitMQ в CentOS/RHEL
Прежде чем приступить к установке RabbitMQ, нужно установить зависимости программы, одной из которых является Erlang. Однако, прежде всего необходимо обновить систему и стандартные приложения; для этого запустите:
Для установки Erlang используйте команды:
Теперь можно установить RabbitMQ:
Установка RabbitMQ в Ubuntu 13/Debian 7
Процесс установки RabbitMQ в Ubuntu/Debian подобен установке в CentOS.
Для начала нужно обновить стандартные пакеты:
Включите репозиторий приложения RabbitMQ:
echo «deb http://www.rabbitmq.com/debian/ testing main» >> /etc/apt/sources.list
Добавьте ключ проверки пакета:
Снова обновите систему:
Теперь можно загрузить и установить RabbitMQ:
sudo apt-get install rabbitmq-server
Чтобы при запуске было обработано максимальное количество подключений, откройте и отредактируйте в nano следующий конфигурационный файл:
sudo nano /etc/default/rabbitmq-server
Раскомментируйте строку limit (просто удалите символ #), а затем сохраните и закройте файл (CTRL+X + Y).
Управление RabbitMQ
Как говорилось ранее, брокер RabbitMQ очень прост в использовании. В данном разделе приведены инструкции по управлению и настройке RabbitMQ.
Включение консоли управления
Консоль управления RabbitMQ (RabbitMQ Management Console) – это один из доступных плагинов, позволяющий мониторить процессы сервера RabbitMQ через графический пользовательский веб-интерфейс.
При помощи этой консоли можно:
Чтобы включить консоль RabbitMQ, запустите команду:
sudo rabbitmq-plugins enable rabbitmq_management
Теперь можно открыть консоль при помощи любого удобного браузера:
Стандартные имя и пароль – guest.
Примечание: Запустив консоль после запуска сервиса, не забудьте перезапустить его, чтобы обновить настройки.
Управление RabbitMQ в CentOS/RHEL
После установки приложение RabbitMQ не будет запускаться автоматически при загрузке системы.
Чтобы настроить автозапуск RabbitMQ, выполните:
chkconfig rabbitmq-server on
Для запуска, остановки, перезапуска и проверки состояния используйте команды:
# Запуск:
/sbin/service rabbitmq-server start
# Остановка:
/sbin/service rabbitmq-server stop
# Перезапуск:
/sbin/service rabbitmq-server restart
# Проверка статуса:
/sbin/service rabbitmq-server status
Управление RabbitMQ в Ubuntu/Debian
Чтобы запустить, остановить перезапустить и проверит статус приложения в Ubuntu и Debian, используйте:
# Запуск:
service rabbitmq-server start
# Остановка:
service rabbitmq-server stop
# Перезапуск:
service rabbitmq-server restart
# Проверка статуса:
service rabbitmq-server status
Готово! Теперь на сервере есть готовый к работе брокер сообщений.
Настройка RabbitMQ
RabbitMQ поставляется со стандартными настройками. В целом, они довольно надёжны инее требуют редактирования.
Чтобы получить информацию о пользовательской настройке RabbitMQ, обратитесь к документации приложения.
Брокеры сообщений
Что такое брокер сообщений?
Брокер сообщений — это программное обеспечение для связи между приложениями, системами и службами, помогающее им обмениваться информацией друг с другом. Это делается посредством перевода сообщений из одного формального протокола обмена сообщениями в другой. Таким образом независимые службы могут «общаться» между собой напрямую, даже если они написаны на разных языках или реализованы на разных платформах.
Брокеры сообщений — это программные модули или решения промежуточного ПО, ориентированного на обмен сообщениями (MOM). Промежуточное ПО такого типа предоставляет стандартизованные средства обработки потока данных между компонентами приложения, позволяя разработчикам не отвлекаться на это и заниматься основной логикой программ. Также брокер может выступать в качестве распределенного уровня связи, позволяющего приложениям, охватывающим несколько платформ, взаимодействовать друг с другом.
Брокеры сообщений проверяют, хранят, маршрутизируют сообщения и доставляют их в место назначения. Они выступают в качестве брокеров между разными приложениями: для отправления сообщений отправителям необязательно знать, где находятся получатели, активны ли они и сколько их всего. Это упрощает разделение процессов и услуг внутри систем.
Чтобы обеспечить надежное хранение сообщений и гарантированную доставку, в брокерах часто используется очередь сообщений — вспомогательная структура или компонент, который хранит и упорядочивает сообщения, пока они не будут обработаны приложениями-получателями. Сообщения в очереди хранятся в том же порядке, в котором они были переданы, до тех пор, пока не будет подтверждено их получение.
Брокеры сообщений работают по принципу асинхронного обмена сообщениями (15:11) между приложениями. Эта модель предотвращает потерю ценных данных и поддерживает функционирование систем даже при нестабильной связи или высоких задержках, присущих общедоступным сетям. При асинхронном обмене сообщениями сообщения будут доставлены один (и только один) раз в том же порядке, в котором были отправлены.
В брокеры сообщений могут входить администраторы очередей для взаимодействия между несколькими очередями, а также инструменты маршрутизации данных, перевода сообщений, хранения и управления состоянием клиента.
Модели брокеров сообщений
Брокеры сообщений работают по двум основным шаблонам (стилям) обмена сообщениями:
Брокеры сообщений в облачных архитектурах
Облачные приложения позволяют реализовать преимущества, присущие облачным вычислениям: это гибкость, масштабируемость и быстрое развертывание. Эти приложения состоят из отдельных маленьких, многократно используемых компонентов, которые называются микросервисами. Каждый микросервис развертывается и работает независимо от остальных. То есть, любой из них можно обновлять, масштабировать или перезапускать, не затрагивая другие сервисы в системе. Микросервисы часто упаковываются в контейнеры и работают как единое целое в составе приложения, однако у каждого из них может быть свой, отличный от других, стек технологий, включающий базу данных и модель управления данными.
Чтобы работать в связке с другими компонентами, микросервисам нужны средства обмена информацией друг с другом. Один из механизмов для создания общей магистрали обмена сообщениями — брокеры сообщений.
Брокеры сообщений часто используются для управления обменом сообщениями между локальными системами и облачными компонентами в гибридных облачных средах. Использование брокера сообщений дает больше контроля над связью между службами и гарантирует, что данные будут пересылаться между компонентами приложения безопасно, надежно и эффективно. Аналогичную роль брокеры могут играть в интеграции мультиоблачных сред, обеспечивая связь между задачами и средами выполнения, работающими на разных платформах. Также эта технология отлично подходит для бессерверных вычислений, подразумевающих запуск отдельных облачных служб по предварительному запросу.
Брокеры сообщений и 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 уже сегодня.
Понимание брокеров сообщений. Изучение механики обмена сообщениями посредством ActiveMQ и Kafka. Глава 1
Начал перевод небольшой книги:
«Understanding Message Brokers«,
автор: Jakub Korab, издательство: O’Reilly Media, Inc., дата издания: June 2017, ISBN: 9781492049296.
Буду выкладывать законченные главы по мере перевода.
ГЛАВА 1
Введение
Межсистемный обмен сообщениями — это одна из наименее понимаемых областей ИТ. Как разработчик или архитектор, вы можете быть хорошо знакомы с различными фреймфорками и базами данных. Однако, вполне вероятно, что у вас есть только мимолетное знакомство с тем, как работают технологии обмена сообщениями, основанные на брокере. Если вы так себя и чувствуете, не волнуйтесь, вы в хорошей компании.
Люди обычно контактируют с инфраструктурой обмена сообщениями очень ограниченно. Нередко подключаются к системе, созданной давным-давно, или загружают дистрибутив из интернета, устанавливают его в ПРОМ и начинают писать под него код. После запуска инфраструктуры в ПРОМ, результаты могут быть неоднозначными: потеря сообщений при сбоях, отправка не работает так, как вы ожидали, или брокеры «подвешивают» ваших продьюсеров или не отправляют сообщения вашим потребителям.
Распространенный сценарий, когда ваш код обмена сообщениями работает отлично, до поры до времени. Пока не перестает работать. Этот период усыпляет бдительность и дает ложное чувство безопасности, что приводит к еще большему коду, основанному на ложных представлениях о фундаментальном поведении технологии. Когда что-то начинает идти не так, вы сталкиваетесь с неудобной истиной: что вы действительно не поняли базовое поведение продукта или компромиссы, выбранные авторами, такие как, производительность против надежности, или транзакционность против горизонтальной масштабируемости.
Без глубокого понимания того, как работают брокеры, люди делают, казалось бы, разумные утверждения об их системах обмена сообщениями, такие как:
Эта книга научит вас рассуждать о системах обмена сообщениями, основанных на брокерах, сравнивая и противопоставляя две популярные технологии брокеров: Apache ActiveMQ и Apache Kafka. Здесь будут изложены примеры использования и стимулы разработки, которые привели к тому, что их разработчики использовали совершенно разные подходы к одной и той же области — обмену сообщениями между системами с промежуточным брокером. Мы рассмотрим эти технологии с нуля и выделим влияние различных вариантов дизайна на этом пути. Вы получите глубокое понимание обоих продуктов, понимание того, как их следует и не следует использовать, и понимание того, на что следует обращать внимание при рассмотрении других технологий обмена сообщениями в будущем.
Прежде чем мы начнем, давайте пройдемся по основам.
Что такое Система обмена сообщениями и зачем она нужна
Чтобы два приложения могли общаться друг с другом, они должны сначала определить интерфейс. Определение этого интерфейса включает выбор транспорта или протокола, такого как HTTP, MQTT или SMTP и согласование форматов сообщений, которыми будут обмениваться системы. Это может быть строгий процесс, такой как определение схемы XML с требованиями к затратам на полезную нагрузку (payload) сообщения, или это может быть гораздо менее формально, например, соглашение между двумя разработчиками о том, что некоторая часть HTTP-запроса будет содержать идентификатор клиента.
Пока формат сообщений и порядок их отправки между системами согласованы, они смогут взаимодействовать друг с другом, не заботясь о реализации другой системы. Внутренности этих систем, такие как язык программирования или использованный фреймфорк, могут со временем меняться. До тех пор, пока поддерживается сам контракт, взаимодействие может продолжаться без изменений с другой стороны. Эти две системы эффективно расцеплены (разделены) этим интерфейсом.
Системы обмена сообщениями, как правило, предусматривают участие посредника между двумя системами, которые взаимодействуют для дальнейшего расцепления (разделения) отправителя от получателя или получателей. При этом система обмена сообщениями позволяет отправителю отправить сообщение, не зная, где находится получатель, активен ли он или сколько их экземпляров.
Рассмотрим пару аналогий разновидностей проблем, которые решает система обмена сообщениями, и введем некоторые основные термины.
Point-to-Point
Александра идет на почту, чтобы отправить Адаму посылку. Она подходит к окошку и вручает сотруднику посылку. Сотрудник забирает посылку и выдает Александре квитанцию. Адаму не нужно быть дома в момент отправки посылки. Александра уверена, что посылка будет доставлена Адаму в какой-то момент в будущем и может продолжать заниматься своими делами. Позже в какой-то момент Адам получает посылку.
Это пример модели обмена сообщениями точка-точка. Почтовое отделение здесь действует как механизм распределения посылок, гарантируя, что каждая посылка будет доставлена один раз. Использование почтового отделения отделяет акт отправки посылки от доставки посылки.
В классических системах обмена сообщениями модель «точка-точка» реализуется через очереди. Очередь действует, как буфер FIFO (первый вошел, первый вышел), на который может подписаться один или несколько потребителей. Каждое сообщение доставляется только одному из подписанных потребителей. Очереди обычно пытаются справедливо распределять сообщения между потребителями. Только один потребитель получит данное сообщение.
К очередям применяется термин «надежные» («durable»). Надежность — это свойство сервиса, которое гарантирует, что система обмена сообщениями будет сохранять сообщения при отсутствии активных подписчиков до тех пор, пока потребитель не подпишется на очередь для доставки сообщений.
Надежность часто путают с персистентностью и, хотя эти два термина взаимозаменяемы, они выполняют разные функции. Персистентность определяет, записывает ли сообщение система обмена сообщениями в какого-либо рода хранилище между получением и отправкой его потребителю. Сообщения, отправляемые в очередь, могут быть или не быть персистентными.
Обмен сообщениями типа «Точка-точка» используется, когда вариант использования требует однократного действия с сообщением. В качестве примера можно привести внесение средств на счет или выполнение заказа на доставку. Мы обсудим позже, почему система обмена сообщениями сама по себе неспособна обеспечить однократную доставку и почему очереди могут в лучшем случае обеспечить гарантию доставки хотя бы один раз.
Издатель-Подписчик
Габриэлла набирает номер конференции. Пока она подключена к конференции, она слышит все, что говорит спикер, вместе с остальными участниками вызова. Когда она отключается, она пропускает то, что сказано. При повторном подключении она продолжает слышать, что говорят.
Это пример модели обмена сообщениями публикация-подписка. Конференц-связь выступает, как широковещательный механизм. Говорящий человек не заботится о том, сколько людей в настоящее время присоединились к звонку — система гарантирует, что любой подключившийся в настоящий момент услышит, что говорится.
В классических системах обмена сообщениями модель обмена сообщениями «публикация-подписка» реализуется через топики. Топик предоставляет такой же способ широковещания, как и механизм конференц-связи. Когда сообщение отправляется в топик, оно распределяется по всем подписанным пользователям.
Топики обычно ненадежные (nondurable). Как и слушатель, который не слышит, что говорится на конференц-звонке, когда слушатель отключается, подписчики топика пропускают любые сообщения, которые отправляются в тот момент, когда они находятся в автономном режиме. По этой причине можно сказать, что топики предоставляют гарантию доставки не более одного раза для каждого потребителя.
Обмен сообщениями типа «публикация-подписка» обычно используется, когда сообщения носят информационный характер, и потеря одного сообщения — не особо значима. Например, топик может передавать показания температуры от группы датчиков один раз в секунду. Система, которая интересуется текущей температурой и которая подписывается на топик, не будет переживать, если она пропустит сообщение — другое поступит в ближайшее время.
Гибридные модели
Веб-сайт магазина помещает сообщения о заказах в «очередь сообщений». Основным потребителем этих сообщений является исполнительная система. Кроме того, система аудита должна иметь копии этих сообщений о заказах для последующего отслеживания. Обе системы не могут пропускать сообщения, даже если сами системы в течение некоторого времени недоступны. Веб-сайт не должен знать о других системах.
Сценарии использования часто требуют совмещения моделей обмена сообщениями «публикация-подписка» и «точка-точка», например, когда нескольким системам требуется копия сообщения, и для предотвращения потери сообщения требуется как надежность, так и персистентность.
В этих случаях требуется адресат (destination) (общий термин для очередей и топиков), который распределяет сообщения в основном как топик, так, что каждое сообщение отправляется в отдельную систему, заинтересованную в этих сообщениях, но и также в которой каждая система может определить несколько потребителей, которые получают входящие сообщения, что больше похоже на очередь. Тип чтения в этом случае — один раз для каждой заинтересованной стороны. Эти гибридные адресаты часто требуют надежности (durability), так что, если потребитель отключается, сообщения, которые отправляются в это время, принимаются после повторного подключения потребителя.
Гибридные модели не новы и могут применяться в большинстве систем обмена сообщениями, включая как ActiveMQ (через виртуальные или составные адресаты, которые объединяют топики и очереди), так и Kafka (неявно, как фундаментальное свойство дизайна её адресата).
Теперь, когда у нас есть некоторая базовая терминология и понимание того, для чего нам могла бы пригодиться система обмена сообщениями, давайте перейдем к деталям.