Параметры асинхронного обмена сообщениями

В этой статье описываются различные типы сообщений и сущности, участвующие в инфраструктуре обмена сообщениями. В зависимости от требований типа сообщения Azure предоставляет службы обмена сообщениями, включающие обмен сообщениями служебной шины Azure, Сетку событий Azure и Центры событий Azure. Дополнительные сведения см. в разделе "Сравнение служб обмена сообщениями".

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

Схема, демонстрирующая компоненты асинхронного обмена сообщениями.

Сообщения имеют две основные категории:

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

Commands

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

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

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

Events

Событие — это сообщение, которое обработчик создаёт, чтобы объявить, что что-то произошло. Продюсер (известный как издатель в этом контексте) не ожидает, что событие приведет к любому конкретному действию.

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

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

События имеют две категории:

  • Дискретные события: Генератор инициирует события, чтобы сообщить об отдельных фактах. Распространенным вариантом использования является уведомление о событии. Например, Azure Resource Manager вызывает события при создании, изменении или удалении ресурсов. Приложение логики может подписаться на эти события и отправить оповещающие электронные письма.

  • Потоки событий: Создатель формирует последовательность связанных событий в течение времени. Потребители обычно оценивают потоки в статистических целях либо в темпоральных окнах, либо по мере поступления событий. Телеметрия — это распространенный вариант использования, например мониторинг работоспособности и загрузки системы. Другой вариант использования включает потоковую передачу событий с устройств Интернета вещей (IoT).

Вы можете реализовать обмен сообщениями о событиях с помощью шаблонаPublisher-Subscriber.

Схема шаблона Publisher-Subscriber для обмена сообщениями о событиях.

Роль и преимущества брокера сообщений

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

Разделение

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

Рассмотрим бизнес-транзакцию, требующую отдельных операций в последовательности:

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

  2. Потребитель признает сообщение в отдельной очереди ответов, зарезервированной для подготовки ответов для производителя.

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

  4. Другой потребитель обрабатывает это сообщение и отправляет сообщение о завершении в очередь ответа.

С помощью обмена сообщениями службы координирует рабочий процесс транзакции между собой.

Схема коммуникации производителя-потребителя.

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

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

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

Балансировка нагрузки

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

Схема шаблона конкурирующих потребителей.

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

Выравнивание нагрузки

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

Схема шаблона выравнивания нагрузки, основанного на очередях.

Для получения дополнительной информации см. раздел шаблон выравнивания нагрузки на основе очереди.

Надежный обмен сообщениями

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

Устойчивое обмен сообщениями

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

Большие сообщения

Если объем вашего полезной нагрузки превышает предел размера брокера сообщений, или когда потребители нуждаются в доступе к большим данным лишь изредка, используйте шаблон Claim-Check. Сохраните большие полезные данные во внешнем хранилище, например, хранилище Azure Blob. Отправьте брокеру сообщение, включающее указатель на сохраненную полезную нагрузку. Потребитель использует указатель для получения полезных данных при необходимости. Такой подход предотвращает перегрузку брокера и потребителей большими дейтаграммами.

Выбор технологии для брокера сообщений

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

Обмен сообщениями шины данных

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

Модель запроса

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

Гарантированная доставка

Служба Service Bus использует механизм просмотра и блокировки. Когда потребитель получает сообщение, Service Bus временно блокирует его. Эта блокировка запрещает другим потребителям обрабатывать то же сообщение.

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

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

Порядок сообщений

Чтобы обеспечить доставку сообщений в том порядке, в который они были отправлены, очереди Service Bus используют сеансы, с помощью которых достигается упорядоченная доставка. Сеанс может содержать одно или несколько сообщений. Сервисная шина сопоставляет сообщения с помощью свойства SessionId. Сообщения, принадлежащие сеансу, никогда не истекают. Сеанс можно заблокировать потребителю, чтобы предотвратить обработку сообщений другого потребителя.

Дополнительные сведения см. в статье Сеансы обмена сообщениями.

Сохраняемость сообщений

Очереди Service Bus поддерживают долговременное временное развязывание. Даже если потребитель недоступен или не может обработать сообщение, он остается в очереди.

Контрольная точка для длительных транзакций

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

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

Очередь недоставленных сообщений

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

