Очереди хранилища и очереди шины Service Bus: сравнение и различия.
В этой статье анализируются различия и сходства между двумя типами очередей, предлагаемыми Microsoft Azure: очередями хранилища и очередями шины обслуживания. Используя эти сведения, можно более точно выбирать решение, которое наилучшим образом соответствует вашим потребностям.
Введение
Azure поддерживает два типа очередей: очереди службы хранилища и очереди служебной шины.
Очереди службы хранилища являются частью инфраструктуры службы хранилища Azure. Они позволяют хранить большое количество сообщений. Доступ к сообщениям возможен из любой точки мира с помощью вызовов с проверкой подлинности по протоколу HTTP или HTTPS. Максимальный размер сообщения в очереди составляет 64 КБ. Очередь может содержать миллионы сообщений, ограничиваясь лишь общей емкостью учетной записи хранения. Очереди обычно используются для создания списка невыполненных заданий для асинхронной обработки. Дополнительные сведения см. в статье Что такое очереди хранилища Azure.
Очереди служебной шины входят в более обширную инфраструктуру обмена сообщениями Azure, поддерживающую очереди, публикации и подписки, а также более сложные шаблоны интеграции. Они предназначены для интеграции приложений или компонентов приложений, которые могут охватывать несколько протоколов связи, контрактов данных, доменов доверия или сетевых сред. Дополнительную информацию об очередях, темах и подписках службы Service Bus см. в статье Очереди, темы и подписки службы Service Bus.
Рекомендации по выбору технологии
Очереди службы хранилища и очереди служебной шины несколько отличаются наборами функций. В зависимости от потребностей конкретного решения можно выбрать один или оба варианта.
При выборе технологии очередей под конкретные цели и задачи архитекторам и разработчикам решений следует принимать во внимание приведенные ниже рекомендации.
Рассмотрите возможность использования очередей хранилища Storage
Ниже приведены случаи, в которых архитекторам и разработчикам решений рекомендуется использовать очереди службы хранилища.
- Приложение должно хранить более 80 ГБ сообщений в очереди.
- Нужно, чтобы приложение отслеживало ход обработки сообщения внутри очереди. Это полезно, если работник, обрабатывающий сообщение, выходит из строя. Другой работник сможет использовать эту информацию, чтобы продолжить с того места, где остановился предыдущий.
- Вам требуются серверные журналы всех транзакций, выполненных в отношении ваших очередей.
Рассмотрите возможность использования очередей Service Bus
В следующих случаях архитекторам и разработчикам решений рекомендуется использовать очереди служебной шины:
- Решение должно быть способно получать сообщения, не опрашивая очередь. С помощью 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 в очередях шины приложений необходимо использовать сеансы обмена сообщениями. Если приложение завершает работу во время обработки сообщения, полученного в режиме "Просмотр и блокировка", в следующий раз, когда получатель очереди принимает сессию обмена сообщениями, она начнется с сбойного сообщения после истечения срока блокировки сессии.
- Очереди хранилища предназначены для поддержки стандартных сценариев очередей, таких как следующие:
- Отделение компонентов приложения для повышения масштабируемости и устойчивости к сбоям
- Выравнивание нагрузки
- Создание рабочих процессов.
- Можно избежать несоответствий в обработке сообщений в контексте сеансов служебной шины, если использовать состояние сеанса для хранения состояния приложения с указанием хода обработки последовательности из сообщений сеанса, а также с помощью транзакций для обработки полученных сообщений и обновления состояния сеанса. Этот тип функции согласованности иногда называется обработка в режиме «только один раз» в продуктах других поставщиков. Любые сбои транзакций, очевидно, приводят к тому, что сообщения будут доставлены повторно, поэтому такой термин недостаточно точный.
- Очереди службы хранилища предоставляют единообразную и согласованную модель программирования для очередей, таблиц и BLOB-объектов как разработчикам, так и специалистам по эксплуатации.
- Очереди службы Service Bus обеспечивают поддержку локальных транзакций в контексте одной очереди.
- Режим Получение и удаление, поддерживаемый служебной шиной, позволяет сократить число операций обмена сообщениями (и связанные с этим расходы) за счет понижения уровня гарантии доставки.
- Очереди хранилища предоставляют арендаторам возможность продления аренды сообщений. Благодаря этой функции рабочие процессы могут поддерживать временные права на сообщения. Поэтому в случае сбоя одного рабочего сообщение может быть быстро обработано другим рабочим. Кроме того, работник может продлить время аренды сообщения, если для его обработки требуется больше времени, чем предусмотрено текущей арендой.
- Очереди хранилища предоставляют тайм-аут видимости, который можно задать при постановке в очередь или извлечении из очереди сообщения. Кроме того, можно обновлять значения аренды сообщения в рабочем режиме, а также использовать разные значения для разных сообщений в рамках одной очереди. Время ожидания блокировки служебной шины определяются в метаданных очереди. Тем не менее можно продлевать блокировку сообщения на предварительно заданное время вручную или использовать функцию автоматического продления блокировки, с помощью которой клиент управляет продлением блокировок вместо вас.
- Максимальное время ожидания для блокирующей операции получения в очередях Service Bus составляет 24 дня. Однако таймауты в системах REST имеют максимальное значение 55 секунд.
- Служебная шина позволяет выполнять пакетную обработку на стороне клиента. Это означает, что клиент очереди может отправлять несколько сообщений в рамках одной операции отправки. Пакетная обработка возможна только для операций асинхронной отправки.
- Функции, такие как ограничение в 200 ТБ для очередей хранения (больше при виртуализации учетных записей) и отсутствие ограничений на количество очередей, делают эту платформу идеальной для поставщиков SaaS.
- Очереди службы хранилища предоставляют гибкий и эффективный механизм управления делегированным доступом.
Расширенные возможности
В этом разделе сравниваются расширенные возможности очередей хранилища и очередей Service Bus.
| Критерии сравнения | Очереди хранилища | Очереди служебной шины |
|---|---|---|
| Доставка по расписанию | Да | Да |
| Автоматическое архивирование "мертвой почты" | Нет | Да |
| Увеличение срока жизни очереди | Да (с помощью изменения времени ожидания видимости) |
Да (используется выделенная функция API) |
| Поддержка проблемных сообщений | Да | Да |
| Обновление "на месте" | Да | Да |
| Журнал транзакций на стороне сервера | Да | Нет |
| Метрики хранения | Да Минутные метрики в режиме реального времени предоставляют сведения о доступности, TPS, количестве вызовов API, количестве ошибок и т. д. Все происходит в режиме реального времени, они агрегируются поминутно, и уже через несколько минут можно узнать, что только что произошло на производстве. Дополнительные сведения см. в разделе О метриках аналитики хранилища. |
Да Сведения о метриках, поддерживаемых служебной шиной Azure, см. в разделе Метрики сообщений. |
| Управление состоянием | Нет | Да (Активный, Отключённый, ОтправкаОтключена, ПолучениеОтключено. Дополнительные сведения об этих состояниях см. в разделе Состояние очереди) |
| Автоматическая переадресация сообщений | Нет | Да |
| Функция очистки очереди | Да | Да |
| Группы сообщений | Нет | Да (с помощью сеансов обмена сообщениями) |
| Состояние приложений по группам сообщений | Нет | Да |
| Поиск повторяющихся данных | Нет | Да (настраивается на стороне отправителя) |
| Просмотр групп сообщений | Нет | Да |
| Выборка сеансов сообщений по идентификатору | Нет | Да |
Дополнительная информация:
- Обе технологии очередей позволяют запланировать доставку сообщения в более позднее время.
- Авто-перенаправление очередей позволяет тысячам очередей автоматически перенаправлять свои сообщения в одну очередь, из которой получающее приложение обрабатывает эти сообщения. Этот механизм можно использовать для обеспечения безопасности, управления потоком и изоляции хранилищ разных создателей сообщений.
- Хранилищные очереди поддерживают обновление содержимого сообщений. Вы можете использовать эту возможность для сохранения в сообщении сведений о состоянии и поэтапного обновления хода выполнения операций. Это позволит продолжать обработку сообщений с последней известной контрольной точки, а не с самого начала. В очередях Service Bus можно реализовать тот же сценарий, используя сеансы сообщений. Дополнительные сведения см. в статье Состояние сеанса обмена сообщениями.
- Очереди служебной шины поддерживают систему мертвых писем. Это может быть полезно для изоляции сообщений, которые соответствуют следующим критериям:
- Принимающему приложению не удалось успешно обработать сообщения
- Сообщения не достигли места назначения из-за просроченного срока жизни (TTL), указанного в свойстве. Значение TTL определяет время, в течение которого сообщение остается в очереди. При использовании Service Bus, по истечении времени жизни сообщение перемещается в специальную очередь, называемую $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. Это число распределяется между отправителями и получателями. После достижения квоты запросы на дополнительные соединения отклоняются, а вызывающий код получает исключение. Это ограничение не применяется к клиентам, подключающимся к очередям с помощью интерфейса API на основе REST.
- Чтобы масштабировать до 10 000 очередей с помощью стандартной единицы учета запасов (SKU) служебной шины или 1000 очередей/единиц обмена сообщениями с премиальной версией служебной шины (SKU Premium), можно также создать дополнительные пространства имен с помощью портала Azure.
Управление и операции
В этом разделе сравниваются функции управления, предоставляемые очередями хранилища и очередями Service Bus.
| Критерии сравнения | Очереди для хранения данных | Очереди 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.
| Критерии сравнения | Очереди хранилища | Очереди 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.
Заключение
Благодаря более глубокому пониманию двух технологий очередей, вы сможете сделать более обоснованный выбор, какую технологию очередей использовать и когда. Решение о том, когда использовать очереди хранилища или очереди шины служб, зависит от множества факторов. Эти факторы сильно зависят от индивидуальных потребностей приложения и его архитектуры.
Вы можете предпочесть выбрать очереди хранилища по следующим причинам, как, например:
- Если приложение уже использует основные возможности Microsoft Azure
- Если требуется базовая связь и обмен сообщениями между службами
- Требуются очереди, которые могут быть размером более 80 ГБ
Очереди шины сервиса предлагают множество расширенных функций, таких как следующие. Таким образом, они могут быть предпочтительнее, если вы создаете гибридное приложение или если ваше приложение в противном случае требует этих функций.
- Сеансы
- Транзакции
- Обнаружение дублей
- Автоматическая обработка недоставленных сообщений
- Устойчивые возможности публикации и подписки
Следующие шаги
Для получения рекомендаций и информации по использованию очередей хранилища или очередей Service Bus ознакомьтесь со следующими статьями.