Windows Azure: Queues и Service Bus Queues – сходства и различия

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

Введение

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

Очереди Windows Azure, входящие в состав инфраструктуры хранилища Windows Azure, поддерживают простой REST-интерфейс с функциями Get/Put/Peek (Получение/Запись/Считывание) для создания надежной и отказоустойчивой системы обмена сообщениями между службами и внутри них.

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

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

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

Выбор технологии

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

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

Архитекторам или разработчикам решения необходимо рассмотреть возможность использования очередей Windows Azure в следующих случаях.

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

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

Требуется полная интеграция со стеком обмена данными Windows Communication Foundation (WCF), который реализован в платформе .NET Framework.
Необходима поддержка автоматического выявления повторяющихся сообщений.
Требуется возможность обработки связанных сообщений как отдельной логической группы.
Требуется поддержка транзакций и атомарности при отправке или получении нескольких сообщений из очереди.
Время жизни (time-to-live, TTL) для рабочей нагрузки конкретных приложений может превышать семидневный период.
Приложение обрабатывает сообщения, длина которых может превышать 64 КБ, но скорее всего не достигнет предела, равного 256 КБ.
Требуется поддержка очереди, которая обеспечивает гарантированную доставку сообщений в режиме «первым вошел, первым вышел» (first-in-first-out, FIFO).
Требуется возможность получения сообщений без опроса очереди. При использовании шины обслуживания такую возможность дает операция получения с длительным временем опроса.
Необходимо реализовать модель доступа к очередям на основе ролей, а также обеспечить поддержку различных прав и полномочий для отправителей и получателей.
Размеры используемых очередей не превысят 5 ГБ.
Существуют перспективы миграции от обмена данными по схеме «точка-точка» на основе очередей к применению шаблона обмена сообщениями. Этот шаблон обеспечит комплексную интеграцию дополнительных получателей (подписчиков), каждый из которых получает независимые копии некоторых или всех сообщений, отправляемых в очередь. Это возможно благодаря функции публикации и подписки, встроенной в шину обслуживания.
Решение для обмена сообщениями должно поддерживать гарантию доставки At-Most-Once (Максимум однажды) без необходимости разработки дополнительных компонентов инфраструктуры.
Требуется возможность публикации и обработки пакетов сообщений.

Сравнение очередей Windows Azure и очередей шины обслуживания

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

Базовые возможности

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

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Гарантия упорядочивания	Нет	Да — режим «первым вошел, первым вышел» (FIFO) (с помощью использования сеансов обмена сообщениями)
Гарантия доставки	At-Least-Once (Минимум однажды)	At-Least-Once (Минимум однажды) At-Most-Once (Максимум однажды)
Поддержка транзакций	Нет	Да (с помощью локальных транзакций)
Реакция на получение	Неблокирующий (завершается немедленно, если новые сообщения не найдены)	Блокирующий (со временем ожидания и без него) (поддержка длинных интервалов опроса или метода на основе долгоживущих HTTP-соединений) Неблокирующий (только с применением API, управляемого платформой .NET)
Режим получения	Считывание и аренда	Считывание и блокировка Получение и удаление
Эксклюзивный режим доступа	На основе аренды	На основе блокировки
Длительность аренды и блокировки	30 секунд (по умолчанию) 7 дней (максимум)	60 секунд (по умолчанию) 5 минут (максимум)
Детализация аренды/блокировки	Уровень сообщений (каждое сообщение может иметь собственное значение времени ожидания)	Уровень очереди (каждая очередь имеет собственную детализацию блокировки, действующую для всех сообщений и зафиксированную на весь период жизни очереди)
Пакетное получение	Да (явное указание количества сообщений при получении, не более 32 сообщений)	Да (включение предварительной выборки неявным образом (с помощью параметра) или явным образом (с помощью транзакций))
Пакетная отправка	Нет	Да (с помощью транзакций или пакетной отправки со стороны клиента)

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

