В этой статье описываются различные типы сообщений и сущности, участвующие в инфраструктуре обмена сообщениями. В зависимости от требований каждого типа сообщения в статье рекомендуется использовать службы обмена сообщениями Azure. К ним относятся Служебная шина Azure обмен сообщениями, Сетка событий Azure и Центры событий Azure. Сравнение продуктов см. в разделе "Сравнение служб обмена сообщениями".
На уровне архитектуры сообщение представляет собой диаграмму данных, созданную сущностью (производителем), для распространения информации, чтобы другие сущности (потребители) могли быть осведомлены и действовать соответствующим образом. Производитель и потребитель могут взаимодействовать напрямую или необязательно через посредника (брокер сообщений). В этой статье рассматриваются асинхронные сообщения с помощью брокера сообщений.
Мы можем классифицировать сообщения в две основные категории. Если производитель ожидает действия от потребителя, это сообщение является командой. Если сообщение сообщает потребителю о том, что произошло действие, сообщение является событием.
Команды
Производитель отправляет команду с намерением, что потребители будут выполнять операцию в область бизнес-транзакции.
Команда является сообщением с высоким значением и должна быть доставлена по крайней мере один раз. Если команда потеряна, может завершиться сбоем всей бизнес-транзакции. Кроме того, команда не должна обрабатываться несколько раз. Это может привести к ошибочной транзакции. Клиент может получить дублирующиеся заказы или дважды выставлять счета.
Команды часто используются для управления рабочим процессом многоэтапной бизнес-транзакции. В зависимости от бизнес-логики производитель может ожидать, что потребитель подтвердит сообщение и сообщить о результатах операции. В зависимости от этого результата производитель может выбрать соответствующий курс действий.
События
Событие — это тип сообщения, которое производитель поднимает для объявления фактов.
Продюсер (известный как издатель в этом контексте) не ожидает, что события приводят к любому действию.
Заинтересованные потребители могут подписываться, прослушивать события и выполнять действия в зависимости от их сценария потребления. События могут содержать несколько подписчиков или вообще не имеют подписчиков. Два разных подписчика могут реагировать на событие с разными действиями и не учитывать друг друга.
Производитель и потребитель свободно связаны и управляются независимо. Производитель не ожидает, что потребитель признал событие обратно продюсеру. Потребитель, который больше не заинтересован в событиях, может отменить подписку, которая удаляет потребителя из конвейера, не влияя на производитель или общую функциональность системы.
Существует две категории событий:
Продюсер поднимает события, чтобы объявить дискретные факты. Распространенным вариантом использования является уведомление о событии. Например, Azure Resource Manager вызывает события при создании, изменении или удалении ресурсов. Подписчиком этих событий может быть приложение логики, которое отправляет оповещения по электронной почте.
Производитель вызывает связанные события в последовательности или поток событий в течение определенного периода времени. Как правило, поток используется для статистической оценки. Оценка может происходить в временном окне или по мере поступления событий. Телеметрия — это распространенный вариант использования (например, мониторинг работоспособности и нагрузки системы). Другим случаем является потоковая передача событий с устройств Интернета вещей.
Распространенный шаблон реализации обмена сообщениями о событиях — шаблон издателя-подписчика .
Роль и преимущества брокера сообщений
Посредник промежуточных сообщений предоставляет функциональные возможности перемещения сообщений от производителя к потребителю и может предложить дополнительные преимущества.
Разъединение
Брокер сообщений отделяет производителя от потребителя в логике, которая создает и использует сообщения соответственно. В сложном рабочем процессе брокер может поощрять бизнес-операции, чтобы быть разделенными и помочь координировать рабочий процесс.
Например, для одной бизнес-транзакции требуются отдельные операции, выполняемые в последовательности бизнес-логики. Производитель выдает команду, которая сигнализирует потребителю начать операцию. Потребитель признает сообщение в отдельной очереди, зарезервированной для подготовки ответов для производителя. Только после получения ответа производитель отправляет новое сообщение, чтобы начать следующую операцию в последовательности. Другой потребитель обрабатывает это сообщение и отправляет сообщение о завершении в очередь ответа. С помощью обмена сообщениями службы координирует рабочий процесс транзакции между собой.
Брокер сообщений предоставляет темпоральную развязку. Производитель и потребитель не должны работать одновременно. Производитель может отправить сообщение брокеру сообщений независимо от доступности потребителя. И наоборот, потребитель не ограничивается доступностью производителя.
Например, пользовательский интерфейс веб-приложения создает сообщения и использует очередь в качестве брокера сообщений. Когда потребитель готов, он может получить сообщения из очереди и выполнить работу. Разделение темпоральных данных помогает пользовательскому интерфейсу оставаться адаптивным. Он не блокируется, пока сообщения обрабатываются асинхронно.
Для выполнения некоторых операций может потребоваться много времени. После того как он выдает команду, производитель не должен ждать, пока потребитель не завершит его. Брокер сообщений помогает асинхронной обработке сообщений.
Балансировка нагрузки
Производители могут публиковать большое количество сообщений, обслуживаемых многими потребителями. Используйте брокер сообщений для распределения обработки между серверами и повышения пропускной способности. Потребители могут работать на разных серверах для распространения нагрузки. Потребители могут быть добавлены динамически для масштабирования системы при необходимости или удалении в противном случае.
Шаблон конкурирующих потребителей объясняет, как одновременно обрабатывать несколько сообщений для оптимизации пропускной способности, повышения масштабируемости и доступности и балансировки рабочей нагрузки.
Выравнивание нагрузки
Объем сообщений, создаваемых производителем или группой производителей, может быть переменным. Иногда может быть большой объем, вызывающий пики сообщений. Вместо добавления потребителей для обработки этой работы брокер сообщений может выступать в качестве буфера, и потребители постепенно сбрасывают сообщения в собственном темпе без стресса системы.
Шаблон выравнивания нагрузки на основе очередей предоставляет дополнительные сведения.
Надежный обмен сообщениями
Брокер сообщений помогает гарантировать, что сообщения не теряются, даже если связь между производителем и потребителем завершается ошибкой. Производитель может отправлять сообщения брокеру сообщений, и потребитель может получить их, когда обмен данными будет восстановлен. Производитель не блокируется, если он не теряет подключение к брокеру сообщений.
Устойчивое обмен сообщениями
Брокер сообщений может добавить устойчивость для потребителей в вашей системе. Если потребитель завершается ошибкой при обработке сообщения, другой экземпляр потребителя может обработать это сообщение. Повторная обработка возможна, так как сообщение сохраняется в брокере.
Выбор технологии для брокера сообщений
Azure предоставляет несколько служб брокера сообщений, каждый из которых содержит ряд функций. Перед выбором службы определите намерение и требования сообщения.
Службы сообщений Служебной шины Azure
Служебная шина Azure очереди обмена сообщениями хорошо подходят для передачи команд от производителей потребителям. Ниже приведены некоторые рекомендации.
Модель извлечения
Потребитель очереди служебная шина постоянно опрашивает служебная шина, чтобы проверка, если новые сообщения доступны. Клиентские пакеты SDK и триггер Функции Azure для служебная шина абстрактной модели. Когда появится новое сообщение, вызывается обратный вызов потребителя и сообщение отправляется потребителю.
Гарантированная доставка
служебная шина позволяет потребителю просмотреть очередь и заблокировать сообщение от других потребителей.
Это ответственность потребителя сообщать о состоянии обработки сообщения. Только если потребитель помечает сообщение как используемое, служебная шина удаляет сообщение из очереди. Если происходит сбой, время ожидания или сбой, служебная шина разблокирует сообщение, чтобы другие потребители могли получить его. Таким образом, сообщения не теряются при передаче.
Продюсер может случайно отправить одно и то же сообщение дважды. Например, экземпляр производителя завершается сбоем после отправки сообщения. Другой производитель заменяет исходный экземпляр и снова отправляет сообщение. Служебная шина Azure очереди предоставляют встроенную функцию дефиксирования, которая обнаруживает и удаляет повторяющиеся сообщения. Есть еще вероятность того, что сообщение доставлено дважды. Например, если потребитель завершается сбоем во время обработки, сообщение возвращается в очередь и извлекается тем же или другим потребителем. Логика обработки сообщений в потребителе должна быть идемпотентной, чтобы даже если работа повторялась, состояние системы не изменяется.
Порядок сообщений
Если вы хотите, чтобы потребители получили сообщения в порядке их отправки, служебная шина очереди гарантируют доставку в первую очередь (FIFO) с помощью сеансов. Сеанс может содержать одно или несколько сообщений. Сообщения коррелируются со свойством SessionId . Сообщения, которые являются частью сеанса, никогда не истекают. Сеанс может быть заблокирован для потребителя, чтобы предотвратить обработку сообщений другим потребителем.
Дополнительные сведения см. в статье Сеансы обмена сообщениями.
Сохраняемость сообщений
Очереди служебной шины поддерживают темпоральную развязку. Даже если потребитель недоступен или не может обработать сообщение, он остается в очереди.
Длительные транзакции контрольной точки
Бизнес-транзакции могут выполняться в течение длительного времени. Каждая операция в транзакции может содержать несколько сообщений. Используйте проверка указание для координации рабочего процесса и обеспечения устойчивости в случае сбоя транзакции.
служебная шина очереди позволяют проверка назначение с помощью возможности состояния сеанса. Сведения о состоянии записываются в очередь (SetState) для сообщений, принадлежащих сеансу. Например, потребитель может отслеживать ход выполнения, проверка состояние (GetState) каждый раз, а затем. Если потребитель завершается ошибкой, другой потребитель может использовать сведения о состоянии для определения последней известной проверка точки для возобновления сеанса.
Очередь недоставленных писем (DLQ)
Очередь служебная шина имеет вложенный запрос по умолчанию, называемый очередью недоставленных писем (DLQ) для хранения сообщений, которые не могут быть доставлены или обработаны. служебная шина или логика обработки сообщений в потребителе может добавлять сообщения в DLQ. DLQ сохраняет сообщения до тех пор, пока они не будут получены из очереди.
Ниже приведены примеры того, когда сообщение может оказаться в DLQ:
Отравляющее сообщение — это сообщение, которое не может быть обработано, так как оно неправильно сформировано или содержит непредвиденная информация. В очередях служебная шина можно обнаружить подозрительные сообщения, задав свойство MaxDeliveryCount очереди. Если число полученных сообщений превышает это значение свойства, служебная шина перемещает сообщение в DLQ.
Сообщение больше не может быть релевантно, если оно не обрабатывается в течение определенного периода. служебная шина очереди позволяют производителю публиковать сообщения с атрибутом времени в реальном времени. Если срок действия этого периода истекает до получения сообщения, сообщение помещается в DLQ.
Проверьте сообщения в DLQ, чтобы определить причину сбоя.
Гибридное решение
служебная шина мосты локальных систем и облачных решений. Локальные системы часто трудно достичь из-за ограничений брандмауэра. Как производитель, так и потребитель (могут быть локальными или облачными) могут использовать конечную точку очереди служебная шина в качестве места сбора и удаления сообщений.
Шаблон моста обмена сообщениями — это другой способ обработки этих сценариев.
Разделы и подписки
служебная шина поддерживает шаблон подписчика издателя с помощью служебная шина тем и подписок.
Эта функция позволяет продюсеру транслировать сообщения нескольким потребителям. Когда раздел получает сообщение, он пересылается всем пользователям, подписанным на подписку. При необходимости подписка может иметь критерии фильтрации, позволяющие потребителю получать подмножество сообщений. Каждый потребитель получает сообщения из подписки аналогично очереди.
Дополнительные сведения см. в Служебная шина Azure разделах.
Сетка событий Azure
Мы рекомендуем Сетка событий Azure для дискретных событий. Сетка событий следует шаблону publisher-подписчика. Когда источники событий активируют события, они публикуются в разделах Сетки событий. Потребители этих событий создают подписки сетки событий, указывая типы событий и обработчик событий, которые будут обрабатывать события. Если нет подписчиков, события не карта. Каждое событие может иметь несколько подписок.
Модель принудительной отправки
Сетка событий распространяет сообщения подписчикам в модели отправки. Предположим, у вас есть подписка сетки событий с веб-перехватчиком. При поступлении нового события сетка событий отправляет событие в конечную точку веб-перехватчика.
Интеграция с Azure
Выберите сетку событий, если вы хотите получать уведомления о ресурсах Azure. Многие службы Azure служат источниками событий, которые имеют встроенные разделы сетки событий. Сетка событий также поддерживает различные службы Azure, которые можно настроить в качестве обработчиков событий. Легко подписаться на эти разделы, чтобы перенаправить события в обработчики событий вашего выбора. Например, можно использовать сетку событий для вызова функции Azure при создании или удалении хранилища BLOB-объектов.
Пользовательские темы
Создайте настраиваемые разделы сетки событий, если вы хотите отправлять события из приложения или службы Azure, которая не интегрирована с сеткой событий.
Например, чтобы увидеть ход выполнения всей бизнес-транзакции, необходимо, чтобы участвующие службы вызвали события по мере их обработки отдельных бизнес-операций. Веб-приложение отображает эти события. Одним из способов выполнения этой задачи является создание пользовательского раздела и добавление подписки с веб-приложением, зарегистрированным через HTTP WebHook. Как бизнес-службы отправляют события в пользовательский раздел, сетка событий отправляет их в веб-приложение.
Отфильтрованные события
Вы можете указать фильтры в подписке, чтобы указать Сетке событий маршрутизировать только подмножество событий в определенный обработчик событий. Фильтры в схеме подписки указываются. Любое событие, отправленное в раздел со значениями, соответствующими фильтру, автоматически перенаправляются в эту подписку.
Например, содержимое в различных форматах передается в служба хранилища BLOB-объектов. При каждом добавлении файла событие создается и публикуется в сетке событий. Подписка на события может иметь фильтр, который отправляет только события для изображений, чтобы обработчик событий мог создавать эскизы.
Дополнительные сведения о фильтрации см. в разделе "Фильтрация событий" для сетки событий.
Высокая пропускная способность
Сетка событий может направлять 10 000 000 событий в секунду в каждом регионе. Первые 100 000 операций в месяц не оплачиваются. Рекомендации по затратам см. в статье о стоимости сетки событий?
Устойчивость доставки
Несмотря на то, что успешная доставка событий не является столь важной, как команды, может потребоваться некоторая гарантия в зависимости от типа события. Сетка событий предоставляет функции, которые можно включить и настроить, такие как политики повторных попыток, время окончания срока действия и недоставленное письмо. Дополнительные сведения см. в разделе Доставка и повторные попытки доставки сообщений сетки событий.
Процесс повторных попыток сетки событий может помочь в устойчивости, но он не является отказоустойчивой. В процессе повторных попыток сетка событий может доставлять сообщение несколько раз, пропускать или задерживать некоторые повторные попытки, если конечная точка не отвечает в течение длительного времени. Дополнительные сведения см. в разделе "Расписание повторных попыток".
Вы можете сохранить незавершенные события в учетной записи хранения BLOB-объектов, включив недоставленную букву. Существует задержка при доставке сообщения в конечную точку хранилища BLOB-объектов, а если эта конечная точка не отвечает, то сетка событий не отвечает карта событие. Дополнительные сведения см. в разделе "Настройка расположения недоставленных букв" и политики повторных попыток.
Центры событий Azure
При работе с потоком событий Центры событий Azure является рекомендуемым брокером сообщений. По сути, это большой буфер, способный получать большие объемы данных с низкой задержкой. Полученные данные можно быстро считывать с помощью параллельных операций. Полученные данные можно преобразовать с помощью любого поставщика аналитики в режиме реального времени. Центры событий также предоставляют возможность хранения событий в учетной записи хранения.
Быстрое прием
Центры событий могут обрабатывать миллионы событий в секунду. События добавляются только к потоку и упорядочиются по времени.
Модель извлечения
Как и в сетке событий, Центры событий также предоставляют возможности подписчика издателя. Ключевое различие между сеткой событий и Центрами событий заключается в том, как данные о событиях предоставляются подписчикам. Сетка событий отправляет отправленные данные подписчикам, а центры событий делают данные доступными в модели извлечения. По мере получения событий центры событий добавляют их в поток. Подписчик управляет курсором и может перемещаться вперед и назад в потоке, выбирать смещение времени и воспроизводить последовательность в темпе.
Обработчики потоков — это подписчики, которые извлекают данные из Центров событий в целях преобразования и статистического анализа. Используйте Azure Stream Analytics и Apache Spark для сложной обработки, например агрегирования с течением времени или обнаружения аномалий.
Если вы хотите выполнить действия по каждому событию на секцию, вы можете извлечь данные с помощью узла обработчика событий или с помощью встроенного соединителя, например Azure Logic Apps, чтобы обеспечить логику преобразования. Другим вариантом является использование Функции Azure.
Секционирование
Секция — это часть потока событий. События разделяются с помощью ключа секции. Например, несколько устройств Интернета вещей отправляют данные устройства в концентратор событий. Ключ секции — это идентификатор устройства. По мере приема событий центры событий перемещают их в отдельные секции. В каждой секции все события упорядочиются по времени.
Потребитель — это экземпляр кода, обрабатывающий данные события. Центры событий соответствуют шаблону секционированного потребителя. Каждый потребитель считывает только определенную секцию. Наличие нескольких секций приводит к более быстрой обработке, так как поток может читаться одновременно несколькими потребителями.
Экземпляры одного и того же потребителя составляют одну группу потребителей. Несколько групп потребителей могут считывать один поток с различными намерениями. Предположим, что поток событий содержит данные из датчика температуры. Одна группа потребителей может считывать поток для обнаружения аномалий, таких как пик температуры. Другой может считывать тот же поток для вычисления скользящей средней температуры в темпоральных окнах.
Центры событий поддерживают шаблон подписчика издателя, позволяя нескольким группам потребителей. Каждая группа потребителей является подписчиком.
Дополнительные сведения о секционирования Центров событий см. в разделах Секционирования.
Функция "Сбор" в Центрах событий
Функция отслеживания позволяет хранить поток событий в хранилище BLOB-объектов Azure или Data Lake служба хранилища. Этот способ хранения событий является надежным, так как даже если учетная запись хранения недоступна, запись сохраняет данные в течение определенного периода, а затем записывает данные в хранилище после его доступности.
службы служба хранилища также могут предлагать дополнительные функции для анализа событий. Например, используя уровни доступа учетной записи хранения BLOB-объектов, можно хранить события на горячем уровне для данных, которым требуется частый доступ. Эти данные можно использовать для визуализации. Кроме того, можно хранить данные на архивном уровне и иногда извлекать их для целей аудита.
Запись сохраняет все события, принятые центрами событий, и полезно для пакетной обработки. Отчеты о данных можно создавать с помощью функции MapReduce. Захваченные данные также могут служить источником истины. Если некоторые факты были пропущены во время агрегирования данных, можно ссылаться на захваченные данные.
Дополнительные сведения об этой функции см. в разделе "Запись событий" Центры событий Azure в Хранилище BLOB-объектов Azure или Azure Data Lake служба хранилища.
Поддержка клиентов Apache Kafka
Центры событий предоставляют конечную точку для клиентов Apache Kafka . Существующие клиенты могут обновить конфигурацию, чтобы указать конечную точку и начать отправку событий в Центры событий. Вам не нужно вносить изменения в код.
Дополнительные сведения см. в разделе Центры событий для Apache Kafka.
Сценарии кроссоверного перехода
В некоторых случаях выгодно объединить две службы обмена сообщениями.
Объединение служб может повысить эффективность системы обмена сообщениями. Например, в бизнес-транзакции для обработки сообщений используются очереди Служебная шина Azure. Очереди, в основном неактивные и получающие сообщения, иногда неэффективны, потому что потребитель постоянно опрашивает очередь для новых сообщений. Подписку сетки событий можно настроить с помощью функции Azure в качестве обработчика событий. Каждый раз, когда очередь получает сообщение, и потребители не прослушивают, служба "Сетка событий" отправляет уведомление, которое вызывает функцию Azure, которая очищает очередь.
Дополнительные сведения о подключении служебная шина к сетке событий см. в Служебная шина Azure обзор интеграции сетки событий.
Интеграция Enterprise с использованием очередей сообщений и эталонной архитектуры событий показывает реализацию служебная шина интеграции сетки событий.
Ниже приведен еще один пример: Сетка событий получает набор событий, в которых некоторые события требуют рабочего процесса, а другие — для уведомления. Метаданные сообщения указывают тип события. Одним из способов отличия является проверка метаданных с помощью функции фильтрации в подписке на события. Если для него требуется рабочий процесс, сетка событий отправляет ее в очередь Служебная шина Azure. Получатели этой очереди могут выполнять необходимые действия. События уведомлений отправляются в Logic Apps для отправки оповещений.
Связанные шаблоны
При реализации асинхронного обмена сообщениями рассмотрите следующие шаблоны:
- Шаблон конкурирующих потребителей. Нескольким потребителям может потребоваться конкурировать для чтения сообщений из очереди. В этом шаблоне объясняется, как одновременно обрабатывать несколько сообщений для оптимизации пропускной способности, повышения масштабируемости и доступности и балансировки рабочей нагрузки.
- Шаблон очереди с приоритетом. В случаях, когда бизнес-логика требует, чтобы некоторые сообщения обрабатывались перед другими пользователями, в этом шаблоне описывается, как сообщения, размещенные производителем с более высоким приоритетом, получаются и обрабатываются потребителем быстрее, чем сообщения с более низким приоритетом.
- Шаблон балансировки нагрузки на основе очередей. Этот шаблон использует брокер сообщений для работы в качестве буфера между производителем и потребителем, чтобы свести к минимуму влияние на доступность и скорость реагирования временных тяжелых нагрузок для обоих этих сущностей.
- Шаблон повторов. Производителю или потребителю может быть не удается подключиться к очереди, но причины этого сбоя могут быть временными и быстро пройдены. В этом шаблоне описывается, как справиться с этой ситуацией, чтобы добавить устойчивость к приложению.
- Шаблон диспетчера агентов планировщика. Обмен сообщениями часто используется в рамках реализации рабочего процесса. В этом шаблоне показано, как обмен сообщениями может координировать набор действий в распределенном наборе служб и других удаленных ресурсов, а также позволяет системе восстанавливать и повторять действия, которые завершаются сбоем.
- Шаблон хореографии. В этом шаблоне показано, как службы могут использовать обмен сообщениями для управления рабочим процессом бизнес-транзакции.
- Шаблон проверки утверждений. В этом шаблоне показано, как разделить большое сообщение на утверждение проверка и полезные данные.
Ресурсы сообщества
Блог Джонатон Оливера: Идемпотентность
Запись блога Мартина Фаулера: Что вы означаете на "На основе событий"?