Примеры Реализации Pub-Sub: Azure Topics, Eventhub, Zeromq, Microservicebus И Т. Д.

Основная идея Паб-Саб довольно просто: " публиковать-подписаться это шаблон обмена сообщениями где отправители Сообщения , называемые издателями, не программируют сообщения для отправки непосредственно конкретным получателям, называемым подписчиками, а вместо этого классифицируют опубликованные сообщения по классам, не зная, какие подписчики, если таковые имеются, могут быть.

Аналогичным образом, подписчики выражают интерес к одному или нескольким классам и получают только те сообщения, которые представляют интерес, без знания того, какие издатели существуют, если таковые имеются».

Бесплатный перевод это может звучать так: " Издатель-подписчик ( Английский издатель-подписчик или Английский паб/саб ) — поведенческий шаблон проектирования передача сообщений, при которой отправители сообщений называются издателями ( Английский издатели ), не привязаны напрямую к программному коду отправки сообщений подписчикам ( Английский подписчики ).

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

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

Модель паб-суб

Давайте немного пофантазируем и попробуем сами разработать систему Pub-sub с нуля.

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

Основной бизнес-процесс в нашей системе может выглядеть так:

Подписчики подписаться на сообщение .
Издатель создает сообщение .
Издатель публикует сообщение в нашей системе.
Сообщение на некоторое время хранится В система .
Система отправляет сообщение всем подписчикам.
Подписчики получить сообщение .
Подписчики обработать сообщение .

Я выделил участников вышеописанного бизнес-процесса:

Издательство.
Их может быть несколько.
Подписчик.
Обычно их несколько, но может и не быть вовсе.
Система.
Это наша система паб-саб.

Все участники работают с Сообщения .

Сообщения — это передаваемые данные.

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

Мы перечислили следующие операции над сообщениями (выделено жирным шрифтом):

Подписаться
Создавать
Публиковать
Держать
Отправлять
Принимать
Ручка

Очереди и асинхронность

Нигде в нашей модели мы не столкнулись с очередями.

Они не упоминаются в определении pub-sub. Также нигде не упоминалась асинхронность.

Но без очереди/очередей pub-sub реализация вряд ли возможна.

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

Например, как быстро потребуется разослать сообщение тысячам подписчиков? Что произойдет, если абонент не успеет обработать предыдущее сообщение? Что делать, если новые сообщения публикуются, а предыдущие сообщения еще не были отправлены? Я не видел реализации pub-sub без очередей, хотя теоретически это возможно.

Итак, очереди.

Очередь Это временное хранилище сообщений, которое работает по принципу «первым поступило — первым отправлено».

Опять же, pub-sub не требует установления последовательности сообщений, но обычно это подразумевается.

Где мы разместим очередь/очереди? Этот вопрос пройдёт золотой нитью через всю нашу дальнейшую дискуссию.

Вопросы реализации

Теперь, пожалуй, начнем формулировать вопросы по нашему бизнес-процессу:

Где и как хранятся адреса издателя и подписчика? В принципе, адреса может хранить любой участник процесса.
Но обычно система выступает в роли брокера и хранит все адреса.
Подписка, что это такое? Наверняка в подписку войдет адрес подписчика .
Кроме того, будет указано " класс сообщения ", своего рода фильтр, определяющий, соответствует ли сообщение данной подписке или нет. Адрес издателя здесь не нужен.
Можем ли мы добавить или удалить подписку в любое время или для этого необходимо остановить работу системы? Если мы добавим или удалим подписку, как это повлияет на уже опубликованные и ожидающие отправки сообщения?
Имеет ли значение формат сообщения? Скорее всего, сообщение будет сериализовано и помещено в пакет. Вместе с пакетом могут передаваться дополнительные параметры, которые размещаются в заголовках пакета.
Как фильтруются сообщения по подписке? Обычно сообщение сразу фильтруется по подпискам на этапе публикации.
Иногда сообщение фильтруется только на этапе отправки сообщения подписчику.
Иногда сообщение фильтруется на стороне абонента.
Что такое фильтры подписки? Фильтры подписки могут представлять собой иерархии, такие как пространства имен, наборы ключей или выражения RegEx.
Что произойдет, если система или абонент не смогут получать сообщения? Система или подписчик могут отказаться принять его, удалить сообщение без предупреждения или просто зависнуть или выйти из строя.
Должен ли я повторно отправить сообщение, если оно не удалось? Повторная отправка (retry) — стандартное решение, если принимающая сторона временно недоступна.
Ключевое слово здесь «временно».
Если принимающая сторона или канал передачи перестали работать на постоянной основе, то повторение отправки никак не поможет, а лишь перегрузит систему/канал связи.
Можно ли настроить алгоритм повторной отправки сообщений? При ненадежных каналах связи этот вопрос может оказаться одним из основных.
Можем ли мы изменить количество повторов, интервал между попытками? Какой алгоритм используется для регулировки интервала между попытками?
Как долго хранятся сообщения? Если абонент долго не отвечает на сообщение, что с ним делать? Следует ли хранить его бессрочно или удалять через определенный интервал?
Кто инициирует отправку сообщения? Абонент может время от времени опрашивать систему на наличие новых сообщений (режим опроса) или система сама отправляет подписчику новое сообщение (режим push).
В первом случае абонент должен знать адрес системы, во втором случае система должна знать адрес абонента.
Во втором случае система более экономно использует как свои ресурсы, так и ресурсы канала передачи данных.
Что произойдет, если абонент перегружен сообщениями? Должен ли он блокировать запись для получения новых сообщений и отправки предупреждений отправителю или молча игнорировать сообщения? А может быть абонент может увеличить (масштабировать) свои ресурсы?

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