Для применения шаблона гарантированной доставки по схеме FIFO, применяемого в очередях шины обслуживания, необходимо использование сеансов обмена сообщениями. В случае критического сбоя приложения в ходе обработки сообщения, полученного в режиме Peek & Lock (Считывание и блокировка), при запуске следующего сеанса обмена сообщениями будет выдано сообщение о сбое по истечении времени ожидания.
Очереди шины обслуживания поддерживают гарантию доставки At-Least-Once. Кроме того, семантика режима At-Most-Once поддерживается с помощью состояний сеанса, в которых хранится состояние приложения, а также с помощью транзакций для атомизированного получения сообщений и обновления состояния сеанса. Служба рабочих процессов Windows Azure Workflow Service использует эту технику для обеспечения гарантированной доставки в режиме At-Most-Once.
Очереди шины обслуживания поддерживают локальные транзакции в контексте одной очереди.
Режим Receive and Delete (Получение и удаление), поддерживаемый шиной обслуживания, при снижении гарантий доставки позволяет сократить количество управляющих сообщений и снизить связанные с ними затраты.
Очереди Windows Azure поддерживают функцию аренды с возможностью продления аренды сообщений. Это позволяет рабочим процессам обеспечивать короткое время аренды сообщений. Благодаря этому, при критическом сбое рабочего процесса, другой рабочий процесс может оперативно обработать сообщение. Кроме того, рабочий процесс может продлевать аренду сообщения, если период его обработки превышает текущее время аренды.
Очереди Windows Azure поддерживают время ожидания видимости, которое можно задать при помещении сообщения в очередь или при извлечении его из очереди. Кроме того, можно обновлять сообщение, устанавливая новые значения параметров аренды в среде выполнения, а также обновлять различные параметры в сообщениях одной и той же очереди. В противоположность этому, шина обслуживания блокирует параметры времени ожидания, заданные в метаданных очереди. Эти параметры невозможно изменить без повторного создания очереди.
Максимальное время ожидания при выполнении операции блокирующего получения, доступное для шины обслуживания, составляет 24 дня.
Пакетная обработка на стороне клиента, поддерживаемая шиной обслуживания, позволяет клиенту очереди выполнять пакетную обработку нескольких сообщений в ходе одной операции отправки. Пакетная обработка доступна только для операций асинхронной отправки.

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

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

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Доставка по расписанию	Да	Да
Автоматическая маркировка удаляемых сообщений‏	Нет	Да
Отсроченная передача сообщений	Да (с помощью обновления на месте времени ожидания видимости)	Да (с помощью специализированной функции API)
Поддержка сообщений о сбое	Да	Да
Обновление на месте	Да	Нет
Журнал транзакций на стороне сервера	Да	Нет
Показатели хранилища	Да	Нет
Функция очистки очереди	Да	Нет
Группы сообщений	Нет	Да (с помощью сеансов обмена сообщениями)
Обнаружение повторяющихся сообщений	Нет	Да (настраивается на стороне отправителя)
Интеграция WCF	Нет	Да (содержит готовые привязки WCF)
Интеграция WF	Индивидуальная настройка (требует создания настраиваемого действия WF)	Собственный (содержит готовые действия WF)

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

