Очереди, разделы и подписки служебной шины

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

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

Очереди

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

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

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

Создавать очереди можно с помощью портала Azure, PowerShell, CLI или шаблонов Resource Manager. Далее через эти очереди можно отправлять и получать сообщения с помощью клиентов, написанных на языках C#, Java, Python и JavaScript.

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

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

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

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

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

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

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

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

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

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

Создание раздела подобно созданию очереди, как показано в примере, приведенном в предыдущем разделе. Создавать разделы и подписки можно с помощью портала Azure, PowerShell, CLI или шаблонов Resource Manager. Далее можно отправлять сообщения в разделы и получать их из подписок с помощью клиентов, написанных на языках C#, Java, Python и JavaScript.

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

Полный рабочий пример см. в примере TopicFilters на сайте GitHub.

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

Сущности в службе сообщений Java (JMS) версии 2.0

Через API службы сообщений Java (JMS) версии 2.0 доступны следующие сущности:

• временные очереди;
• временные разделы;
• общие устойчивые подписки;
• необщие устойчивые подписки;
• общие неустойчивые подписки;
• необщие неустойчивые подписки.

Дальнейшие действия

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