шаблон Publisher-Subscriber

Шаблон Publisher-Subscriber позволяет приложениям асинхронно транслировать события нескольким заинтересованным потребителям, не связывая отправителей и получателей. Этот подход называется обмен сообщениями по модели публикация/подписка.

Контекст и проблема

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

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

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

Решение

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

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

  Замечание

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

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

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

На следующей схеме показаны логические компоненты этого шаблона.

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

Обмен сообщениями в формате pub/sub имеет следующие преимущества:

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

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

• Изолирует неисправности. Сбой подписчика не влияет на издателя или других подписчиков, и брокер сохраняет сообщения до тех пор, пока восстановленный подписчик не будет готов к обработке.

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

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

• Улучшает тестируемость. Каналы поддерживают мониторинг и сообщения доступны для проверки или ведения журнала в рамках стратегии тестирования интеграции.

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

Проблемы и рекомендации

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

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

  • Azure Service Bus для обмена сообщениями, для которых требуются транзакции, упорядочивание, сеансы или очереди недоставленных писем.

  • Azure Event Grid для уведомлений на основе событий с push-доставкой, особенно когда ресурсы Azure изменяют состояние и должны уведомить подписанные компоненты.

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

  Дополнительные сведения см. в разделе Выбор между службами Azure, которые отправляют сообщения. Другие технологии, поддерживающие обмен сообщениями по модели публикации/подписки, включают Redis, RabbitMQ и Apache Kafka.

  Библиотеки, такие как MassTransit и NServiceBus предоставляют встроенную поддержку модели публикации и подписки на Service Bus и других технологиях обмена сообщениями.

• Обработка подписки: Инфраструктура обмена сообщениями должна предоставлять механизмы, которые потребители используют для подписки на доступные каналы или отмены подписки.

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

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

  • Темы: Каждый раздел имеет выделенный выходной канал, и каждый потребитель может подписаться на все соответствующие разделы.

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

  Намеренно выберите степень детализации темы. Широкие темы проще в управлении, но подписчикам приходится отфильтровывать сообщения, которые им не нужны. Узкие разделы сокращают фильтрацию на стороне подписчика, но увеличивают количество разделов для управления. Некоторые брокеры поддерживают подстановочные подписки, например orders.*, что позволяет подписчикам охватывать несколько тем без перечисления каждой из них.

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

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

• Приоритет сообщения: Для некоторых рабочих нагрузок требуется обработка определенных сообщений перед другими. Шаблон очереди приоритетов предоставляет механизм маршрутизации сообщений с более высоким приоритетом до сообщений с более низким приоритетом.

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

• Размер сообщения: Брокеры применяют ограничения размера сообщения. Если размер полезных данных большой, сохраняйте содержимое, такое как файлы или изображения, во внешнюю систему хранения данных, и добавьте ссылку в сообщение. Шаблон Claim-Check описывает этот подход.

• Гарантии доставки и повторяющиеся сообщения: Системы обмена сообщениями предоставляют разные гарантии доставки, которые имеют компромиссы.

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

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

  • Доставка ровно один раз устраняет дубликаты, но добавляет координационную нагрузку и задержку, и её доступность зависит от инфраструктуры сообщений.

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

• Срок действия сообщения: Некоторые сообщения имеют ограниченное время существования. Если получатель не обрабатывает сообщение в течение этого периода, сообщение становится неуместным, и система удаляет его. Задайте метку времени окончания срока действия в данных сообщения, чтобы получатели могли проверить его релевантность перед их обработкой.

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

• Эволюция схемы сообщений: Издатели и подписчики работают независимо, поэтому схемы сообщений меняются со временем. Предпочитайте изменения, совместимые с обратной совместимостью, например добавление необязательных полей, чтобы существующие подписчики продолжали работать. Для изменений, которые нарушают совместимость, используйте версию через имена разделов, например orders.v1 и orders.v2, или через поле версии в метаданных сообщения. Подписчики должны игнорировать поля, которые они не распознают.

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Приложению необходимо распространить информацию значительному числу потребителей.

• Приложение должно взаимодействовать с независимыми разработанными приложениями или службами. Они могут использовать различные платформы, языки программирования или протоколы связи.