По состоянию на ноябрь 2012 года обе технологии обработки очередей, реализованные в выпуске Windows Azure SDK, позволяют создавать расписания отложенной отправки сообщений.
Очереди Windows Azure обеспечивают обновление содержимого сообщений. Эта функция позволяет сохранять информацию о состоянии и добавлять в сообщение сведения о его обработке, чтобы продолжить обработку сообщения с последней известной контрольной точки, вместо того чтобы начинать ее заново.
Механизм пометки удаляемых сообщений поддерживается только очередями шины обслуживания. Он предназначен для изоляции сообщений, которые не удалось успешно обработать принимающим приложением. Этот механизм также используется, когда время жизни сообщения (TTL) истекло и сообщение не может достичь получателя. Значение TTL определяет период, в течение которого сообщение остается в очереди. При использовании шины обслуживания сообщение будет перемещено в специальную очередь, называемую $DeadLetterQueue по истечении времени его жизни.
Чтобы обнаружить сообщения о сбое в очередях Windows Azure, при удалении сообщения из очереди приложение анализирует свойство DequeueCount этого сообщения. Если значение DequeueCount превышает заданный порог, приложение перемещает сообщение в очередь сообщений, предназначенных для удаления.
Очереди Windows Azure позволяют вести подробные журналы всех транзакций, относящихся к очереди, а также журналы агрегированных показателей. Эти журналы предназначены для отладки и анализа использования очередей Windows Azure приложением. Они также полезны для оптимизации производительности приложения и сокращения затрат, связанных с использованием очередей.
Механизм «сеансов сообщений», поддерживаемый шиной обслуживания, позволяет связывать с конкретным получателем сообщения, принадлежащие определенной логической группе. В свою очередь, это приводит к созданию связи между сообщениями и получателями, по своим свойствам похожую на сеанс. Эту расширенную функцию шины обслуживания можно включить, настроив свойство SessionID сообщения. Получатели, ожидающие передачи конкретного идентификатора сеанса, могут получать сообщения с этим идентификатором.
Функция обнаружения повторяющихся сообщений поддерживается шиной обслуживания. Эта функция использует свойство MessageID и автоматически удаляет повторяющиеся сообщения, отправленные очереди или теме.

Мощности и квоты

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

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Максимальный размер сообщений	64 КБ (48 КБ при использовании кодировки Base64)	256 КБ (включая заголовок и текст сообщения; максимальный размер заголовка 64 КБ)
Максимальный размер очереди	100 ТБ (ограничен объемом одной учетной записи хранилища)	1, 2, 3, 4 или 5 ГБ (определяется при создании очереди)
Максимальный срок жизни сообщения	7 дней	Без ограничений
Максимальное количество очередей	Без ограничений	10 000 (для одного пространства имен службы, может быть увеличено)
Максимальное количество одновременно работающих клиентов	Без ограничений	Без ограничений (ограничение на 100 одновременных соединений относится только к обмену данными по протоколу TCP)

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

Для очередей Windows Azure необходимо использовать сообщения в кодировке Base64, если их содержимое не XML-безопасное. Для сообщения в формате Base64 полезная пользовательская нагрузка может уменьшиться с 64 до 48 КБ.
При использовании очередей шины обслуживания каждое сообщение, хранимое в очереди, состоит из двух частей: заголовка и текстового поля. Общая длина сообщения не может превышать 256 КБ.
При обмене данными между клиентами с помощью очередей шины обслуживания и протокола TCP можно создавать не более 100 одновременных соединений с одной очередью шины обслуживания. Это количество — общее для отправителей и получателей. При превышении квоты последующие запросы на создание дополнительных соединений будут отклонены; будет получено исключение с кодом вызова. Эта квота не относится к клиентам, которые подключаются к очередям с помощью API на основе REST.
Максимальный размер очереди принудительно устанавливается шиной обслуживания. Максимальный размер очереди указывается при создании очереди и может иметь значение 1, 2, 3, 4 или 5 ГБ. При превышении максимального размера очереди все последующие входящие сообщения будут отклонены с созданием исключения по коду вызова. Дополнительную информацию о квотах шины обслуживания см. в документе Windows Azure Service Bus Quotas (Квоты шины обслуживания Windows Azure).
Если вам требуются более 10 000 очередей в одном пространстве имен службы, связанной с шиной обслуживания, вы можете связаться с группой поддержки Windows Azure и попросить ее увеличить это значение. Если вам необходимо масштабировать решение и использовать более 10 000 очередей шины обслуживания, вы можете создать дополнительные пространства имен службы с помощью портала управления Windows Azure.

