Очереди службы хранилища и очереди служебной шины: сходства и различия.

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

Введение

Azure поддерживает два типа очередей: очереди службы хранилища и очереди служебной шины.

Очереди службы хранилища являются частью инфраструктуры службы хранилища Azure. Они позволяют хранить большое количество сообщений. Доступ к сообщениям возможен из любой точки мира с помощью вызовов с проверкой подлинности по протоколу HTTP или HTTPS. Максимальный размер сообщения в очереди составляет 64 КБ. Очередь может содержать миллионы сообщений, ограничиваясь лишь общей емкостью учетной записи хранения. Очереди обычно используются для создания списка невыполненных заданий для асинхронной обработки. Дополнительные сведения см. в статье Общие сведения об очередях службы Azure.

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

Рекомендации по выбору технологии

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

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

Рассмотрите возможность использования очередей службы хранилища

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

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

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

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

• Решение должно иметь возможность получать сообщения, не опрашивая очередь. С помощью служебной шины можно этого достичь, используя операцию получения с длинным опросом и протоколы на основе TCP, поддерживаемые служебной шиной.
• В решении требуется, чтобы очередь гарантированно доставляла сообщения в порядке их добавления в очередь (FIFO).
• В решении необходима поддержка автоматического обнаружения дубликатов.
• Вы хотите, чтобы приложение обрабатывало сообщения как параллельные долговременные потоки (сообщения связываются с потоком с помощью свойства session ID сообщения). В этой модели каждый узел принимающего приложения конкурирует за потоки, а не за сообщения. Когда для принимающего узла выделяется поток, узел может проверить состояние потока приложения с помощью транзакций.
• В решении требуется реализовать транзакционный режим работы и атомарность при отправке или получении нескольких сообщений из очереди.
• Приложение обрабатывает сообщения, размер которых может превышать 64 КБ, но вряд ли достигнет ограничений в 256 КБ или 1 МБ, которые действуют в зависимости от выбранного уровня службы (при этом сами очереди Служебная шина могут обрабатывать сообщения размером до 100 МБ).
• Вам требуется обеспечить доступ к очередям на основе ролей, а также предусмотреть различные права или разрешения для отправителей и получателей. Дополнительные сведения см. в следующих статьях:
  • Проверка подлинности с помощью управляемых удостоверений
  • Проверка подлинности из приложения
• Размер очереди не будет превышать 80 ГБ.
• Вы хотите использовать протокол обмена сообщениями на основе стандартов AMQP 1.0. Дополнительные сведения об AMQP см. в статье Общие сведения о протоколе AMQP для служебной шины.
• Вы задумали постепенный переход от обмена данными между точками на основе очередей к шаблону сообщений с публикациями и подписками. Этот шаблон обеспечивает интеграцию дополнительных получателей (подписчиков). Каждый получатель получает независимые копии некоторых или всех сообщений, отправленных в очередь.
• В решении обмена сообщениями должна поддерживаться гарантированная доставка "не более одного раза" и "как минимум один раз" без необходимости создания дополнительных компонентов инфраструктуры.
• Ваше решение должно публиковать и использовать пакеты сообщений.

Сравнение очередей службы хранилища и очередей служебной шины

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

Основные возможности

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

Дополнительная информация:

• Сообщения в очередях службы хранилища обычно располагаются по принципу "первым пришел, первым ушел", но иногда они могут быть в неправильном порядке. Например, если время ожидания видимости сообщения истекло из-за аварийного завершения работы клиентского приложения при обработке сообщения. По истечении времени ожидания сообщение снова становится видимым, и следующий рабочий процесс может вывести его из очереди. В этот момент вновь видимое сообщение может быть помещено в очередь для повторного выведения из очереди.
• Для гарантированного упорядочения сообщений по методу FIFO в очередях служебной шины необходимо использовать сеансы обмена сообщениями. Если приложение завершает работу во время обработки сообщения, полученного в режиме "Просмотр и блокировка ", в следующий раз, когда получатель очереди принимает сеанс обмена сообщениями, он начнется с сообщением о сбое после истечения срока блокировки сеанса.
• служба хранилища очереди предназначены для поддержки стандартных сценариев очереди, таких как следующие:
  • Отделение компонентов приложения для повышения масштабируемости и допустимости сбоев
  • Выравнивание нагрузки
  • Создание рабочих процессов процесса.