Служебная шина перемещает сообщения в DLQ в следующих сценариях:

  • Отравляющее сообщение — это сообщение, которое потребитель не может обрабатывать, так как он неправильно сформирован или содержит непредвиденная информация. Чтобы обнаружить ядовитые сообщения в очередях Service Bus, задайте MaxDeliveryCount свойство очереди. Если потребитель получает то же сообщение больше раз, чем позволяет это значение свойства, Service Bus перемещает сообщение в DLQ.

  • Сообщение больше не может быть актуальным, если потребитель не обрабатывает его в течение определенного периода. Очереди служебной шины позволяют производителю публиковать сообщения с атрибутом TTL. Если срок действия этого периода истекает до того, как потребитель получит сообщение, Service Bus помещает сообщение в DLQ.

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

Гибридное решение

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

Гибридные подключения Azure Relay предоставляют готовую реализацию для кросс-платформенного взаимодействия на основе сообщений. Ретранслятор Azure основан на служебной шине и предоставляет двунаправленные шаблоны запроса-ответа и потоки дейтаграмм.

Для обработки этих сценариев также можно использовать шаблон моста обмена сообщениями .

Разделы и подписки

Сервисная шина поддерживает паттерн издатель-подписчик с помощью топиков и подписок.

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

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

Дополнительные сведения см. в темах служебной шины.

Протоколы в Service Bus

Служебная шина использует расширенный протокол очереди сообщений (AMQP) для взаимодействия в отрасли. Служба также поддерживает стандарт API службы сообщений Java (JMS ).

Дополнительные сведения о схеме формата сообщения см. в разделе "Сообщения", "Полезные данные" и сериализация.

Сетка событий

Используйте сетку событий для дискретных событий. Сетка событий следует шаблону Publisher-Subscriber. Когда источники событий активируют события, они публикуют их в разделах сетки событий. Потребители этих событий создают подписки сетки событий, указывая типы событий и обработчик событий для обработки событий. Каждое событие может иметь несколько подписок.

Модель push-уведомлений в сетке событий

Сетка событий может распространять сообщения подписчикам в устойчивой модели отправки. Предположим, что у вас есть подписка на Event Grid с веб-хуком. При поступлении нового события Event Grid отправляет событие на конечную точку webhook. В модели push-отправки, если подписчики не существуют или подписчики неоднократно не отвечают, сетка событий удаляет события.

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

Интеграция с Azure

Выберите сетку событий, если вы хотите получать уведомления о ресурсах Azure. Многие службы Azure служат источниками событий, имеющими встроенные разделы сетки событий. Служба "Сетка событий" также поддерживает различные службы Azure, которые можно настроить в качестве обработчиков событий. Вы можете подписаться на эти разделы, чтобы перенаправить события в выбранные обработчики событий. Например, можно использовать сетку событий для вызова функции Azure при создании или удалении BLOB-объекта хранилища.

Пользовательские темы

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

Например, предположим, что вы хотите отслеживать ход выполнения всей бизнес-транзакции. Участвующие службы генерируют события во время выполнения своих отдельных бизнес-операций. Веб-приложение отображает эти события. Чтобы реализовать этот мониторинг, создайте настраиваемый раздел и добавьте подписку, которая регистрирует веб-приложение в качестве веб-перехватчика HTTP. Когда бизнес-службы отправляют события в пользовательский раздел, сетка событий отправляет события в веб-приложение.

Отфильтрованные события

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

Например, приложения загружают содержимое в различных форматах в хранилище BLOB-объектов. Хранилище BLOB-объектов вызывает и публикует событие в Сетке событий при каждом поступлении файла. Вы можете добавить фильтр в подписку, которая ограничивает события только изображения, чтобы обработчик событий смог создать эскизы.

Дополнительные сведения см. в разделе "Фильтрация событий" для сетки событий.

Высокая пропускная способность

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

Устойчивость доставки

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

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

При включении недоставленных букв сетка событий сохраняет незавершенные события в учетной записи хранения BLOB-объектов. Если конечная точка хранилища BLOB-объектов не отвечает, сетка событий задерживает доставку и в конечном итоге удаляет событие. Дополнительные сведения см. в разделе "Настройка расположения недоставленных букв" и политики повторных попыток.

Сетка событий не гарантирует порядок доставки событий.

Модель извлечения в сетке событий