Управление и эксплуатация

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

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Протокол управления	REST поверх HTTP/HTTPS	REST поверх HTTPS
Протокол среды выполнения	REST поверх HTTP/HTTPS	REST поверх HTTPS TCP с поддержкой TLS
API под управлением .NET	Да (API клиента хранилища под управлением .NET)	Да (API обмена промежуточными сообщениями .NET)
Java API	Да	Да
PHP API	Да	Да
Node.js API	Да	Нет
Поддержка произвольных метаданных‏	Да	Нет
Правила именования очередей	Длина до 63 символов (в имени очереди необходимо использовать только нижний регистр)	Длина до 260 символов (имена очередей не чувствительны к регистру)
Функция получения длины очереди	Да (приблизительное значение)	Да (точное значение для конкретного момента времени)
Функция считывания	Да	Нет

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

Очереди Windows Azure поддерживают произвольные атрибуты, которые можно применять в описании очереди. Каждый атрибут представляет собой пару «имя-значение».
Очереди Windows Azure также позволяют считывать сообщения без их предварительной блокировки. Эта возможность используется при разработке программных инструментов для просмотра очередей.
В API обмена промежуточными сообщениями, реализованном для шины обслуживания с помощью платформы .NET, применяются полнодуплексные соединения TCP, что повышает производительность по сравнению с использованием REST поверх HTTP.
Очереди Windows Azure накладывают определенные ограничения на имена очередей. Дополнительную информацию см. в статье Naming Queues and Metadata (Именование очередей и метаданные).
Длина имени очереди шины обслуживания не может превышать 260 символов; для этих очередей действуют менее строгие правила именования. Имена очередей шины обслуживания могут содержать только буквы, числа, точки (.), тире (—) и символы подчеркивания (_).

Производительность

В этом разделе приведен сравнительный анализ очередей Windows Azure Queues и очередей шины обслуживания с точки зрения производительности.

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Максимальная пропускная способность	До 2000 сообщений в секунду	До 2000 сообщений в секунду (на основании теста производительности с использованием сообщений длиной 1 КБ)
Среднее время задержки	10 мс (с отключенным алгоритмом TCP Nagle)	100 мс
Режим регулирования количества запросов	Отклонение запросов с выдачей кода ошибки HTTP 503 (запросы, получаемые в режиме регулирования количества запросов, не тарифицируются)	Отклонение запросов с выдачей исключения и кода ошибки HTTP 503 (запросы, получаемые в режиме регулирования количества запросов, не тарифицируются)

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

Одна очередь Windows Azure способна обрабатывать до 2000 транзакций в секунду. Транзакция представляет собой одну из следующих операций: Put, Get или Delete. Отправка в очередь отдельного сообщения (Put) считается одной транзакцией, однако получение сообщения часто представляет собой двухэтапный процесс, включающий в себя получение сообщения (Get), за которым следует запрос на удаление из очереди (Delete). Таким образом, успешная операция удаления из очереди обычно состоит из двух транзакций.
Когда приложение достигает максимальной пропускной способности очереди Windows Azure, служба очередей обычно возвращает ответ HTTP 503 Server Busy. В этом случае приложение должно использовать логику повторной отправки с экспоненциальным возрастанием времени задержки.
Задержка в очередях Windows Azure в среднем составляет 10 миллисекунд при обработке сообщений небольшого объема (менее 10 КБ) с использованием размещенной службы, географическое расположение которой (подрегион) совпадает с расположением учетной записи хранилища.
Очереди Windows Azure и очереди шины обслуживания могут использовать режим регулирования количества запросов. В этом случае отвергаются любые запросы к очереди, для которой действует этот режим. При этом запросы, полученные в режиме регулирования количества запросов, не тарифицируются.
Тесты производительности очередей шины обслуживания показали, что одна очередь обеспечивает скорость обработки сообщений до 2000 сообщений в секунду при размере сообщения около 1 КБ. Для обеспечения более высокой скорости обработки необходимо использовать несколько очередей. Дополнительная информация об оптимизации производительности при использовании шины обслуживания содержится в документе Best Practices for Performance Improvements Using Service Bus Brokered Messaging (Рекомендованные способы повышения производительности при использовании шины обслуживания для обмена промежуточными сообщениями).
При превышении максимальной пропускной способности очереди шины обслуживания, клиенту очереди возвращается либо исключение ServerBusyException (при использовании API обмена промежуточными сообщениями .NET), либо ответ HTTP 503 (при использовании API на основе REST). Это указывает на переход очереди в режим регулирования количества запросов.

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

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

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Проверка подлинности	Симметричный ключ	Заявки ACS
Контроль доступа на основе ролей	Нет	Да (с помощью ролей ACS)
Федерация поставщиков удостоверений	Нет	Да

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