• Можно избежать несоответствий в обработке сообщений в контексте сеансов служебной шины, если использовать состояние сеанса для хранения состояния приложения с указанием хода обработки последовательности из сообщений сеанса, а также с помощью транзакций для обработки полученных сообщений и обновления состояния сеанса. Этот тип функции согласованности иногда получает метку только один раз при обработке в продуктах других поставщиков. Любые сбои транзакций, очевидно, приводят к тому, что сообщения будут доставлены повторно, поэтому такой термин недостаточно точный.
• Очереди службы хранилища предоставляют единообразную и согласованную модель программирования для очередей, таблиц и больших двоичных объектов как разработчикам, так и специалистам по эксплуатации.
• Очереди служебной шины обеспечивают поддержку локальных транзакций в контексте одной очереди.
• Режим Получение и удаление, поддерживаемый служебной шиной, позволяет сократить число операций обмена сообщениями (и связанные с этим расходы) за счет понижения уровня гарантии доставки.
• Очереди службы хранилища поддерживают аренду сообщений с возможностью продления, Благодаря этой функции рабочие процессы могут поддерживать короткие сроки аренды для сообщений. Поэтому в случае сбоя одного рабочего процесса сообщение может быть быстро обработано другим рабочим процессом. Кроме того, рабочий процесс может продлить аренду сообщения, если для его обработки требуется время, превышающее текущее время аренды.
• Очереди службы хранилища поддерживают время ожидания видимости, которое можно задавать при добавлении сообщения в очередь или выведении из нее. Кроме того, можно обновлять значения аренды сообщения в рабочем режиме, а также использовать разные значения для разных сообщений в рамках одной очереди. Время ожидания блокировки служебной шины определяется в метаданных очереди. Тем не менее можно продлевать блокировку сообщения на предварительно заданное время вручную или использовать функцию автоматического продления блокировки, с помощью которой клиент управляет продлением блокировок вместо вас.
• Максимальное время ожидания для операции получения с блокировкой в очередях служебной шины составляет 24 дня. Однако для очередей на основе REST время ожидания не может превышать 55 секунд.
• Служебная шина позволяет выполнять пакетную обработку на стороне клиента. Это означает, что клиент очереди может отправлять несколько сообщений в рамках одной операции отправки. Пакетная обработка возможна только для операций асинхронной отправки.
• Верхнее ограничение в 200 ТБ (при виртуализации учетных записей — больше) для очередей службы хранилища или полное отсутствие ограничений делают эти службы идеальной платформой для поставщиков SaaS.
• Очереди службы хранилища предоставляют гибкий и эффективный механизм управления делегированным доступом.

Расширенные возможности

В этом разделе сравниваются расширенные возможности очередей службы хранилища и очередей служебной шины.

Дополнительная информация:

• Обе технологии очередей позволяют запланировать доставку сообщения в более позднее время.
• Автоматическая пересылка позволяет тысячам очередей автоматически перенаправлять сообщения в одну очередь, из которой их забирает получающее приложение. Этот механизм можно использовать для обеспечения безопасности, управления потоком и изоляции хранилищ разных создателей сообщений.
• Очереди службы хранилища поддерживают обновление содержимого сообщений. Вы можете использовать эту возможность для сохранения в сообщении сведений о состоянии и поэтапного обновления хода выполнения операций. Это позволит продолжать обработку сообщений с последней известной контрольной точки, а не с самого начала. В очередях служебной шины тот же сценарий реализуется с использованием сеансов сообщений. Дополнительные сведения см. в статье Состояние сеанса обмена сообщениями.
• Очереди служебной шины поддерживают перемещение в очередь недоставленных сообщений. Это может быть полезно для изоляции сообщений, которые соответствуют следующим критериям:
  • Принимающему приложению не удалось успешно обработать сообщения
  • Сообщения не достигли места назначения из-за просроченного срока жизни (TTL), указанного в свойстве. Значение TTL определяет время, в течение которого сообщение остается в очереди. Если используется служебная шина, после истечения срока жизни сообщение перемещается в специальную очередь $DeadLetterQueue.
• Чтобы найти подозрительные сообщения в очередях службы хранилища, приложение проверяет свойство сообщения DequeueCount при выведении его из очереди. Если значение DequeueCount превышает заданное пороговое значение, сообщение перемещается в определяемую приложением "мертвую очередь".
• Очереди службы хранилища позволяют получить подробный журнал всех транзакций, примененных к очереди, а также агрегированные метрики. Обе функции полезны для отладки и понимания принципов использования очередей службы хранилища в приложении. Они также помогают оптимизировать производительность приложения и сократить расходы, связанные с использованием очередей.
• Сеансы сообщений, поддерживаемые служебной шиной, позволяют связать сообщения, принадлежащие логической группе, с получателем. Это создает сходство, как в случае с сеансами, между сообщениями и их соответствующими получателями. Чтобы включить эту дополнительную функцию в служебной шине, нужно задать свойство сообщения session ID. Получатели смогут выполнять прослушку по конкретному идентификатору сеанса и получать сообщения с этим идентификатором.
• Функция обнаружения дубликатов, поддерживаемая очередями служебной шины, автоматически удаляет дубликаты сообщений, отправленные в очередь или раздел, используя свойство message ID.

