Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье анализируются различия и сходства между двумя типами очередей, предлагаемыми Microsoft Azure: очередями хранилища и очередями шины обслуживания. Используя эти сведения, можно более точно выбирать решение, которое наилучшим образом соответствует вашим потребностям.
Введение
Azure поддерживает два типа очередей: очереди службы хранилища и очереди служебной шины.
Очереди службы хранилища являются частью инфраструктуры службы хранилища Azure. Они позволяют хранить большое количество сообщений. Доступ к сообщениям возможен из любой точки мира с помощью вызовов с проверкой подлинности по протоколу HTTP или HTTPS. Максимальный размер сообщения в очереди составляет 64 КБ. Очередь может содержать миллионы сообщений, ограничиваясь лишь общей емкостью учетной записи хранения. Очереди обычно используются для создания списка невыполненных заданий для асинхронной обработки. Дополнительные сведения см. в статье Что такое очереди хранилища Azure.
Очереди служебной шины входят в более обширную инфраструктуру обмена сообщениями Azure, поддерживающую очереди, публикации и подписки, а также более сложные шаблоны интеграции. Они предназначены для интеграции приложений или компонентов приложений, которые могут охватывать несколько протоколов связи, контрактов данных, доменов доверия или сетевых сред. Дополнительные сведения об очередях, темах и подписках Service Bus см. в разделе очереди, темы и подписки Service Bus.
Рекомендации по выбору технологии
Очереди службы хранилища и очереди служебной шины несколько отличаются наборами функций. В зависимости от потребностей конкретного решения можно выбрать один или оба варианта.
При выборе технологии очередей под конкретные цели и задачи архитекторам и разработчикам решений следует принимать во внимание приведенные ниже рекомендации.
Рассмотрите возможность использования очередей хранилища Storage
В качестве архитектора решений или разработчика рассмотрите возможность использования очередей хранилища когда:
- Приложение должно хранить более 80 ГБ сообщений в очереди.
- Нужно, чтобы приложение отслеживало ход обработки сообщения внутри очереди. Эта функция полезна, если рабочий процесс обработки сообщения завершается сбоем. Другой работник сможет использовать эту информацию, чтобы продолжить с того места, где остановился предыдущий.
- Вам требуются серверные журналы всех транзакций, выполненных в отношении ваших очередей.
Рассмотрите возможность использования очередей Service Bus
В качестве архитектора решения или разработчика рекомендуется использовать очереди служебной шины , когда:
- Решение должно быть способно получать сообщения, не опрашивая очередь. Используя служебную шину, эту цель можно достичь с помощью операции получения длинного опроса с протоколами на основе TCP, поддерживаемыми служебной шиной.
- В вашем решении требуется, чтобы очередь гарантированно исполняла задачи в порядке их очередности (FIFO), то есть в том порядке, в котором они поступают.
- В решении необходима поддержка автоматического обнаружения дубликатов.
- Вы хотите, чтобы приложение обрабатывало сообщения как параллельные долговременные потоки (сообщения связываются с потоком с помощью свойства session ID сообщения). В этой модели каждый узел принимающего приложения конкурирует за потоки, а не за сообщения. Когда поток передается принимающему узлу, узел может с помощью транзакций проверить состояние потока приложения.
- Вашему решению требуется транзакционный режим работы и атомарность при отправке или получении нескольких сообщений из очереди.
- Приложение обрабатывает сообщения, размер которых может превышать 64 КБ, но вряд ли достигнет ограничений в 256 КБ или 1 МБ, которые действуют в зависимости от выбранного уровня службы (при этом сами очереди Служебная шина могут обрабатывать сообщения размером до 100 МБ).
- Необходимо предоставить очередям модель доступа на основе ролей, а также различные права и разрешения для отправителей и получателей. Дополнительные сведения см. в следующих статьях:
- Размер очереди не превышает 80 ГБ.
- Вы хотите использовать протокол обмена сообщениями на основе стандартов AMQP 1.0. Дополнительные сведения об AMQP см. в статье Общие сведения о протоколе AMQP для служебной шины.
- Вы представляете себе в будущем постепенный переход от коммуникаций точка-точка на основе очередей к шаблону обмена сообщениями по модели публикации-подписки. Этот шаблон обеспечивает интеграцию дополнительных получателей (подписчиков). Каждый получатель получает независимые копии некоторых или всех сообщений, отправленных в очередь.
- В решении для обмена сообщениями должна поддерживаться гарантия доставки «не более одного раза» и «как минимум один раз» без необходимости создания дополнительных компонентов инфраструктуры.
- Ваше решение должно публиковать и использовать пакеты сообщений.
Сравните очереди хранилища и очереди Microsoft Service Bus
В таблицах в следующих разделах приводится логическая группировка возможностей очереди. Они позволяют вам быстро сравнить возможности, доступные как в очередях хранилища Azure, так и в очередях служебной шины.
Основные возможности
В этом разделе сравниваются некоторые из основных возможностей очередей службы хранилища и служебной шины.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Гарантия на заказ | Нет Дополнительные сведения см. в первом примечании в разделе Дополнительные сведения. |
Да — FIFO ("первым прибыл, первым обслужен") (с помощью сеансов обмена сообщениями) |
| Гарантированный метод доставки | Как минимум один раз | По крайней мере один раз (с помощью режима получения PeekLock). Это значение по умолчанию) At-Most-Once (с помощью режима получения ReceiveAndDelete) Дополнительные сведения о различных режимах получения |
| Поддержка атомарной операции | Нет | Да |
| Поведение при приеме | Неблокирующий (немедленно завершается, если новые сообщения не найдены) |
Блокировка с временем ожидания или без нее (продолжительный опрос, или "метод Comet") Неблокирующий (только с помощью управляемого API .NET) |
| API в стиле Push | Нет | Да Наши SDK для .NET, Java, JavaScript и Go предоставляют push-API. |
| Режим получения | Просмотр и аренда | Просмотр и блокировка Прием и удаление |
| Режим монопольного доступа | На основе аренды | На основе блокировки |
| Продолжительность аренды или блокировки | 30 секунд (по умолчанию) 7 дней (максимум) (вы можете продлить или освободить аренду сообщения с помощью API UpdateMessage .) |
30 секунд (по умолчанию) Вы можете продлевать блокировку сообщения на такое же время каждый раз вручную или использовать функцию автоматического продления блокировки, с помощью которой клиент управляет продлением блокировок вместо вас. |
| Точность аренды/блокировки | Уровень сообщения Каждое сообщение может иметь другое значение времени ожидания, которое можно обновить по мере необходимости при обработке сообщения с помощью API UpdateMessage. |
Уровень очереди (каждая очередь имеет точность блокировки, примененную ко всем ее сообщениям, но блокировку можно продлить, как описано в предыдущей строке) |
| Получение в пакетном режиме | Да (задать точное количество извлекаемых сообщений, до 32 сообщений максимум) |
Да (неявно включив свойство предварительной выборки или явно используя транзакции) |
| Отправка в пакетном режиме | Нет | Да (с помощью транзакций или пакетной обработки на стороне клиента) |
Дополнительная информация:
- Сообщения в очередях службы хранилища обычно располагаются по принципу "первым пришел, первым ушел", но иногда могут быть в другом порядке. Например, когда время ожидания видимости сообщения истекает, потому что клиентское приложение завершилось сбоем во время обработки сообщения. Когда истекает время ожидания видимости, сообщение снова становится видимым в очереди для другого работника, чтобы извлечь его из очереди. В этот момент сообщение, ставшее вновь видимым, может быть помещено в очередь для повторного извлечения из неё.
- Для гарантированного упорядочения сообщений по методу FIFO в очередях шины приложений необходимо использовать сеансы обмена сообщениями. Если приложение срывается во время обработки сообщения, полученного в режиме "Просмотр и блокировка", при следующем запуске приемника очереди принимается сеанс обмена сообщениями, который начинается с неисправленного сообщения после истечения срока действия блокировки сеанса.
- Очереди хранилища предназначены для поддержки стандартных сценариев очередей, таких как следующие:
- Отделение компонентов приложения для повышения масштабируемости и устойчивости к сбоям
- Выравнивание нагрузки
- Создание рабочих процессов.
- Вы можете избежать несоответствий в обработке сообщений в контексте сеансов Service Bus, используя состояние сеанса для хранения состояния приложения относительно хода обработки последовательности сообщений сеанса. Также применяйте транзакции для урегулирования полученных сообщений и обновления состояния сеанса. Этот тип функции согласованности иногда называется обработка в режиме «только один раз» в продуктах других поставщиков. Все ошибки транзакций вызывают повторную доставку сообщений, и именно поэтому термин не является точным.
- Очереди службы хранилища предоставляют единообразную и согласованную модель программирования для очередей, таблиц и BLOB-объектов как разработчикам, так и специалистам по эксплуатации.
- Очереди службы Service Bus обеспечивают поддержку локальных транзакций в контексте одной очереди.
- Режим Получение и удаление, поддерживаемый служебной шиной, позволяет сократить число операций обмена сообщениями (и связанные с этим расходы) за счет понижения уровня гарантии доставки.
- Очереди хранилища предоставляют арендаторам возможность продления аренды сообщений. Благодаря этой функции рабочие процессы могут поддерживать временные права на сообщения. Если рабочий процесс завершается сбоем, другой работник может быстро обработать сообщение. Кроме того, работник может продлить время аренды сообщения, если для его обработки требуется больше времени, чем предусмотрено текущей арендой.
- Очереди хранилища предоставляют время ожидания видимости, которое можно задать при вложении или выводе сообщения. Кроме того, можно обновлять значения аренды сообщения в рабочем режиме, а также использовать разные значения для разных сообщений в рамках одной очереди. Время ожидания блокировки служебной шины определяются в метаданных очереди. Тем не менее можно продлевать блокировку сообщения на предварительно заданное время вручную или использовать функцию автоматического продления блокировки, с помощью которой клиент управляет продлением блокировок вместо вас.
- Максимальное время ожидания для операции блокирующего получения в очередях Service Bus составляет 24 дня. Однако время ожидания на основе REST имеют максимальное значение 55 секунд.
- Служебная шина позволяет выполнять пакетную обработку на стороне клиента. Это означает, что клиент очереди может отправлять несколько сообщений в рамках одной операции отправки. Пакетная обработка возможна только для операций асинхронной отправки.
- Функции, такие как ограничение в 200 ТБ для очередей хранения (больше при виртуализации учетных записей) и отсутствие ограничений на количество очередей, делают эту платформу идеальной для поставщиков SaaS.
- Очереди службы хранилища предоставляют гибкий и эффективный механизм управления делегированным доступом.
Расширенные возможности
В этом разделе сравниваются расширенные возможности очередей хранилища и очередей Service Bus.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Доставка по расписанию | Да | Да |
| Автоматическое архивирование "мертвой почты" | Нет | Да |
| Увеличение срока жизни очереди | Да (с помощью изменения времени ожидания видимости) |
Да (используется выделенная функция API) |
| Поддержка проблемных сообщений | Да | Да |
| Обновление "на месте" | Да | Да |
| Журнал транзакций на стороне сервера | Да | Нет |
| Метрики хранения | Да Минутные метрики в режиме реального времени предоставляют сведения о доступности, TPS, количестве вызовов API, количестве ошибок и т. д. Они все в режиме реального времени, агрегируются каждую минуту и сообщаются в течение нескольких минут после того, как это произошло в производственной среде. Дополнительные сведения см. в разделе О метриках аналитики хранилища. |
Да Сведения о метриках, поддерживаемых служебной шиной Azure, см. в разделе Метрики сообщений. |
| Управление состоянием | Нет | Да (Активный, Отключённый, ОтправкаОтключена, ПолучениеОтключено. Дополнительные сведения об этих состояниях см. в разделе Состояние очереди) |
| Автоматическая переадресация сообщений | Нет | Да |
| Функция очистки очереди | Да | Да |
| Группы сообщений | Нет | Да (с помощью сеансов обмена сообщениями) |
| Состояние приложений по группам сообщений | Нет | Да |
| Поиск повторяющихся данных | Нет | Да (настраивается на стороне отправителя) |
| Просмотр групп сообщений | Нет | Да |
| Выборка сеансов сообщений по идентификатору | Нет | Да |
Дополнительная информация:
- Обе технологии очередей позволяют запланировать доставку сообщения в более позднее время.
- Авто-перенаправление очередей позволяет тысячам очередей автоматически перенаправлять свои сообщения в одну очередь, из которой получающее приложение обрабатывает эти сообщения. Этот механизм можно использовать для обеспечения безопасности, управления потоком и изоляции хранилищ разных создателей сообщений.
- Хранилищные очереди поддерживают обновление содержимого сообщений. Вы можете использовать эту возможность для сохранения в сообщении сведений о состоянии и поэтапного обновления хода выполнения операций. Это позволит продолжать обработку сообщений с последней известной контрольной точки, а не с самого начала. С помощью очередей Service Bus можно реализовать тот же сценарий, используя сеансы сообщений. Дополнительные сведения см. в статье Состояние сеанса обмена сообщениями.
- Очереди служебной шины поддерживают систему мертвых писем. Это может быть полезно для изоляции сообщений, которые соответствуют следующим критериям:
- Сообщения не могут быть успешно обработаны принимающей приложением.
- Сообщения не достигли места назначения из-за просроченного срока жизни (TTL), указанного в свойстве. Значение TTL определяет время, в течение которого сообщение остается в очереди. При использовании служебной шины сообщение перемещается в специальную очередь с именем $DeadLetterQueue, когда срок действия срока жизни истекает.
- Чтобы найти подозрительные сообщения в очередях службы хранилища, приложение проверяет свойство сообщения DequeueCount при выведении его из очереди. Если значение DequeueCount превышает заданное пороговое значение, сообщение перемещается в определяемую приложением "мертвую очередь".
- Очереди службы хранилища позволяют получить подробный журнал всех транзакций, выполненных с очередью, а также агрегированные метрики. Обе функции полезны для отладки и понимания принципов использования очередей службы хранилища в приложении. Они также помогают оптимизировать производительность приложения и сократить расходы, связанные с использованием очередей.
- Сеансы сообщений, поддерживаемые служебной шиной, позволяют связать сообщения, принадлежащие логической группе, с получателем. Это создает сходство, как в случае с сеансами, между сообщениями и их соответствующими получателями. Чтобы включить эту расширенную функциональность в Service Bus, нужно задать свойство идентификатора сеанса (session ID) для сообщения. Получатели смогут выполнять прослушку по конкретному идентификатору сеанса и получать сообщения с этим идентификатором.
- Функция обнаружения дубликатов, поддерживаемая очередями Service Bus, автоматически удаляет дубликаты сообщений, отправленные в очередь или тему, используя свойство message ID.
Емкость и квоты
В этом разделе сравниваются очереди хранилища и служебная шина очереди с точки зрения емкости и квот, которые могут применяться.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Максимальный размер очереди | 5 PiB (в рамках емкости одной учетной записи хранения) |
От 1 до 80 ГБ (Уровень "Премиум" или "Стандартный" с секционированием) |
| Максимальный размер сообщения | 64 КБ (48 КБ при использовании кодировки Base 64) Azure поддерживает большие сообщения за счет сочетания очередей и блобов; благодаря этому можно поставить в очередь до 200 ГБ для одного элемента. |
256 КБ, 1 МБ или 100 МБ (включая заголовок и текст; максимальный размер заголовка — 64 КБ). Зависит от уровня служб. |
| Максимальный срок жизни сообщения | Infinite (API версии 2017-07-27 или более поздней) | TimeSpan.MaxValue (максимальное значение для TimeSpan) |
| Максимальное количество очередей | Не ограничено | 10 000 (уровень "Стандартный") 1000 / Единица обмена сообщениями (категория "Премиум") (на пространство имен службы) |
| Максимальное количество параллельных клиентов | Не ограничено | 5,000 |
Дополнительная информация:
- Сервисная шина применяет лимиты на размер очереди. Максимальный размер очереди указывается при ее создании. Значение может составлять от 1 до 80 ГБ. Если размер очереди достигает этого ограничения, служебная шина отклоняет дополнительные входящие сообщения, и вызывающий получает исключение. Дополнительные сведения о квотах в Service Bus см. в разделе Квоты Service Bus.
- На уровне обмена сообщениями "Стандартный" можно создавать очереди и разделы служебной шины размером в 1 или 2, 3, 4 или 5 ГБ (по умолчанию). При активации разделения на разделы в уровне "Стандартный" Service Bus создаёт 16 копий (16 разделов) сущности, каждая того же указанного размера. Поэтому при создании очереди размером 5 ГБ с 16 разделами максимальный размер очереди составит 80 ГБ (5 × 16). Вы можете увидеть максимальный размер секционированной очереди или темы на портале Azure.
- При использовании очередей службы хранилища содержимое сообщений, небезопасное с точки зрения XML, должно кодироваться в формат Base64. При кодировке сообщения методом Base64 размер полезных данных может достигать 48 KБ (а не 64 КБ).
- Каждое сообщение в очереди Service Bus состоит из двух частей: заголовка и тела. Общий размер сообщения не может превышать максимальный размер, поддерживаемый уровнем служб.
- Когда клиенты взаимодействуют с очередями служебной шины по протоколу TCP, максимальное количество одновременных подключений к отдельной очереди служебной шины не может превышать 100. Это число распределяется между отправителями и получателями. Если эта квота будет достигнута, запросы на дополнительные подключения будут отклонены, и вызывающий код получит исключение. Это ограничение не применяется для клиентов, подключающихся к очередям с помощью REST API.
- Чтобы масштабировать более 10 000 очередей с уровнем "Стандартный" служебной шины или 1000 очередей или единиц обмена сообщениями с уровнем "Премиум" служебной шины, можно также создать дополнительные пространства имен с помощью портала Azure.
Управление и операции
В этом разделе сравниваются функции управления, предоставляемые очередями хранилища и очередями Service Bus.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Протокол управления | REST по протоколу HTTP/HTTPS | REST по протоколу HTTPS |
| Протокол выполнения | REST по протоколу HTTP/HTTPS | REST по протоколу HTTPS Стандарт AMQP 1.0 (TCP с TLS) |
| API для .NET | Да (API клиента службы хранилища для .NET) |
Да (API служебной шины для .NET) |
| Нативный C++ | Да | Да |
| Java API | Да | Да |
| API для PHP | Да | Да |
| API для Node.js | Да | Да |
| Поддержка произвольных метаданных | Да | Нет |
| Правила именования очередей | Может содержать до 63 символов (Буквы в имени очереди должны быть строчными.) |
До 260 символов длиной (В путях и именах очередей регистр не учитывается.) |
| Функция получения длины очереди | Да (Приблизительное значение, если сообщение не удаляется после истечения срока жизни.) |
Да (Точное значение в определенный момент времени.) |
| Функция просмотра | Да | Да |
Дополнительная информация:
- Очереди хранилища поддерживают произвольные атрибуты, которые можно применить к описанию очереди в виде пар "имя-значение".
- Обе технологии очередей предлагают возможность просматривать сообщение без блокировки, что может быть полезно при реализации обозревателя очередей или средства браузера.
- API-интерфейсы обмена сообщениями через посредники служебной шины .NET используют полно дуплексные TCP-подключения для повышения производительности по сравнению с REST по протоколу HTTP и поддерживают стандартный протокол AMQP 1.0.
- Имена очередей хранилища могут иметь длину 3–63 символов и могут содержать строчные буквы, цифры и дефисы. Дополнительные сведения см. в статье Именование очередей и метаданных.
- Имя очереди служебной шины Service Bus может содержать до 260 символов, а также действует менее жесткие правила именования. Имена очередей Service Bus могут содержать буквы, цифры, точки, дефисы и знаки подчеркивания.
Проверка подлинности и авторизация
В этом разделе рассматриваются функции аутентификации и авторизации, поддерживаемые очередями хранилища и очередями Service Bus.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Проверка подлинности | Симметричный ключ и управление доступом на основе ролей (RBAC) | Симметричный ключ и управление доступом на основе ролей (RBAC) |
| Объединение провайдеров удостоверений | Да | Да |
Дополнительная информация:
- Для каждого запроса к любой из технологий очередей требуется аутентификация. Общие очереди с анонимным доступом не поддерживаются.
- С помощью проверки подлинности с использованием токена общего доступа (SAS) можно создать правило авторизации общего доступа в очереди, которое может предоставить пользователям доступ только для записи, только для чтения или полный доступ. Для получения дополнительной информации см. Проверка подлинности SAS для Azure Storage и Проверка подлинности SAS для Azure Service Bus.
- Обе очереди поддерживают авторизацию доступа с помощью идентификатора Microsoft Entra. Авторизация пользователей или приложений с помощью токена OAuth 2.0, возвращаемого Microsoft Entra ID, обеспечивает более высокую безопасность и удобство использования по сравнению с подписанными сигнатурами доступа (SAS). При использовании Microsoft Entra ID нет необходимости хранить токены в коде и подвергать систему потенциальным уязвимостям безопасности. Дополнительные сведения см. в разделе Azure Storage - проверка подлинности Microsoft Entra и Azure Service Bus - проверка подлинности Microsoft Entra.
Заключение
Понимая две технологии, вы можете принять более информированное решение о том, какую технологию очередей следует использовать и когда. Выбор между очередями Azure Storage или очередями Azure Service Bus зависит от многих факторов. Эти факторы сильно зависят от индивидуальных потребностей приложения и его архитектуры.
Вы можете предпочесть выбрать очереди хранилища по следующим причинам, как, например:
- Приложение уже использует основные возможности Microsoft Azure
- Требуется базовое взаимодействие и обмен сообщениями между службами
- Вам нужны очереди размером более 80 ГБ
Очереди шины сервиса предлагают множество расширенных функций, таких как следующие. Таким образом, они могут быть предпочтительнее, если вы создаете гибридное приложение или если ваше приложение в противном случае требует этих функций.
- Сеансы
- Транзакции
- Обнаружение дублей
- Автоматическая обработка недоставленных сообщений
- Устойчивые возможности публикации и подписки
Следующие шаги
Для получения рекомендаций и информации по использованию очередей хранилища или очередей Service Bus ознакомьтесь со следующими статьями.