Настройка в приложении возможности асинхронно объявлять событие для нескольких объектов-получателей без взаимозависимости между отправителями и получателями.
Также называется: pub/sub messaging
Контекст и проблема
В облачных и распределенных приложениях при возникновении событий компоненты системы часто должны предоставлять сведения об этом другим компонентам.
Асинхронный обмен сообщениями — это эффективный способ отделить отправителей от объектов-получателей и избежать блокирования отправителя для ожидания ответа. Тем не менее использование выделенной очереди сообщений для каждого объекта-получателя не масштабируется эффективным образом для нескольких объектов-получателей. Кроме того, некоторые объекты-получатели могут быть заинтересованы только в подмножестве данных. Как может отправитель объявлять о событиях для всех заинтересованных объектов-получателей, не зная их удостоверений?
Решение
Представляем систему асинхронного обмена сообщениями, которая включает в себя следующее:
Входной канал обмена сообщениями, используемый отправителем. Отправитель упаковывает события в сообщения, используя известный формат сообщений, и отправляет их через входной канал. Отправитель в этом шаблоне также называется издателем.
Примечание.
Сообщение — это пакет данных. Событие представляет собой сообщение, которое уведомляет другие компоненты об изменении или действии, которое было выполнено.
Один выходной канал обмена сообщениями на объект-получателя. Объекты-получатели известны как подписчики.
Механизм копирования каждого сообщения из входящего канала в выходные для всех подписчиков, заинтересованных в этом сообщении. Обычно эта операция обрабатывается посредником, например брокером сообщений или шиной событий.
На следующей схеме показаны логические компоненты этого шаблона:
Обмен сообщениями c публикацией и подпиской имеет указанные ниже преимущества:
Разделение подсистем, которые по-прежнему должны взаимодействовать. Подсистемами можно управлять независимо друг от друга, и сообщениями можно должным образом управлять, даже если один или несколько получателей находятся в автономном режиме.
Увеличение масштабируемости и повышение отклика отправителя. Отправитель может быстро отправить одно сообщение во входной канал, а затем вернуться к своим основным обязанностям обработки. Инфраструктура обмена сообщениями отвечает за обеспечение доставки сообщений заинтересованным подписчикам.
Это повышает надежность. Асинхронный обмен сообщениями помогает приложениям продолжать работать без проблем под повышенной нагрузкой и более эффективно обрабатывать временные сбои.
Поддержка отложенной обработки или обработки по расписанию. Подписчики могут ждать нерабочего времени, чтобы получить сообщения, или же сообщения могут направляться либо обрабатываться согласно заданному расписанию.
Обеспечение более простой интеграции между системами, использующими различные платформы, языки или протоколы связи, как и между локальными системами и приложениями, работающими в облаке.
Обеспечение выполнения асинхронных рабочих процессов по всему предприятию.
Улучшение возможности тестирования. Можно отслеживать каналы и проверять или регистрировать сообщения как часть общей стратегии тестирования интеграции.
Разделение областей ответственности для ваших приложений. Каждое приложение может сосредоточиться на основных возможностях, пока инфраструктура обмена сообщениями обрабатывает все необходимое для надежного перенаправления сообщений нескольким объектам-получателям.
Проблемы и рекомендации
При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.
Существующие технологии. Настоятельно рекомендуется использовать доступные продукты и службы для обмена сообщениями, поддерживающие модель с публикацией и подпиской, а не создавать собственные. В Azure рекомендуется использовать служебная шина, Центры событий или сетку событий. К другим технологиях, которые могут использоваться для обмена сообщениями c публикацией и подпиской, относятся Redis, RabbitMQ и Apache Kafka.
Обработка подписки. Инфраструктура обмена сообщениями должна предоставить механизмы, которые объекты-получатели могут использовать для подписки или отмены подписки на доступные каналы.
Безопасность. Подключение к любому каналу сообщений должно быть ограничено политикой безопасности для предотвращения перехвата со стороны неавторизованных пользователей или приложений.
Подмножества сообщений. Подписчики обычно заинтересованы только в подмножестве сообщений, распределяемых издателем. Службы обмена сообщениями часто позволяют подписчикам сузить набор получаемых сообщений следующим образом:
- По разделам. Каждый раздел имеет выделенный выходной канал, и каждого объекта-получателя можно подписать на все соответствующие разделы.
- Путем фильтрации содержимого. Сообщения проверяются и распределяются на основе содержимого каждого из них. Каждый подписчик может указать интересующее его содержимое.
Подписчики с подстановочными знаками. Рассмотреть возможность разрешения подписчикам подписываться на несколько разделов с помощью подстановочных знаков.
Двусторонняя связь. Каналы в системе с публикацией и подпиской рассматриваются как однонаправленные. Если определенному подписчику необходимо отправить подтверждение или сообщить о состоянии обратно издателю, рассмотрите возможность использования шаблона запроса и ответа. Этот шаблон использует один канал для отправки сообщения подписчику и отдельный канал ответа для обратной связи с издателем.
Упорядочивание сообщений. Порядок, в котором экземпляры объекта-получателя получают сообщения, ненадежный и не обязательно должен совпадать с порядком создания сообщений. Разработайте систему, чтобы гарантировать идемпотентную обработку сообщений. Это поможет исключить любые зависимости в порядке обработки сообщений.
Приоритет сообщений. Некоторые решения могут требовать обработки сообщений в определенном порядке. Шаблон очереди с приоритетом предоставляет механизм, обеспечивающий доставку определенных сообщений раньше других.
Сообщения о сбое. Неправильно сформированные сообщения или задачи, которым требуется доступ к недоступным ресурсам, могут вызвать сбой экземпляра службы. Система должна предотвращать возвращение в очередь таких сообщений. Поэтому записывайте и храните сведения об этих сообщениях в другом месте, чтобы их можно было анализировать при необходимости. Некоторые брокеры сообщений, такие как Служебная шина Azure, поддерживают это с помощью функций очереди недоставленных писем.
Повторяющиеся сообщения. То же сообщение может быть отправлено более одного раза. Например, отправитель может завершить работу ошибкой после публикации сообщения. Затем новый экземпляр отправителя может запуститься и повторить сообщение. Инфраструктура обмена сообщениями должна реализовать обнаружение и удаление (также известное как удаление повторов) дубликатов сообщений на основе идентификаторов сообщений для обеспечения одноразовой доставки сообщений. Кроме того, если используется инфраструктура обмена сообщениями, которая не отменяет дублирование сообщений, убедитесь, что логика обработки сообщений является идемпотентной.
Срок действия сообщений. Сообщение может иметь ограниченное время существования. Если оно не обрабатывается в течение этого периода, оно может быть недействительными и его следует отменить. Отправитель может указать время окончания срока действия в составе данных в сообщении. Получатель может проверить эту информацию, прежде чем решить, следует ли выполнять бизнес-логику, связанную с сообщением.
Планирование сообщений. Сообщение может быть временно запрещено и не будет обрабатываться до определенных даты и времени. Сообщение не должно быть доступным получателю до этого времени.
Масштабирование подписчиков. Если у конкретного подписчика нет возможности следить за скоростью получения сообщений, используйте шаблон конкурирующих потребителей для масштабирования.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
Приложению требуется распространить информацию значительному числу объектов-получателей.
Приложение должно взаимодействовать с одним или несколькими независимыми разработанными приложениями или службами, которые могут использовать различные платформы, языки программирования и протоколы связи.
Приложение может отправить объектам-получателям сведения, не требуя от них ответов в режиме реального времени.
Интегрируемые системы предназначены для поддержки модели итоговой согласованности для своих данных.
Приложению требуется передавать информацию нескольким объектам-получателям, которые могут иметь другие требования к доступности или расписания бесперебойной работы, чем отправитель.
Этот шаблон может оказаться неэффективным в следующих случаях:
Приложение имеет только несколько объектов-получателей, которым требуются сведения, значительно отличающиеся от приложения-производителя.
Приложение требует взаимодействия с объектами-получателями почти в реальном времени.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон издателя или подписчика можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Распаковка, представленная в этом шаблоне, обеспечивает независимые целевые показатели надежности для компонентов и удаляет прямые зависимости. - Анализ режима сбоя RE:03 - Задания RE:07 Фоновые задания |
| Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. | Этот шаблон представляет важную границу сегментации безопасности, которая позволяет подписчикам очередей быть изолированы от издателя в сети. - Сегментация SE:04 |
| Оптимизация затрат ориентирована на поддержание и улучшение рентабельности инвестиций рабочей нагрузки. | Этот несоединяемый дизайн может включить подход на основе событий в архитектуре, который хорошо соответствует выставлению счетов на основе потребления, чтобы избежать чрезмерной подготовки. - Оптимизация скорости CO:05 - Затраты на масштабирование CO:12 |
| Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды. | Этот уровень косвенного обращения позволяет безопасно изменять реализацию на стороне издателя или подписчика без необходимости координировать изменения обоих компонентов. - Разработка рабочей нагрузки OE:06 - Рекомендации по развертыванию OE:11 Сейф |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Разделение издателей от потребителей позволяет оптимизировать вычисления и код специально для задачи, которую потребитель должен выполнить для конкретного сообщения. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
На следующей схеме показана архитектура интеграции предприятия, которая использует служебная шина для координации рабочих процессов и сетки событий для уведомления подсистем событий, происходящих. Дополнительные сведения см. в статье Корпоративная интеграция в Azure с использованием очередей сообщений и событий.
Следующие шаги
При реализации этого шаблона может потребоваться следующее руководство.
Руководство по асинхронному обмену сообщениями. Очереди сообщений — это механизмы для асинхронного обмена данными. Если службе потребителя необходимо отправить ответ в приложение, может потребоваться реализовать некоторые варианты обмена сообщениями через ответы. Руководство по асинхронному обмену сообщениями предоставляет сведения о реализации обмена сообщениями через запрос или ответ с помощью очередей сообщения.
При реализации этого шаблона могут быть важны следующие шаблоны:
Шаблон наблюдателя. Шаблон с публикацией и подпиской основан на шаблоне наблюдателя с отделением субъектов от наблюдателей через асинхронный обмен сообщениями.
Шаблон брокера сообщений. Многие подсистемы обмена сообщениями, поддерживающие модель публикации и подписки, реализуются через брокер сообщений.
В этой записи блога описаны различные способы обработки сообщений, поступающих из порядка.
Связанные ресурсы
- В стиле архитектуры, управляемом событиями, используется обмен сообщениями с публикацией и подпиской.
- Обработка сообщений idempotent
- Корпоративная интеграция в Azure с помощью очередей сообщений и событий