• Приложение может отправлять информацию потребителям, не требуя от них ответов в режиме реального времени.

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

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

Этот шаблон может быть не подходит, если:

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

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

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

• Для операции требуется одна атомарная транзакция для издателя и ее потребителей. Сообщения в системе pub/sub по своей природе являются асинхронными и в конечном итоге консистентными. Если вам нужны гарантии транзакций, рассмотрите прямую транзакцию базы данных или шаблон Saga для координации распределенных транзакций.

Проектирование рабочей нагрузки

Оцените, как использовать шаблон Publisher-Subscriber в проектировании рабочей нагрузки для достижения целей и принципов, отраженных в основных элементах рамки Azure Well-Architected Framework. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	Этот шаблон отделяет компоненты, чтобы можно было задать независимые целевые показатели надежности и удалить прямые зависимости. - Анализ режима сбоя RE:03 - RE:07 Фоновые задания
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Этот шаблон представляет четкую границу сегментации безопасности. Используйте его для того, чтобы изолировать подписчиков очереди от издателя на сетевом уровне. - SE:04 Сегментация
Оптимизация затрат фокусируется на поддержании и улучшениирентабельности инвестиций рабочей нагрузки (ROI).	Этот развязанный дизайн поддерживает архитектуры на основе событий, которые соответствуют моделям выставления счетов на основе потребления и помогают избежать чрезмерного выделения ресурсов. - Оптимизация скорости CO:05 - CO:12 Затраты на масштабирование
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды.	Брокер в качестве посредника позволяет изменять реализацию на стороне издателя или подписчика без координации изменений между обоими компонентами. - Разработка рабочей нагрузки OE:06 - Рекомендации по безопасному развертыванию OE:11
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Разъединение издателей и потребителей позволяет оптимизировать вычислительные процессы и код для конкретных задач, которые каждый потребитель обрабатывает в соответствии с заданным типом сообщения. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование

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

Пример

На следующей схеме показана архитектура интеграции предприятия, которая использует Service Bus для координации рабочих процессов и сетки событий для уведомления подсистем событий, происходящих. Дополнительные сведения см. в статье Интеграция предприятия в Azure с использованием очередей сообщений и событий.

На крайнем левом солидная стрелка с меткой HTTPS направлена напрямую от клиентских приложений к значку шлюза API. Клиентские приложения подключаются к Microsoft Entra ID через стрелку, обозначенную как аутентификация. Сплошная стрелка, помеченная HTTPS, ведет от шлюза API к веб-службе REST или простого протокола доступа к объектам (SOAP). Два региона находятся справа от шлюза API. Верхняя средняя область, помеченная как рабочий процесс и оркестрация, включает три значка логических приложений. Пунктирная стрелка указывает от значка логического приложения к Service Bus. Пунктирная стрелка указывает от Service Bus ко второму значку Logic App. Сплошная стрелка с меткой HTTPS указывает от этого приложения логики к программному обеспечению как услуге (SaaS). Неподписанная стрелка отделяется от этой линии и указывает на службы Azure. Еще одна пунктирная стрелка идет от сетки событий к третьему приложению логики. Сплошная стрелка с надписью HTTPS указывает от этого приложения логики к службе SaaS. Из этой линии отделяется стрелка без надписи и указывает на службы Azure. В нижнем среднем регионе помечены очереди, разделы, подписки и события, включая Service Bus и сетку событий. Пунктирная стрелка с надписью "сообщения" указывает на службу, основанную на сообщениях. С правой стороны находится раздел с надписью серверные системы, содержащий три значка: служба SaaS, службы Azure и служба на основе сообщений. Пунктирная стрелка с меткой "события" указывает от служб Azure к Event Grid. Пунктирная стрелка, помеченная как "отправка или извлечение сообщений", указывает от службы, основанной на сообщениях, на Service Bus.

Дальнейшие действия

• Параметры асинхронного обмена сообщениями
• Вам не нужна заказанная доставка

Связанные ресурсы

• Стиль архитектуры на основе событий
• Идемпотентная обработка сообщений
• Интеграция корпоративных систем с Azure с использованием очередей сообщений и событий