Емкость и квоты

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

Дополнительная информация:

• В служебной шине ограничения по размеру применяются принудительно. Максимальный размер очереди указывается при ее создании. Значение может составлять от 1 до 80 ГБ. Если размер очереди достигнет этого предела, последующие входящие сообщения будут отклонены, и вызывающий получит исключение. Дополнительные сведения о квотах в служебной шине см. в разделе Квоты на служебную шину.
• На уровне обмена сообщениями "Стандартный" можно создавать очереди и разделы служебной шины размером в 1 или 2, 3, 4 или 5 ГБ (по умолчанию). При включении секционирования на уровне "Стандартный" служебная шина создает 16 копий (16 секций) сущности, каждый из указанных размеров. Поэтому при создании очереди размером 5 ГБ с 16 разделами максимальный размер очереди составит 80 ГБ (5 × 16). Максимальный размер секционированной очереди или раздела можно на портале Azure.
• При использовании очередей службы хранилища содержимое сообщений, небезопасное с точки зрения XML, должно кодироваться в формат Base64. При кодировке сообщения методом Base64 размер полезных данных может достигать 48 KБ (а не 64 КБ).
• Каждое сообщение, сохраненное в очереди служебной шины, состоит из двух частей: заголовка и текста. Общий размер сообщения не может превышать максимальный размер, поддерживаемый уровнем служб.
• Когда клиенты взаимодействуют с очередями служебной шины по протоколу TCP, максимальное количество одновременных подключений к отдельной очереди служебной шины не может превышать 100. Это число распределяется между отправителями и получателями. После достижения квоты запросы на дополнительные соединения отклоняются, а вызывающий код получает исключение. Это ограничение не применяется к клиентам, подключающимся к очередям с помощью интерфейса API на основе REST.
• Если требуется более 10 000 очередей в одном пространстве имен служебной шины, можно отправить запрос на увеличение в службу поддержки Azure. Чтобы увеличить количество очередей служебной шины сверх ограничения в 10 000, создайте дополнительные пространства имен на портале Azure.

Управление и использование

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

Дополнительная информация:

• Очереди службы хранилища поддерживают произвольные атрибуты, которые могут применяться к описанию очереди, в формате пары "имя/значение"
• Обе технологии также позволяют просматривать сообщения без их блокировки, что может пригодиться при реализации браузера или проводника для очередей.
• В API для .NET для обмена сообщениями через посредника, предоставляемых служебной шиной, используются дуплексные TCP-соединения, позволяющие повысить производительность по сравнению с REST через HTTP. Они также поддерживают стандарт AMQP 1.0.
• Имена очередей службы хранилища могут содержать от 3 до 63 знаков, включая строчные буквы, цифры и дефисы (-). Дополнительные сведения см. в статье Именование очередей и метаданных.
• Имя очереди служебной шины может содержать до 260 символов. При этом действуют менее жесткие правила именования: имена очереди служебной шины могут содержать буквы, цифры, точки, дефисы и знаки подчеркивания.

Проверка подлинности и авторизация

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

Дополнительная информация:

• В обеих технологиях очередей требуется аутентификация при каждом запросе. Общие очереди с анонимным доступом не поддерживаются.
• Используя проверку подлинности на основе подписанного URL-доступа (SAS), можно создать правило авторизации общего доступа в очереди, которое предоставляет пользователям доступ только для записи, только для чтения или для полного доступа. Дополнительные сведения см. в статьях о проверке подлинности SAS для службы хранилища Azure и для Служебной шины Azure.
• Обе очереди поддерживают авторизацию доступа с помощью идентификатора Microsoft Entra. Авторизация пользователей или приложений с помощью маркера OAuth 2.0, возвращаемого идентификатором Microsoft Entra, обеспечивает более высокую безопасность и простоту использования через подписанные URL-адреса (SAS). С идентификатором Microsoft Entra не требуется хранить маркеры в коде и риск потенциальных уязвимостей безопасности. Дополнительные сведения см. в разделе служба хранилища Azure — проверка подлинности Microsoft Entra и Служебная шина Azure — проверка подлинности Microsoft Entra.

Заключение

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

Вы можете выбрать служба хранилища очереди по следующим причинам:

• Если приложение уже использует основные возможности Microsoft Azure
• Если требуется базовая связь и обмен сообщениями между службами
• Требуются очереди, которые могут быть размером более 80 ГБ

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

• Сеансы
• Транзакции
• Обнаружение повторяющихся записей
• Автоматическое перемещение в очередь недоставленных сообщений
• Устойчивые возможности публикации и подписки

Следующие шаги

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

• Начало работы с очередями служебной шины
• Как использовать службу хранилища очередей
• Рекомендации по повышению производительности с помощью обмена сообщениями через брокер в служебной шине