Что такое и зачем нужна модель издатель/подписчик — pub/sub

Модель pub/sub — средство передачи сообщений между двумя сторонами, называемыми издателем и подписчиками. Прежде всего pub/sub используется в системах управления событиями, где компоненты реагируют на изменения состояния системы.

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

Pub/sub представляет собой платформу для обмена сообщениями между издателями, которые создают и отправляют сообщения и подписчиками, которые их получают. При этом издатели не отправляют сообщения подписчикам напрямую в режиме «точка-точка». Вместо этого используется посредник — брокер, который группирует сообщения в сущности, называемые топиками или темами.

Pub/sub поддерживает работу неограниченного числа издателей, отправляющих данные в топики, а также неограниченного числа подписчиков, их получающих. Также важно знать, что каждый компонент pub/sub одновременно может быть как издателем, так и подписчиком.

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

В процессе выполнения заказа с помощью pub/sub приложение обеспечивает правильную и оперативную маршрутизацию сообщений.

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

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

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

Слабая связь между системными компонентами. Pub/sub разделяет логику коммуникаций и бизнес-логику, позволяя изолировать компоненты. Изоляция упрощает поддержку кода приложений и делает их надежнее.

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

Интеграция с сервисами, созданными на разных языках. Pub/sub не привязан к определенному языку программирования и протоколу передачи данных.

Гибкая масштабируемость. Логика коммуникаций и бизнес-логика — это отдельные объекты, поэтому системы, использующие pub/sub, масштабируются без сбоев. Вдобавок разработчики ПО могут перепроектировать архитектуру топика брокера сообщений, не заботясь о бизнес-логике.

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

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

Маршрутизация. Pub/sub позволяет настроить маршрутизацию сообщений от издателя до группы подписчиков. Вдобавок возможна доставка сообщения до конкретного экземпляра подписчика.

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

Модульность. Системы, созданные на основе pub/sub, позволяют разработчикам разделить систему на модули на основе бизнес-логики приложений. Интеграция с сервисами, созданными на разных языках. Pub/sub не зависит от языка программирования, протокола передачи данных или конкретной технологии. Следовательно брокер сообщений может быть легко интегрирован в приложение с помощью любого языка программирования. Кроме того, pub/sub может использоваться в качестве моста, обеспечивающего взаимодействие между компонентами, построенными на разных языках, управляя связями между ними.

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

Скорость отклика. В pub/sub связь асинхронная, что позволяет и модули программировать асинхронно. Доставка сообщений не блокирует издателя. Он возвращается к своей задаче после отправки сообщения. Точно так же подписчик прерывается только в момент публикации сообщения в топике.

Упрощение тестирования. Pub/sub делает тестирование модульным, поскольку бизнес-логика не связана с брокером сообщений. Модульность позволяет отдельно тестировать и оптимизировать каждый модуль. Такой подход значительно снижает сложность тестирования.

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

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

Pub/sub решает множество задач, например:

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