Что такое Pub / Sub? Объяснение обмена сообщениями публикации / подписки

Обмен сообщениями Publish / Subscribe, известный как 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 доставляет сообщения подписчикам мгновенно с помощью push-доставки, что делает его идеальным выбором для требований связи почти в реальном времени. Это устраняет необходимость в любом опросе для проверки сообщений в очередях и сокращает задержку доставки приложения.

Легкость развития

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

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

Повышенная масштабируемость и надежность

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

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

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

Улучшения тестируемости

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

Шаблон pub / sub также помогает легко понять происхождение и назначение данных и информационного потока. Это особенно полезно при тестировании вопросов, связанных с:

• Повреждение данных
• Форматирование
• Безопасность

Недостатки паттерна pub / sub

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

Излишняя сложность в небольших системах

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

Потоковое мультимедиа

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

• Видео-конференция
• VOIP
• Общие приложения для потоковой передачи мультимедиа

Примеры использования для обмена сообщениями «публикация / подписка»

Итак, когда же самое время использовать pub / sub?

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

В следующих разделах описаны распространенные варианты использования Pub / Sub.

IoT (Интернет вещей)

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

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

Системный мониторинг и уведомления о событиях

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

Это очень полезно при крупномасштабном развертывании:

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

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

Резервное копирование и репликация базы данных

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

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

Управление журналом

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

Журналы можно фильтровать по проблемам, контрольным журналам, уведомлениям, фоновым задачам и т. Д. И направлять их разным подписчикам, обеспечивая надлежащее управление журналами.

Службы обмена сообщениями pub / sub

Существует множество сервисов обмена сообщениями Pub / Sub, от выделенных брокеров сообщений до облачных предложений. Ниже приведен список некоторых распространенных служб Pub / Sub.

• Apache Kafka. Разработанный Apache, Kafkaимеет надежные функции обмена сообщениями Pub / Sub с журналами сообщений.
• Фэй. Простая служба Pub / Sub, предназначенная для поддержки веб-приложений с серверами, разработанными для NodeJS и Ruby.
• Redis.Это один из самых популярных брокеров сообщений с поддержкой как традиционных очередей сообщений, так и реализаций шаблонов pub / sub.
• Amazon SNS. Amazon Simple Notification Service — это полностью управляемая служба, предлагающая сообщения Pub / Sub.
• Google Pub / Sub. Предложение GCP для реализации службы обмена сообщениями pub / sub.
• Сервисная шина Azure. Надежное решение для службы обмена сообщениями (MaaS), предлагающее шаблон Pub / Sub.

Простой пример: публикация / подписка на сообщения

Поскольку теперь мы понимаем концепции Pub / Sub, давайте рассмотрим простой рабочий процесс с использованием Google Pub / Sub. Он опубликует сообщение в теме и вызовет подписанную функцию Google для печати отправленного сообщения.

Шаг 1. Создание темы

Первый шаг — создать тему в Google Pub / Sub, чтобы мы могли публиковать сообщения по этой теме.

Шаг 2. Настройте триггер

Перейдите в созданную тему (Test_Topic) и нажмите опцию «Запустить функцию Google». Это позволит вам создать функцию Google с созданной темой в качестве триггера.

Шаг 3. Создайте функцию Google (print_message_pubsub_test)

Первый экран позволяет вам назвать функцию Google и настроить тему в качестве триггера. Мы будем использовать Python для создания функции, которая просто захватывает передаваемые данные и отправляет их на Webhook.site.

Кроме того, мы будем использовать библиотеку запросов для создания запроса POST для отправки данных.

Блок кода функции облака:

import base64
import requests


def get_quote(event, context):
   # Decode the Message Data
   message = base64.b64decode(event['data']).decode('utf-8')

   # Create Request
   url = "https://webhook.site/xxxxxxx-xxxx-xxxx-xxxx-739c28ebd7ad"
   request_headers = {"Content-type": "application/json"}
   request_data = {"quote": message}

   response = requests.post(url, data=request_data, headers=request_headers)

   # Print Response
   print(response.status_code)
   print(response.text)

После успешного развертывания функции вы заметите, что она указывает Test_Topic в качестве триггера для функции.

Шаг 4. Настройте издателя

На этом этапе давайте создадим простую программу Python, которая будет выступать в роли издателя.

Мы будем использовать библиотеку Google Cloud pubsub_v1, чтобы создать клиент Publisher и получить случайную вдохновляющую цитату от quotable.io. Затем мы опубликуем объединенную строку с именем автора и цитатой в тему (Test_Topic)

message_publish.py

from google.oauth2 import service_account
from google.cloud import pubsub_v1
import requests

# Create Authentication Credentials
project_id = "test-applications-xxxxx"
topic_id = "Test_Topic"
gcp_credentials = service_account.Credentials.from_service_account_file('test-applications-xxxx-xxxxxxxxxx.json')

# Create Publisher Client
publisher = pubsub_v1.PublisherClient(credentials=gcp_credentials)
topic_path = publisher.topic_path(project_id, topic_id)

# Get a Random Quote
response = requests.get("https://api.quotable.io/random")
json_response = response.json()
message = f"{json_response['author']} - {json_response['content']}"

# Publish the Message
data = message.encode("utf-8")
future = publisher.publish(topic_path, data)

# Print Result
print(f"Published messages to {topic_path} - {future.result()}.")

Вот и все! Мы успешно настроили конвейер обмена сообщениями. Когда мы запускаем сценарий message_publish, он публикует данные в Test_Topic и запускает функцию Google Cloud (print_message_pubsub_test), которая отправляет данные на сайт Webhook.

Мы можем видеть сообщения, опубликованные в теме, в теме Pub / Sub.

В журналах облачной функции Google будет указано, что функция была запущена.

Наконец, мы можем увидеть все сообщения, которые были получены сайтом Webhook.site, как показано ниже.

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

Простое и эффективное общение

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

Pub / Sub можно использовать для создания асинхронных масштабируемых потоков сообщений с минимальными задержками доставки благодаря всем преимуществам. Которые он предлагает по сравнению с традиционными брокерами сообщений.