Если какие-то из них для вас критичны, постарайтесь найти ответы.

Детали реализации

Я хочу рассмотреть реализации Pub-Sub на примере наиболее популярных программ этого класса.

Если читатель решит, что в этом списке нужно что-то изменить, я обсужу это еще раз.

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

Итак, что сейчас в списке:

Темы служебной шины Azure

Вся система расположена в Microsoft Azure. Реализация, можно сказать, классическая, на основе модели брокер сообщений .

Система Pub-Sub — это централизованный платный сервис, брокер, через который проходят все сообщения.

Здесь регистрируются все издатели и подписчики, здесь же хранятся все их учетные данные.

Здесь абонент регистрирует подписку.

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

Сообщения, выбранные фильтром подписки, попадают в виртуальную очередь.

Абонент сам запрашивает следующее сообщение (опрос), либо система уведомляет абонента о новом сообщении (пуш).

Абонент получает сообщение, после чего указатель сообщения удаляется из виртуальной очереди.

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

Центр событий Microsoft Azure

EventHub сильно отличается от классической реализации.

Основное отличие состоит в том, что EventHub не регистрирует и не хранит подписки, а также не создает и не хранит виртуальные очереди.

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

Они хранятся определенное время, после чего удаляются системой.

Подписчики имеют доступ ко всем сообщениям.

Абонент сам фильтрует сообщения и сохраняет курсор в списке.

С одной стороны, это возлагает на абонента дополнительную функцию.

С другой стороны, EventHub не требует поддержки по подписке, что обеспечивает отличную производительность.

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

Достигается практически полная независимость подписчиков от издателей.

Операция подписки в EventHub является пустой операцией.

Любой клиент может начать читать сообщения в любой момент.

Microsoft BizTalk-сервер

BizTalk существует уже два десятилетия, поэтому не стоит ожидать от него инновационных подходов.

По сути, его механизм Pub-sub, называемый MessageBox, является предшественником Azure Topics. Разница в том, что доступ к нему осуществляется через адаптеры.

Мы не можем просто вызвать функцию API для публикации или получения сообщения, нам нужно использовать адаптеры.

Адаптеры играют роль как издателей, так и получателей сообщений.

КроликMQ

КроликMQ основанный на идеях AMQP протокол, но не его последней версии (1.0), а предыдущих версий: 0-8 и 0-9-1. Эти версии поддерживают так называемые обмены, от которых разработчики AMQP отказались в версии 1.0. Модель обмена элегантно реализует pub-sub для брокера RabbitMQ.

НулевойMQ

ZeroMQ — наследник идей AMQP. Один из создателей AMQP создал ZeroMQ, когда обсуждение версии 1 AMQP зашло в тупик.

ZeroMQ — одна из интересных идей реализации сверхбыстрой системы обмена сообщениями, в том числе с использованием pub-sub. ZeroMQ не имеет централизованного сервиса.

Вся система Pub-sub реализована как часть кода издателя и подписчика.

ZeroMQ — это просто библиотека, поддерживающая очереди.

В простейшей модели программы-подписчики и издатели создают локальные очереди.

Подписчик явно подключается к адресу издателя, после чего в очередь подписчика начинают поступать сообщения из очереди издателя.

Очереди располагаются в адресных пространствах программ-издателей и подписчиков без промежуточного брокера.

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

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

Очереди в ZeroMQ хранятся в памяти, что обеспечивает максимальную производительность, но снижает надежность.

ZeroMQ также реализует более сложные конфигурации.

Например, вы можете создать паб-саб с брокером.

Более того, ZeroMQ позволяет создавать разнообразные архитектуры, не имеющие аналогов в классических системах Pub-sub. Например, вы можете создавать разные варианты распределенных брокеров.

Рекомендую прочитать один из самых успешных описания паб-подписок на веб-сайте ZeroMQ , начиная с основы паб-саба и окончание более сложные модели .

Это займет довольно много времени, но мне, например, это открыло глаза на многие важные аспекты паб-саба.

микросервисбус

Одна из новых реализаций pub-sub. Я включил его в наш список из-за нескольких интересных решений.

microServiceBus основан на темах Azure ServiceBus. Интересно то, что код издателя и подписчика хранится прямо здесь, в Azure. Более того, этот код может загружаться автоматически.

Код реализован на Node.js, что означает хорошую независимость от платформы.

Node.js работает практически на любой операционной системе и устройстве.