Помимо push-модели, Event Grid поддерживает выборочную доставку на основе HTTP, использующую очередь-подобную семантику. Используйте эту модель, если потребители событий имеют следующие характеристики:

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

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

Протоколы в сетке событий

Сетка событий поддерживает две схемы событий:

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

  • Схема сетки событий: Используйте эту собственную схему неэкстенсивного формата, только если не удается использовать схему CloudEvents. Эта схема зависит от сетки событий.

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

Event Hubs

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

Прием больших объемов

Центры событий могут получать миллионы событий в секунду. Event Hubs добавляет события в поток и упорядочивает их по времени.

Модель извлечения в Центрах событий

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

Обработчики потоков — это подписчики, которые извлекают данные из Центров событий для преобразования и статистического анализа. Для сложной обработки, например агрегирования с течением времени или обнаружения аномалий, используйте Azure Stream Analytics или Apache Spark. Вы также можете интегрировать Центры событий с Microsoft Fabric, загрузив данные в хранилище событий или создав поток событий.

Для обработки отдельных событий в каждой секции можно использовать встроенные соединители EventProcessorHost, такие как Azure Logic Apps или триггеры центров событий и привязки для функций Azure.

Partitioning

Раздел — это часть потока событий. Центры событий разделяют события с помощью ключа раздела. Например, несколько устройств Интернета вещей отправляют данные устройства в концентратор событий. Ключ секции — это идентификатор устройства. По мере приема событий центры событий перемещают их в отдельные секции. В каждом разделе Центр событий упорядочивает все события по времени.

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

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

Центры событий реализуют шаблон Publisher-Subscriber через несколько групп потребителей, где каждая группа выступает в качестве отдельного подписчика.

Для получения дополнительных сведений о секционировании в Event Hubs см. Разделы.

Запись центров событий

Функцию записи можно использовать для хранения потока событий в хранилище BLOB-объектов или Azure Data Lake Storage. Запись обеспечивает надежное хранилище, так как сохраняет данные в течение определенного периода, если учетная запись хранения недоступна, затем записывается в хранилище после его доступности.

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

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

Дополнительные сведения об этой функции см. в разделе "Запись событий через Event Hubs в хранилище BLOB-объектов или Data Lake Storage".

Поддержка клиентов Apache Kafka

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

Дополнительные сведения см. в разделе Центры событий для Apache Kafka.

Сценарии кроссоверов

Вы можете объединить две службы обмена сообщениями, чтобы получить преимущества. Такой подход повышает эффективность системы обмена сообщениями. Например, предположим, что для обработки сообщений при бизнес-транзакции используются очереди Service Bus. Очереди простоя, которые иногда получают сообщения, приводят к неэффективности, так как потребитель постоянно опрашивает очередь в поисках новых сообщений. Вы можете настроить подписку Сетки событий и использовать функцию Azure в качестве обработчика событий. Каждый раз, когда очередь получает сообщение, и потребители не прослушивают, служба "Сетка событий" отправляет уведомление, которое вызывает функцию Azure для очистки очереди.

Схема, на которую показана интеграция служебной шины с сеткой событий.

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

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

В качестве другого примера сетка событий получает набор событий. Некоторые события требуют рабочего процесса, а другие запускают уведомления. Метаданные сообщения указывают тип события. Чтобы проверить метаданные, используйте функцию фильтрации в подписке на события. Если для события требуется рабочий процесс, Event Grid отправляет его в очередь Service Bus. Получатели этой очереди могут выполнять необходимые действия. Служба "Event Grid" отправляет события уведомлений в Logic Apps для отправки оповещающих писем.

Схема интеграции сетки событий с служебной шиной.

При реализации асинхронного обмена сообщениями рассмотрите следующие шаблоны:

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

  • Шаблон очереди приоритета: если бизнес-логика требует приоритетной обработки сообщений, этот шаблон описывает, как потребители обрабатывают сообщения с более высоким приоритетом до сообщений с более низким приоритетом.

  • Queue-Based Load Leveling pattern: этот шаблон использует брокер сообщений для работы в качестве буфера между производителем и потребителем. Этот шаблон помогает свести к минимуму влияние временных тяжелых нагрузок как на доступность производителя, так и на скорость реагирования потребителей.

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

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

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

  • Claim-Check шаблон. В этом шаблоне показано, как разделить большое сообщение на проверку утверждений и полезные данные.

Ресурсы сообщества

  • Last updated on