Asynchronous messaging options in Azure (Параметры асинхронного обмена сообщениями в Azure)

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

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

Сущности, принимающие участие в асинхронном обмене сообщениями

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

Команды

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

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

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

События

Событие — это тип сообщения, который производитель создает для объявления фактов.

Производитель (известный как Издатель в этом контексте) не имеет ожидания о том, что события будут возникать в любом действии.

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

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

Существует две категории событий:

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

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

распространенным шаблоном для реализации сообщений о событиях является шаблон Publisher-подписчика .

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

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

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

Разъединение

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

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

Взаимодействие "производитель-получатель"

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

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

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

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

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

Шаблон конкурирующих потребителей

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

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

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

Шаблон выравнивания нагрузки на основе очередей

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

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

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

Отказоустойчивый обмен сообщениями

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

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

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

Служебная шина Azure

очереди служебная шина Azure хорошо подходят для передачи команд от поставщиков потребителям. Ниже приведены некоторые рекомендации.

Модель извлечения

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

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

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

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

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

Упорядочение сообщений

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

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

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

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

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

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

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

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

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

Ниже приведены примеры, в которых сообщение может быть в очередь DLQ:

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

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

Просмотрите сообщения в очередь DLQ, чтобы определить причину сбоя.

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

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

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

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

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

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

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

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

Модель принудительной отправки

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

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

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

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

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

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

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

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

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

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

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

Сетка событий может маршрутизировать 10 000 000 событий в секунду для каждого региона. Первые 100 000 операций в месяц не оплачиваются. Сведения о затратах см. в статье что такое стоимость сетки событий?

Отказоустойчивая Доставка

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

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

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

Центры событий Azure

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

Быстрое получение

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

Модель извлечения

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

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

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

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

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

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

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

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

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

Функция "Сбор" в Центрах событий

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

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

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

дополнительные сведения об этой функции см. в разделе захват событий с помощью концентраторов событий azure в служба хранилища или Azure Data Lake Storage больших двоичных объектов azure.

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

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

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

Сценарии перекрестного развертывания

В некоторых случаях удобнее сочетать две службы обмена сообщениями.

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

Интеграция служебной шины Azure со службой "Сетка событий"

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

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

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

служба "сетка событий Azure" для интеграции служебная шина

Используйте эти шаблоны при реализации асинхронного обмена сообщениями:

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

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

Запись блога жонасон Оливера (: идемпотентности

Запись блога Мартен Фаулер: что вы значите с помощью "управляемых событиями"?