Любое устройство, на котором может работать Node.js, может быть либо издателем, либо подписчиком, либо и тем, и другим.

Следуя примеру BizTalk Server, microServiceBus реализует адаптеры для многих систем и протоколов.

Но в отличие от BizTalk адаптеры — это всего лишь полезное дополнение к API. microServiceBus похож на ZeroMQ тем, что ориентирован на разработчиков.

Так же, как и ZeroMQ, он мультиплатформенный, хотя мультиплатформенность ZeroMQ основана на портировании библиотеки на множество языков и на том факте, что базовая библиотека выполнена на C. Мультиплатформенность MicroServiceBus основана на том, что Node .

js портирован на многие операционные системы.

microServiceBus ориентирован как на системную интеграцию, так и на интеграцию устройств (IoT).

Редис

Redis на самом деле не является системой pub-sub, но хранилище данных «ключ-значение» .

Но он на удивление хорошо реализует классику.

паб-саб и показывает замечательную производительность.

Вы можете установить Redis локально или как распределенную службу.

Вы можете добавить возможность сохранять сообщения на диск.

Выбор системы

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

Я никоим образом не пытаюсь ответить на этот вопрос, я лишь намечу схему поиска ответа.

Во-первых, систем pub-sub значительно больше, чем собрано в этой статье.

Во-вторых, я никоим образом не претендую на правильную расстановку акцентов.

Я остановлюсь на системах, которые выделяются чем-то особенным из общего списка.

Сравнительная таблица здесь.

Среда разработки

BizTalk Server можно использовать только с Visual Studio. Для создания различных частей системы используются многочисленные редакторы.

Разработка для других систем в основном сводится к обычной работе с кодом и API системы.

Языки разработки

Имеется в виду разработка программ для издателей и подписчиков; Я назову это клиентским кодом.

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

Клиентский код для Redis, ZeroMQ и RabbitMQ может быть разработан на большом количестве языков.

Вы можете использовать все языки, используемые для промышленных систем: C#, Java, Python, PHP, JavaScript/Node.js, Scala, Ruby. В ZeroMQ большинство языков реализовано как обертки для оригинальной библиотеки, написанной на C. Также существуют оригинальные библиотеки для C#, Java, Erlang и JavaScript. Но по функциональности они немного отстают от оригинальной библиотеки C. Темы Azure ServiceBus и Azure EventHub имеют API C# и REST. Клиентский код microServiceBus написан только на Node.js, но это скорее преимущество, чем недостаток.

Реализация ядра системы

Темы Azure ServiceBus и системы Azure EventHub реализованы как службы SaaS, размещенные в облаке Microsoft Azure. microServiceBus работает поверх тем Azure ServiceBus. В ZeroMQ нет готовой брокерской части, но это можно сделать довольно легко.

Более того, вы можете сделать брокера любой сложности с любым функционалом.

Хорошие программисты часто выбирают ZeroMQ именно из-за этого.

Сервисы RabbitMQ и Redis поставляются в двоичной и исходной форме и могут быть установлены на любые серверные платформы: Windows, Linux, Mac, Unix. ZeroMQ также можно установить на любую платформу.

BizTalk Server реализован как массивный код SQL и .

NET, работающий в службах Windows, и работает только в Windows. Вам понадобится не только лицензия на BizTalk, но и лицензии на Windows и SQL Server.

Надежность и зрелость

BizTalk Server выделяется в этой категории.

Он известен тем, что системы на его основе работают годами без какого-либо обслуживания.

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

Это накладывает свою специфику в отношении надежности.

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

Azure Topics и EventHub — новые системы, но за ними стоит Microsoft, поэтому к надежности претензий нет. Информации по microServiceBus пока нет, так как система только появилась.

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

Производительность

Именно здесь ZeroMQ выделяется.

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

За ZeroMQ следует Redis, затем EventHub.

Масштабируемость

ZeroMQ также лучше всего масштабируется благодаря своей архитектуре и низким требованиям к ресурсам.

Но вам придется уделить особое внимание конструкции системы.

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

Цена

BizTalk Server — самая дорогая система в нашем списке.

Но вы должны понимать, что pub-sub — это лишь малая часть его функционала и BizTalk выбирается совсем по другим критериям.

Некоторые из перечисленных систем являются системами с открытым исходным кодом.

В крайнем случае вы потратите деньги на платную поддержку.

Простота

Чтобы начать работу с ZeroMQ, потребуется всего несколько минут. Redis потребуется немного больше.

Темы Azure ServiceBus, microServiceBus, RabbitMQ и Azure EventHub также довольно легко приступить к разработке.

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

Работающую систему на Azure или RabbitMQ не так просто настроить и масштабировать, как может показаться.

Любой брокер, настроенный в кластерной конфигурации, потребует от вас не только знаний, но и опыта.

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

Теги: #pub/sub #azure #azure service bus #Azure Topics #Azure EventHub #rabbitmq #redis #biztalk #microservicebus #programming #Системный анализ и проектирование #.

NET #node.js #Microsoft Azure

Последнее изменение: 2024-10-19 21:10:22

Вместе с данным постом часто просматривают: