Publisher-Subscriber pattern

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

Also called: Pub/sub messaging

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

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

Асинхронный обмен сообщениями — это эффективный способ отделить отправителей от объектов-получателей и избежать блокирования отправителя для ожидания ответа. Тем не менее использование выделенной очереди сообщений для каждого объекта-получателя не масштабируется эффективным образом для нескольких объектов-получателей. Кроме того, некоторые объекты-получатели могут быть заинтересованы только в подмножестве данных. Как может отправитель объявлять о событиях для всех заинтересованных объектов-получателей, не зная их удостоверений?

Solution

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

• Входной канал обмена сообщениями, используемый отправителем. Отправитель упаковывает события в сообщения, используя известный формат сообщений, и отправляет их через входной канал. The sender in this pattern is also called the publisher.

  Note

  A message is a packet of data. An event is a message that notifies other components about a change or an action that has taken place.

• Один выходной канал обмена сообщениями на объект-получателя. The consumers are known as subscribers.

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

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

Обмен сообщениями c публикацией и подпиской имеет указанные ниже преимущества:

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

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

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

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

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

• Обеспечение выполнения асинхронных рабочих процессов по всему предприятию.

• Улучшение возможности тестирования. Можно отслеживать каналы и проверять или регистрировать сообщения как часть общей стратегии тестирования интеграции.

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

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

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

• Existing technologies. Настоятельно рекомендуется использовать доступные продукты и службы для обмена сообщениями, поддерживающие модель с публикацией и подпиской, а не создавать собственные. In Azure, consider using Service Bus, Event Hubs or Event Grid. К другим технологиях, которые могут использоваться для обмена сообщениями c публикацией и подпиской, относятся Redis, RabbitMQ и Apache Kafka.

• Subscription handling. Инфраструктура обмена сообщениями должна предоставить механизмы, которые объекты-получатели могут использовать для подписки или отмены подписки на доступные каналы.

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

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

  • Topics. Каждый раздел имеет выделенный выходной канал, и каждого объекта-получателя можно подписать на все соответствующие разделы.
  • Content filtering. Сообщения проверяются и распределяются на основе содержимого каждого из них. Каждый подписчик может указать интересующее его содержимое.

• Wildcard subscribers. Рассмотреть возможность разрешения подписчикам подписываться на несколько разделов с помощью подстановочных знаков.

• Bi-directional communication. Каналы в системе с публикацией и подпиской рассматриваются как однонаправленные. If a specific subscriber needs to send acknowledgment or communicate status back to the publisher, consider using the Request/Reply Pattern. Этот шаблон использует один канал для отправки сообщения подписчику и отдельный канал ответа для обратной связи с издателем.

• Message ordering. Порядок, в котором экземпляры объекта-получателя получают сообщения, ненадежный и не обязательно должен совпадать с порядком создания сообщений. Разработайте систему, чтобы гарантировать идемпотентную обработку сообщений. Это поможет исключить любые зависимости в порядке обработки сообщений.

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

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

• Repeated messages. То же сообщение может быть отправлено более одного раза. Например, отправитель может завершить работу ошибкой после публикации сообщения. Затем новый экземпляр отправителя может запуститься и повторить сообщение. Инфраструктура обмена сообщениями должна реализовать обнаружение и удаление (также известное как удаление повторов) дубликатов сообщений на основе идентификаторов сообщений для обеспечения одноразовой доставки сообщений. Кроме того, если используется инфраструктура обмена сообщениями, которая не отменяет дублирование сообщений, убедитесь, что логика обработки сообщений является идемпотентной.

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

• Message scheduling. Сообщение может быть временно запрещено и не будет обрабатываться до определенных даты и времени. Сообщение не должно быть доступным получателю до этого времени.

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

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

Используйте этот шаблон в следующих случаях:

• Приложению требуется распространить информацию значительному числу объектов-получателей.

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

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

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

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

Этот шаблон может оказаться неэффективным в следующих случаях:

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

• Приложение требует взаимодействия с объектами-получателями почти в реальном времени.

Workload design

Архитектор должен оценить, как шаблон издателя или подписчика можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. For example:

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

Example

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

Next steps

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

• Выбор между службами обмена сообщениями Azure.

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

При реализации этого шаблона могут быть важны следующие шаблоны:

• Observer pattern. Шаблон с публикацией и подпиской основан на шаблоне наблюдателя с отделением субъектов от наблюдателей через асинхронный обмен сообщениями.

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

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

Related resources

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