Как тестировать приложения которые работают с очередями сообщений

Автотесты приложений через AMQP

В статье разбираем протокол AMQP, его частную реализацию — RabbitMQ и пишем автотест с помощью PyTest для тестирования очередей сообщений.

Тестирование — одна из самых горячих тем в разработке программного обеспечения. Все согласны с необходимостью качественных проверок и определённого покрытия кода всевозможными тестами. Но как тестировать приложения, работающие не по привычному HTTP протоколу? В статье мы рассмотрим протокол AMQP, его частную реализацию RabbitMQ и протестируем наше простое приложение, разработав автотесты для него.

Андрей Мальчук
Бэкенд разработчик группы частных облаков КРОК.

Введение

AMQP (Advanced Message Queuing Protocol) — открытый протокол прикладного уровня для передачи сообщений между компонентами системы. Идея в том, что отдельные подсистемы или независимые приложения могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.

AMQP основан на трёх понятиях:

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

Точка обмена ( exchange ) — в неё отправляются сообщения. Она распределяет сообщения в одну или несколько очередей. При этом в точке обмена сообщения не хранятся.

Очередь ( queue ) — здесь сообщения хранятся до тех пор, пока не будут забраны клиентом. Клиент всегда забирает сообщения из одной или нескольких очередей.

Producer — клиентское приложение, которое публикует сообщения в exchange.

Consumer — клиентское приложение, которое получает сообщения из очереди.

По сравнению с HTTP, у систем, построенных на очередях сообщений AMQP, есть ряд преимуществ и недостатков.

Плюсы HTTP

• Отладка HTTP-запросов проще, чем в AMQP. Подключаться к очереди сообщений в AMQP придётся только через сторонние утилиты, тогда как HTTP можно отлаживать прямо в браузере.
• Это популярный протокол — его используют практически всегда и везде, а значит и понимает его гораздо больше людей.

Плюсы AMQP

• Надёжность доставки сообщений реализуется «из коробки» — значит не нужно об этом волноваться. Сообщение, которое будет отправлено в AMQP-брокер, будет доставлено и обработано одним из обработчиков очередей AMQP.
• Broadcast — функционал, который позволяет уведомить разные компоненты системы в рамках одного сообщения. Таким образом, можно сократить количество отправляемых сообщений в единицу времени.

Коротко о RabbitMQ и RPC

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

RPC (Remote Procedure Call) — один из шаблонов взаимодействия в распределённых приложениях. Этот протокол позволяет программам вызывать функции и процедуры удалённо таким образом, как будто они представлены локально.

Совмещая RPC и RabbitMQ, мы в итоге получаем отказоустойчивую, распределённую систему для простого вызова функций и последующего агрегирования результатов.

Тестирование AMQP

Существуют разные способы тестирования приложений, основанных на протоколе AMQP. Вот несколько их них:

• Функциональное тестирование;
• Ручное тестирование;
• Автоматизированное тестирование;
• Интеграционное тестирование.

Под функциональным тестированием чаще всего подразумевается непосредственная проверка каждого элемента в тестируемой среде.

Ручное тестирование — проверка всех компонентов или отдельной, в частности, непосредственно человеком, вручную.

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

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

Автотесты на Python

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

Основным инструментом при разработке автотестов будет pytest — библиотека с простым интерфейсом для написания тестов.

Для подключения к RabbitMQ есть множество библиотек, самая распространённая и хорошо документированная — pika.

Устанавливается всё с помощью утилиты pip:

$ pip install pytest pika 

Далее, представим, что у нас есть сервис, который работает по протоколу AMQP и непосредственно через RabbitMQ, в интерфейсе которого реализована простая функция, возвращающая последнее число из последовательности Фибоначчи:

import pika def fib(n): if n == 0: return 0 elif n == 1: return 1 else: return fib(n - 1) + fib(n - 2) def on_request(ch, method, props, body): n = int(body) response = fib(n) ch.basic_publish( exchange="", routing_key=props.reply_to, properties=pika.BasicProperties( correlation_id=props.correlation_id ), body=str(response) ) ch.basic_ack(delivery_tag=method.delivery_tag) connection = pika.BlockingConnection( pika.ConnectionParameters(host="localhost") ) channel = connection.channel() channel.queue_declare(queue="rpc_queue") channel.basic_qos(prefetch_count=1) channel.basic_consume(queue="rpc_queue", on_message_callback=on_request) channel.start_consuming() 

Данный сервис подключается к RabbitMQ, создаёт очередь rpc_queue, из которой принимает сообщения, где тело запроса — это число N, от которого нужно вычислить последнее число из последовательности чисел Фибоначчи.

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

Напишем клиент, который взаимодействует с нашим сервисом с помощью очереди сообщений через RabbitMQ:

import pika import uuid class FibonacciRpcClient: def __init__(self): self.connection = pika.BlockingConnection( pika.ConnectionParameters(host="localhost") ) self.channel = self.connection.channel() result = self.channel.queue_declare(queue="", exclusive=True) self.callback_queue = result.method.queue self.channel.basic_consume( queue=self.callback_queue, on_message_callback=self.on_response, auto_ack=True ) self.response = None self.corr_id = None def on_response(self, ch, method, props, body): if self.corr_id == props.correlation_id: self.response = body def call(self, n): self.response = None self.corr_id = str(uuid.uuid4()) self.channel.basic_publish( exchange="", routing_key="rpc_queue", properties=pika.BasicProperties( reply_to=self.callback_queue, correlation_id=self.corr_id, ), body=str(n) ) self.connection.process_data_events(time_limit=None) return int(self.response) 

В данном примере:

• Устанавливаем соединение к RabbitMQ и подключаемся к очереди rpc_queue;
• Подписываемся на очередь, в которую возвращаются ответы от сервиса при вызове RPC-методов;
• Реализуем функцию on_response, которая проверяет каждый ответ и сверяет correlation_id с тем, который мы отправили. Если идентификатор ответа совпадает — это ответ конкретного запроса, и функция сохраняет ответ в self.response.

Далее мы реализуем автотесты к нашему сервису. Создадим папку tests и в ней файлы conftest.py и test_fibonacci_rpc.py :

. └── tests ├── conftest.py └── test_fibonacci_rpc.py 

Файл conftest.py содержит в себе всевозможные надстройки для pytest . В частности, добавим наш клиент туда для того, чтобы его можно было переиспользовать во всех подтестах, не импортируя вручную. Наш клиент будет иметь свойство Test Fixture — это объект, который можно рассматривать как набор условий, необходимых тесту для выполнения. Например, зачастую фикстуры создаются, чтобы генерировать какие-то данные ещё до теста и возвращать их для использования в тесте.

import pytest # Класс FibonacciRpcClient из примера выше: class FibonacciRpcClient: . @pytest.fixture(scope="module") def fibonacci_rpc(): return FibonacciRpcClient() 

Таким образом, наша фикстура fibonacci_rpc может переиспользоваться во всех тестах как аргумент к каждой тестовой функции.

Файлы с префиксом test_ — это файлы, в которых непосредственно реализованы сами тесты. Напишем несколько тестов, которые проверяют реализацию RPC-метода fib с нашими пользовательскими значениями.

Содержимое файла test_fibonacci_rpc.py :

def test_fibonacci(fibonacci_rpc): # Последний элемент последовательности чисел Фибоначчи от N=0 это 0: assert fibonacci_rpc.call(0) == 0 # От N=10 это 55: assert fibonacci_rpc.call(10) == 55 # От N=25 это 75025: assert fibonacci_rpc.call(25) == 75025 def test_non_number(fibonacci_rpc): try: fibonacci_rpc.call("non-number") except Exception: pass else: assert False, "fib must consume only ints" 

Функции с префиксом test_ означают, что это тестируемые методы, которые запускаются с помощью pytest .

Наш пример в test_fibonacci реализует проверку метода fib на стороне сервиса с положительными аргументами. Директивная assert проверяет условие, выполняющееся в её блоке на True или False . Если условие не выполнилось, тест упадёт с ошибкой, уведомив нас о некорректной работе сервиса.

Пример в test_non_number реализует проверку того же метода fib , только с заведомо некорректными входными параметрами. При вызове такого метода должна произойти ошибка. Если её не произошло, то мы закончим проверку метода с текстом fib must consume only ints.

Таким образом, мы полностью покрыли тестами функцию в нашем сервисе.

Заключение

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

Особенность тестирования сервисов, которые работают на протоколе AMQP, это корректная реализация объекта, который будет эмулировать запросы клиента. Для этого нужно знать некоторые особенности работы самого протокола AMQP, а также нюансы, которые использовали при разработке тестируемого сервиса (название очередей, публичные RPC-методы и прочее).

Очереди сообщений в бэкенд-архитектуре: как построить надежную систему

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

Почему понадобились очереди сообщений

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

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

Чтобы решить вопрос с обработкой объемных запросов, придумали специальную технологию — обмен серверными сообщениями. Она позволяет передать обработку крупной партии данных заинтересованной стороне, при этом сразу ответив клиенту: «Все хорошо, мы работаем над вашей задачей». То есть разные части системы могут обрабатывать операции асинхронно.

Что такое обмен серверными сообщениями и как он устроен

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

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

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

Когда в вашем бэкенд-приложении задействованы очереди, обработка видео выглядит так:

1. Сервер получает запрос на обработку видео от клиента.
2. Он сохраняет видео на сервере и сообщает другому приложению, расположенному на соседнем сервере, что поступил запрос на обработку. Для этого сервер бэкенда формирует специальное сообщение и отправляет его в очередь сообщений.
3. Сервер обработки видео получает запрос от своего коллеги, обрабатывает контент и через шину сообщений сообщает о том, что все обработано.

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

FIFO и LIFO (ФИФО и ЛИФО) — что это такое

Сервисы обмена сообщениями между серверами делятся на два типа:

• Очереди(ФИФО-метод) — «первый пришел и первый ушел» (First in First out). Принцип FIFO означает: сообщение, которое первым попало в очередь, первым же отправляется на обработку.
• Стеки (LIFO) — «пришел последним, а ушел первым» (Last in First out). В отличие от системы FIFO, стек можно представить в виде стопки тарелок: вы кладете тарелки друг на друга и сначала берете верхние тарелки.

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

Сервисы для организации очередей сообщений

Популярные сервисы для организации очередей сообщений — RabbitMQ, Apache Kafka и Redis. Давайте посмотрим, чем они различаются.

RabbitMQ

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

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

Apache Kafka

Apache Kafka — продукт, который реализует систему распределенного журнала событий. Kafka славится своей скоростью работы и масштабируемостью. Из-за способности передавать терабайты данных эту систему очередей сообщений любят разработчики, работающие с Big Data. Например, ее используют в Airbnb, Adidas, Cisco и PayPal.

Redis

Redis создавалась как система хранения данных в оперативной памяти. Изначальное предназначение — ускорение доступа к востребованной информации и построение систем кеширования.

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

Очередь сообщений (Message Queue)

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

Использование очереди сообщений

• Слабое связывание — очереди сообщений создают неявные интерфейсы обмена данными, которые позволяют процессам быть независимыми друг от друга т.е вы просто определяете формат сообщений отправляемых от одного процесса другому.
• Избыточность — Очереди позволяют избежать случаев неэкономного использования ресурсов процесса(например памяти) в результате хранения необработанной (лишней) информации.
• Масштабируемость — очереди сообщений позволяют распределить процессы обработки информации. Таким образом, они позволяют легко наращивать скорость, с которой сообщения добавляются в очередь и обрабатываются.
• Эластичность и возможность выдерживать пиковые нагрузки — очереди сообщений могут выполнять роль своего рода буфера для накопления данных в случае пиковой нагрузки, смягчая тем самым нагрузку на систему обработки информации и не допуская ее отказа.
• Отказоустойчивость — очереди сообщений позволяют отделить процессы друг от друга, так что если процесс, который обрабатывает сообщения из очереди падает, то сообщения могут быть добавлены в очередь на обработку позднее, когда система восстановится.
• Гарантированная доставка — использование очереди сообщений гарантирует, что сообщение будет доставлено и обработано в любом случае (пока есть хотя бы один обработчик).
• Гарантированный порядок доставки — большая часть систем очередей сообщений способны обеспечить гарантии того, что данные будут обрабатываться в определённом порядке (чаще всего в том порядке в котором они поступили).
• Буферизация — очереди сообщений позволяет отправлять и получать сообщения при этом работая с максимальной эффективностью, предлагая буферный слой — процесс записи в очередь может происходить настолько быстро, насколько быстро это в состоянии выполнить очередь сообщений, а не обработчик сообщения.
• Понимание потоков данных — очереди сообщений позволяют выявлять узкие места в потоках данных приложения, легко можно определить какая из очередей забивается, какая простаивает и определить что необходимо делать — добавлять новых обработчиков сообщений или оптимизировать текущую архитектуру.
• Асинхронная связь — очереди сообщений предоставляют возможность асинхронной обработки данных, которая позволяет поместить сообщение в очередь без обработки, позволяя системе обработать сообщение позднее, когда появится возможность.

• Обработку данных
• Буферизацию потоков данных
• Управление процессами
• Интеграцию и взаимодействие систем