Независимо от того, какая технология организации очереди используется, каждый запрос требует проверки подлинности. Анонимный доступ к общедоступным очередям не поддерживается.
Схема проверки подлинности, реализованная в очередях Windows Azure, включает в себя использование симметричного ключа, представляющего собой хеш-код проверки подлинности сообщений (Hash-Based Message Authentication Code, HMAC), вычисляемый с применением алгоритма SHA-256 в кодировке Base64. Более подробная информация о соответствующем протоколе содержится в статье Authenticating Access to Your Storage Account (Проверка подлинности при доступе к учетной записи хранилища).
Служба управления доступом Windows Azure Access Control (ACS), поддерживаемая шиной обслуживания, содержит три отдельные роли: Admin (Администратор), Sender (Отправитель) и Receiver (Получатель), которые в настоящее время не поддерживаются очередями Windows Azure.
Шина обслуживания поддерживает интеграцию ACS, поэтому ее можно объединять с Active Directory (с помощью ADFS) и с часто используемыми поставщиками средств идентификации в Интернете, такими как Live ID, Google, Facebook и Yahoo.

Затраты

В этом разделе приведен сравнительный анализ затрат на использование очередей Windows Azure и очередей шины обслуживания.

Критерий сравнения	Очереди Windows Azure	Очереди шины обслуживания
Стоимость транзакции для очереди	0,01 долл. США (за 10 000 транзакций)	0,01 долл. США (за 10 000 сообщений)
Тарифицируемые операции	Все	Только отправка и получение (за прочие операции плата не взимается)
Транзакции без рабочей нагрузки	Тарифицируются (запрос к пустой очереди считается тарифицируемой транзакцией)	Тарифицируются (получение сообщения из пустой очереди тарифицируется)
Стоимость хранения данных	0,14 долл. США (за ГБ в месяц)	0,00 долл. США
Стоимость исходящих данных	0,12–0,19 долл. США (в зависимости от географического местоположения)	0,12–0,19 долл. США (в зависимости от географического местоположения)
Стоимость транзакций при использовании службы Windows Azure Access Control (ACS)	0,00 долл. США (служба ACS не используется)	1,99 долл. США (за 10 000 запросов маркеров; см. комментарий ниже)

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

Передача данных тарифицируется на основании совокупного объема данных, переданных из центров обработки данных Windows Azure через Интернет в конкретный период тарификации.
Передача данных между серверами Windows Azure, расположенными в одном и том же подрегионе, не тарифицируется.
На момент написания этой статьи плата за входящие данные не взимается.
При операциях обмена сообщениями с очередями шины обслуживания стоимость транзакций ACS можно не принимать в расчет. Шина обслуживания получает один маркер ACS для каждого отдельного экземпляра объекта фабрики обработки сообщений. Этот маркер повторно используется до истечения срока действия, который составляет приблизительно 20 минут. Следовательно, объем операций обмена сообщениями по шине обслуживания не является прямо пропорциональным объему ACS транзакций, необходимых для поддержки этих операций.
Очереди шины обслуживания можно использовать с наименьшими затратами для решения задач, требующих доставки сообщений с малым временем задержки при использовании длинных интервалов опроса.

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

Заключение

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

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

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

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