Почему SaaS?

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

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

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

Преимущества перехода на облачные очереди сообщений включают в себя:

• Увеличение скорости выхода на рынок: приложения и системы могут быть построены гораздо быстрее.
• Уменьшение сложности: снижение рисков и накладных расходов в стратегическом потенциале. Например вам сейчас кажется что свой собственный сервер с поднятым и сконфигурированным RabbitMQ кажется лучшим решением, то в долгосрочной перспективе при росте нагрузки, требованиях к HA(high availability) ранняя интеграция сторонних сервисов может сыграть свою положительную роль.
• Увеличение масштабируемости: возможность легко масштабировать производительность и функциональность

С чего начать?

• Amazon SQS
• IronMQ
• StormMQ
• Windows Azure Queues

PS Я надеюсь мне удалось заронить каплю сомнения в выбор «поставить свой сервер MQ или использовать сторонний сервис» и заинтересовать в существующих SaaS решениях в области очередей сообщений.

upd: добавил Windows Azure Queues

Брокеры сообщений, или Как происходит взаимодействие в рамках распределённой инфраструктуры

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

Что будет, если ввести этот элемент в вашу архитектуру? И почему это особенно актуально сейчас, когда так широко распространился микросервисный подход к проектированию систем? Обсудим это сегодня. Все подробности — под катом.

Брокер сообщений представляет собой тип построения архитектуры, при котором элементы системы «общаются» друг с другом с помощью посредника. Благодаря его работе происходит снятие нагрузки с веб-сервисов, так как им не приходится заниматься пересылкой сообщений: всю сопутствующую этому процессу работу он берёт на себя.

Можно сказать, что в работе любого брокера сообщений используются две основные сущности: producer (издатель сообщений) и consumer (потребитель/подписчик).

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

Здесь возможны несколько вариантов:

• Сообщение отправляется напрямую от отправителя к получателю.

В этом случае каждое сообщение используется только однократно;

• Схема публикации/подписки.

В рамках этой схемы обмена сообщениями отправитель не знает своих получателей и просто публикует сообщения в определённую тему. Потребители, которые подписаны на эту тему, получают сообщение. Далее на базе этой системы может быть построена работа с распределением задач между подписчиками. То есть выстроена логика работы, когда в одну и ту же тему публикуются сообщения для разных потребителей. Каждый «видит» уникальный маркер своего сообщения и забирает его для исполнения.

Для чего нужны брокеры сообщений?

• Для организации связи между отдельными службами, даже если какая-то из них не работает в данный момент. То есть продюсер может отправлять сообщения, несмотря на то, проявляет ли активность потребитель в настоящее время.
• За счёт асинхронной обработки задач можно увеличить производительность системы в целом.
• Для обеспечения надёжности доставки сообщений: как правило, брокеры обеспечивают механизмы многократной отправки сообщений в тот же момент или через определённое время. Кроме того, обеспечивается соответствующая маршрутизация сообщений, которые не были доставлены.

Недостатки брокеров сообщений:

• Усложнение системы в целом как таковой, так как в ней появляется ещё один элемент. Кроме того, возникает зависимость от надёжности распределённой сети, а также потенциальная возможность возникновения проблем из-за потребности в непротиворечивости данных, так как некоторые элементы системы могут обладать неактуальными данными.
• Из-за асинхронной работы всей системы, а также её распределённого характера могут возникать ошибки, выяснение сути которых может стать непростой задачей.
• Освоение подобных систем является не самым простым вопросом и может занять существенное время.

Когда брокеры сообщений могут быть полезны:

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

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

• Мобильные приложения: здесь возможен вариант с задействованием push-уведомлений, когда множество смартфонов с установленным приложением подписаны на определённую тему. Если в ней публикуется какая-либо новость, то подписанный смартфон выводит уведомление.
• Транзакционные системы: если какое-то действие системы состоит из множества отдельных этапов, каждый из которых выполняется отдельным элементом системы, то в этом случае брокер сообщений может выступить в роли своеобразной «доски уведомлений». Каждый сервис отписывается после того, как его этап общей задачи был выполнен. После этого в работу вступает следующий сервис, обрабатывающий, соответственно, следующий этап общей задачи.

Какие есть брокеры сообщений?

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

Каждый из них обладает определёнными «фишками» и хорошо решает возложенные на него задачи. Например, если одни предназначены для создания инфраструктуры связи между распределёнными частями приложения, другие предназначены для достаточно специфических задач, например «интернета вещей», и функционируют на основе легковесного протокола MQTT. Подобные брокеры служат для сбора статистики, температуры и других показателей с распределённых датчиков, установленных на определённых машинах, элементах конструкций, географически разных точках территории.

Малое время задержки для прохода сообщения по сети, а также возможность двунаправленной связи в реальном времени (так как MQTT является надстройкой над дуплексным протоколом websockets) позволяют реализовывать достаточно интересные применения. Среди них может быть даже управление робототехническими устройствами в реальном времени. При таком управлении задержка не превышает десятков миллисекунд, что вполне допустимо для низкоскоростных устройств. Например, для управления роботами, движущимися в промышленных цехах и использующимися для перевозки деталей от станков или сырья к производственным станкам.

Также информационные системы на базе протокола MQTT используются в автомобильной сфере и в ряде других промышленных областей (HiveMQ).

Apache Kafka и RabbitMQ: что выбрать?

В корпоративных инфраструктурных системах популярностью пользуются Apache Kafka и RabbitMQ. В связи с чем часто возникает вопрос, какую из них выбрать в конкретном случае?

Говоря о RabbitMQ, можно сказать, что он представляет собой классический брокер, в котором присутствуют две описанные выше сущности – продюсер (система, генерирующая сообщения о разнообразных событиях) и подписчик, являющийся получателем этих сообщений.

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

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

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

В рамках этого брокера инициатором информационного обмена является продюсер, только он отправляет сообщение в сеть, в то время как подписчик не может запросить его сам (так называемая «push-доставка сообщений»).

Apache Kafka представляет собой брокер, который, в отличие от RabbitMQ, хранит все сообщения в виде распределённого лога, причём гарантируется, что порядок сообщений отражает последовательность их поступления в систему. Сообщение в этом логе хранится в течение определённого времени, и работа построена таким образом, что продюсеры пишут новые сообщения в систему, а подписчики сами их запрашивают. При надобности организуется хранение сообщений в рамках тем. То есть можно сказать, что происходит определённого рода группировка сообщений в рамках одной темы.

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

В свою очередь, брокер Apache Kafka больше предназначен для построения высоконагруженных систем сферы bigdata, так как сама его парадигма параллельной обработки, репликации позволяет создавать достаточно надёжные системы и обеспечивать неограниченные возможности по масштабированию. Высокая пропускная способность, а также возможности извлечения сообщений из очереди за определённый период времени (так как они хранятся в очереди, как мы сказали ранее, именно в том порядке, в каком были отправлены) являются мощным инструментом для анализа происходящего в историческом разрезе.

Platform V Corax

В экосистеме Сбера для приложений с микросервисной архитектурой есть также свой брокер сообщений.

Platform V Corax – программный продукт, предназначенный для автоматизации развёртывания, масштабирования контейнеризированных приложений и управления ими с использованием платформы Kubernetes путём предоставления REST API. Выполняет функции развёртывания, администрирования и учёта ресурсов инсталляций Kafka.

Platform V Corax – это платформа для работы с потоками данных, обладающая высокой производительностью и отказоустойчивостью. Разработана на базе открытого программного обеспечения Apache Kafka.

Она сохраняет рыночные преимущества свободно распространяемой версии Apache Kafka и имеет контролируемый и сокращённый релизный цикл по сравнению с open source-версией. Функциональность продукта соответствует запросам Enterprise-клиентов.

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

Пример использования Platform V Corax – непрерывная передача информации с конечных устройств в платформу. Данные не только передаются, но и обрабатываются множеством клиентов, которые называются подписчиками (consumers). В роли подписчиков могут выступать приложения и программные сервисы.

Преимущества:

• Горизонтальное масштабирование.
• Высокая скорость передачи сообщений.
• Поддержка транзакций.
• Контроль доступа через SASL.
• TLS-шифрование.
• Аудит изменения конфигурации кластера.

Platform V Corax поставляется вместе с UI-интерфейсом, реализующим все базовые элементы управления сервисом.

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

Выбирая нужный брокер, следует исходить из глубокого понимания вашей системы и её потребностей. Например, если нужно построение сложных сценариев маршрутизации, можно выбрать известный брокер RabbitMQ. Если же вы проектируете высоконагруженные системы, то советуем остановиться на Apache Kafka – он отлично справляется с этой задачей. А если у вас enterprise-разработка – отличным решением будет Platform V Corax.

• Блог компании Сбер
• IT-инфраструктура
• Сетевые технологии
• Микросервисы