Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Очереди Azure и очереди шины обслуживания — сходство и отличия

Обновлено: Март 2015 г.

Авторы: Валерий Мизонов, Сет Мангейм (Seth Manheim) и Абишек Лал (Abhishek Lal)

Соавторы: Брэд Колдер (Brad Calder), Джай Харидас (Jai Haridas), Джейсон Хогг (Jason Hogg), Джефф Ирвин (Jeff Irwin), Джаганатан Тангавелу (Jaganathan Thangavelu), Картик Парамасивам (Kartik Paramasivam), Toдд Холмквист-Сазерленд (Todd Holmquist-Sutherland) и Руперт Кох (Ruppert Koch)

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

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

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

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

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

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

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

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

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

  • Для хранения сообщений в очереди приложению требуется более 80 ГБ пространства при времени существования сообщений менее 7 дней.

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

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

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

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

  • В решении требуется, чтобы очередь гарантировала доставку сообщений в порядке их добавления в очередь (FIFO).

  • Требуется симметричная работа Azure и Windows Server (частное облако). Дополнительные сведения см. в разделе Шина обслуживания для Windows Server.

  • В решении необходима поддержка автоматического обнаружения дубликатов.

  • Для приложения требуется обрабатывать сообщения как параллельные долговременные потоки (сообщения связываются с потоком, используя свойство SessionId сообщения). В этой модели каждый узел приложения-приемника конкурирует за потоки, а не за сообщения. Когда поток выделяется для принимающего узла, узел может проверить состояние потока приложения с использованием транзакций.

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

  • Характеристика срока жизни (TTL) рабочей нагрузки конкретного приложения может превышать 7 дней.

  • В приложении обрабатываются сообщения, размер которых может превышать 64 КБ, но вряд ли приблизится к пределу в 256 КБ.

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

  • Размер очереди не превысит 80 ГБ.

  • Вам надо использовать брокер обмена сообщениями, основанный на стандартах AMQP 1.0. Дополнительные сведения AMQP см. в разделе Общие сведения о протоколе AMQP для служебной шины.

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

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

  • Желательна возможность публикации и потребления пакетов сообщений.

  • Требуется полная интеграция с коммуникационным стеком Windows Communication Foundation (WCF) в .NET Framework.

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

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

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Гарантированный метод упорядочивания

Нет

Для получения дополнительной информации см. первое примечание в разделе «Дополнительная информация».

Да, в порядке добавления (FIFO)

(с использованием сеансов обмена сообщениями)

Гарантированный метод доставки

Как минимум один раз

Как минимум один раз

Без повторов

Поддержка транзакций

Нет

Да

(с помощью локальных транзакций)

Поведение при получении

Неблокирующий

(немедленно завершается, если не найдено новых сообщений)

Блокировка со временем ожидания (или без него)

(возможность продолжительного опроса, или метод Comet)

Неблокирующий

(только с помощью управляемого интерфейса API .NET)

Push-API

Нет

Да

OnMessage и сеансы OnMessage в управляемом API (.NET).

Режим получения

Просмотр и аренда

Просмотр и блокировка

Получение и удаление

Режим монопольного доступа

На основе аренды

На основе блокировки

Продолжительность аренды или блокировки

30 секунд (по умолчанию)

7 дней (максимум) (можно продлить или отменить аренду сообщения с помощью API UpdateMessage.)

60 секунд (по умолчанию)

Возобновить блокировку сообщения можно с помощью API-интерфейса RenewLock.

Степень детализации аренды или блокировки

На уровне сообщений

(все сообщения могут иметь различные значения времени ожидания, которые затем можно обновлять по мере необходимости в процессе обработки сообщений с помощью API UpdateMessage)

На уровне очереди

(Для каждой очереди определена степень детализации блокировки, применяемая ко всем сообщениям в очереди, но блокировку можно возобновить с помощью API-интерфейса RenewLock.)

Получение в пакетном режиме

Да

(явно путем указания количества сообщений в процессе их извлечения вплоть до максимального количества в 32 сообщения)

Да

(неявно путем включения свойства предварительной выборки или явно с помощью транзакций)

Отправка в пакетном режиме

Нет

Да

(путем использования транзакций или пакетной обработки на стороне клиента)

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

  • Если вы уже используете хранилище BLOB-объектов или таблицы Azure и начинаете использовать очереди, вам гарантируется 99,9 % доступности. Если вы используете большие двоичные объекты и таблицы с очередями Служебная шина, доступность снизится.

  • Гарантированный шаблон FIFO в очередях Служебная шина требует использования сеансов обмена сообщениями. В случае сбоя приложения во время обработки сообщения, полученного в режиме Peek & Lock, в следующем сеансе обмена сообщениями получатель очереди начнет работу с сообщения, на котором произошел сбой, после истечения его срока жизни (TTL).

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

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

  • Очереди Azure предоставляют единообразную и согласованную модель программирования для очередей, таблиц и BLOB-объектов как для разработчиков, так и для специалистов по эксплуатации.

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

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

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

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

  • Максимальное время ожидания для операции блокирующего получения в очередях Служебная шина составляет 24 дня. Однако максимальное время ожидания для очередей на основе REST равно 55 секундам.

  • Пакетная обработка на стороне клиента, предоставляемая Служебная шина, позволяет клиенту очереди отправлять несколько сообщений одним пакетом (в рамках одной операции отправки). Пакетная обработка может использоваться только для операций асинхронной отправки.

  • Такие факторы, как верхнее ограничение в 200 ТБ для очередей Azure (или больше при виртуализации учетных записей) и очереди без ограничений, делают их идеальной платформой для поставщиков SaaS.

  • Очереди Azure обеспечивают гибкий и эффективный механизм управления делегированным доступом.

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

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Плановая доставка

Да

Да

Автоматическое перемещение в «мертвую» очередь

Нет

Да

Увеличение значения срока жизни очереди

Да

(путем обновления на месте времени ожидания видимости)

Да

(предоставляется выделенной функцией API)

Поддержка сообщений о сбое

Да

Да

Обновление на месте

Да

Да

Журнал транзакций на стороне сервера

Да

Нет

Метрики хранения

Да

Точные метрики: в режиме реального времени отслеживается доступность, TPS, количество вызовов API, количество ошибок, и многое другое (объединение идет поминутно и доступно через несколько минут после событий в рабочей среде). Дополнительные сведения см. в разделе Сведения о метриках аналитики хранилища.

Да

(массовые запросы путем вызова GetQueues)

Управление данными о состоянии

Нет

Да

Microsoft.ServiceBus.Messaging.EntityStatus.Active, Microsoft.ServiceBus.Messaging.EntityStatus.Disabled, Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled, Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled

Автоматическая пересылка сообщений

Нет

Да

Функция очистки очереди

Да

Нет

Группы сообщений

Нет

Да

(с использованием сеансов обмена сообщениями)

Состояние приложений по группам сообщений

Нет

Да

Обнаружение дубликатов

Нет

Да

(настраивается на стороне отправителя)

Интеграция с WCF

Нет

Да

(содержит заранее реализованные функции привязки к WCF)

Интеграция с WF

Особые настройки

(требует построения специального действия WF)

Собственный

(содержит реализованные действия WF)

Просмотр групп сообщений

Нет

Да

Выдача сеансов сообщений по идентификатору

Нет

Да

  • Обе технологии очередей позволяют запланировать доставку сообщения в более позднее время.

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

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

  • Перемещение сообщений в «мертвую» очередь, поддерживаемое только очередями Служебная шина, может быть полезным для изоляции сообщений, которые не могут быть успешно обработаны приложением-получателем, или в том случае, когда сообщения не могут достичь цели из-за истечения срока жизни (TTL). Значение TTL задает время, в течение которого сообщение остается в очереди. В случае с Служебная шина после истечения срока TTL сообщение будет перемещено в специальную очередь $DeadLetterQueue.

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

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

  • Понятие «сеансы сообщений», поддерживаемое очередями Служебная шина, позволяет сообщениям в составе определенной логической группы ассоциироваться с заданным получателем, что в свою очередь порождает сходство (как в сеансах) сообщений с соответствующими им получателями. Эти расширенные функции можно включить в Служебная шина путем задания свойс��ва SessionID для сообщения. Получатели затем могут прослушивать на сеансе с определенным идентификатором и получать сообщения, у которых идентификатор сеанса равен этому заданному идентификатору.

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

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

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Максимальный размер очереди

200 ТБ

(в рамках емкости одной учетной записи хранения)

от 1 до 80 ГБ

(определяется при создании очереди и включении секционирования)

Максимальный размер сообщения

64 КБ

(48 КБ при использовании кодирования Base64)

Azure поддерживает большие сообщения, комбинируя очереди и большие двоичные объекты, благодаря которым можно поставить в очередь до 200 ГБ на один элемент.

256 КБ

(включая заголовок и текст, максимальный размер заголовка: 64 КБ)

Максимальный срок жизни (TTL) сообщения

7 дней

Неограниченно

Максимальное количество очередей

Неограниченно

10,000

(для каждого пространства имен службы, может быть увеличено)

Максимальное количество параллельных клиентов

Неограниченно

Неограниченно

(ограничение в 100 параллельных соединений применяется только к взаимодействию по протоколу TCP)

  • При использовании очередей Azure содержимое сообщений, не являющееся безопасным с точки зрения XML, должно кодироваться методом Base64. При кодировании сообщения методом Base64 полезная нагрузка пользовательским содержимым может достигать 48 KБ (вместо 64 КБ).

  • При использовании очередей Служебная шина каждое сообщение, сохраненное в очереди, состоит из двух частей: заголовка и текста. Общий размер сообщения не может превышать 256 КБ.

  • Когда клиенты взаимодействуют с очередями Служебная шина по протоколу TCP, максимальное количество одновременных подключений к отдельной очереди Служебная шина ограничено 100. Это значение распределяется между отправителями и получателями. После достижения этой квоты последующие запросы на дополнительные соединения будут отклонены, вызывающий код получит исключение. Это ограничение не применяется к клиентам, соединяющимся с очередями с помощью интерфейса API на основе REST.

  • Служебная шина применяет ограничения размера очереди. Максимальный размер очереди указывается при создании очереди и может иметь значение между 1 и 80 ГБ. При достижении значения размера очереди, заданного при создании очереди, последующие входящие сообщения будут отклонены, вызывающий код получит исключение. Дополнительные сведения квоты в Служебная шина см. раздел Квоты Service Bus.

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

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

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Протокол управления

REST по протоколу HTTP/HTTPS

REST по протоколу HTTPS

Протокол выполнения

REST по протоколу HTTP/HTTPS

REST по протоколу HTTPS

AMQP 1.0 Standard (TCP с TLS)

управляемый интерфейс API .NET

Да

(управляемый интерфейс API .NET для клиента хранения)

Да

(управляемый интерфейс API .NET для посреднического обмена сообщениями)

Машинный C ++

Да

Нет

API-интерфейс Java

Да

Да

API-интерфейс PHP

Да

Да

Интерфейс API Node.js

Да

Да

Поддержка произвольных метаданных

Да

Нет

Правила именования очередей

До 63 символов

(буквы в имени очереди должны быть строчными)

До 260 символов

(в именах очередей регистр не учитывается)

Функция получения длины очереди

Да

(приблизительное значение, если сообщение не удаляется после истечения срока жизни)

Да

(точное значение в определенный момент времени)

Функция просмотра

Да

Да

  • Очереди Azure поддерживают произвольные атрибуты, которые могут применяться к описанию очереди, в формате пар «имя/значение».

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

  • В управляемом API Служебная шина .NET для брокерного обмена сообщениями используются полнодуплексные TCP-соединения, чтобы повысить производительность по сравнению с REST через HTTP, к тому же они поддерживают стандарт AMQP 1.0.

  • Имена очередей Azure могут содержать от 3 до 63 символов, которыми могут быть буквы нижнего регистра, цифры и знаки дефиса. Дополнительные сведения см. в разделе Именование очередей и метаданных.

  • Имя очереди Служебная шина может содержать до 260 символов, при этом действуют менее жесткие правила именования. Имя очереди Служебная шина может содержать буквы, цифры, точки (.), дефисы (-) и символы подчеркивания (_).

В данном разделе очереди Azure и очереди Служебная шина сравниваются с точки зрения производительности.

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Максимальная пропускная способность

До 2000 сообщений в секунду

(на основе теста производительности с сообщениями 1 КБ)

До 2000 сообщений в секунду

(на основе теста производительности с сообщениями 1 КБ)

Среднее время задержки

10 мс

(при отключенном TCP Nagle)

20-25 мс

Поведение при регулировании

Отклонить с кодом HTTP 503

(регулируемые запросы не считаются оплачиваемыми)

Отклонить с исключением/HTTP 503

(регулируемые запросы не считаются оплачиваемыми)

  • Одна очередь Azure может обрабатывать до 2000 транзакций в секунду. Под транзакцией подразумевается операция Put, Get или Delete. Отправка одного сообщения в очередь (Put) считается как одна транзакция, однако получение сообщения часто происходит в два этапа, включая извлечение (Get) и последующий запрос на удаление сообщения из очереди (Delete). Как следствие, успешная операция выведения из очереди включает в себя две транзакции. Извлечение нескольких сообщений в пакете можно уменьшить эффект от этого, так как можно использовать Get для 32 сообщений в одной транзакции, после которой идет вызов Delete для каждого из них. Для повышения производительности вы можете создать несколько очередей (учетная запись хранения может иметь неограниченное число очередей).

  • При достижении приложением максимальной пропускной способности для очереди Azure служба очередей обычно возвращает «HTTP 503, сервер занят». В этом случае приложение должно вызывать логику повторных попыток с экспоненциальным увеличением отсрочки.

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

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

  • Тесты производительности очередей Служебная шина показ��ли, что с помощью одной очереди можно достичь пропускной способности до 2000 сообщений в секунду при размере сообщений около 1 КБ. Для достижения более высокой пропускной способности используйте несколько очередей. Дополнительные сведения об оптимизации производительности с помощью Служебная шина см. в разделе Советы и рекомендации по повышению производительности с помощью обмена сообщениями через посредника служебной шины.

  • При достижении максимальной пропускной способности для очереди Служебная шина клиенту очереди возвращается ответ ServerBusyException (при использовании управляемого интерфейса API .NET для посреднического обмена сообщениями) или HTTP 503 (при использовании интерфейса API на основе REST), что означает, что очередь регулируется.

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

 

Критерии сравнения Очереди Azure Очереди Служебная шина

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

Симметричный ключ

Симметричный ключ

Модель управления доступом

Делегирование доступа через токены SAS

RBAC через Служба управления доступом

Федерация поставщика удостоверений

Нет

Да

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

  • Схема проверки подлинности в очередях Azure основана на применении симметричного ключа, который представляет собой хэш-код проверки подлинности сообщения (HMAC), вычисляемый по алгоритму SHA-256 и кодируемый как строка Base64. Дополнительные сведения соответствующем протоколе см. в статье Проверка подлинности при доступе к учетной записи хранилища. Очереди Служебная шина поддерживают аналогичную модель с использованием симметричных ключей. Дополнительные сведения см. в разделе Проверка подлинности подписанного URL-адреса с помощью служебной шины.

  • Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS), поддерживаемая Служебная шина, предлагает три различные роли: Admin, Sender и Receiver, которые в настоящее время не поддерживаются для очередей Azure.

  • Так как в Служебная шина предоставляется интеграция с Служба управления доступом, это дает возможность создания федерации с Active Directory (посредством ADFS) и с распространенными поставщиками веб-удостоверений, в том числе Live ID, Google, Facebook и Yahoo.

В данном разделе очереди Azure и очереди Служебная шина сравниваются с точки зрения стоимости.

 

Критерии сравнения Очереди Azure Очереди Служебная шина

Стоимость транзакции с очередью

$0.0005

(за 10 000 транзакций)

Базовый уровень: $0.05

(за миллион операций)

Оплачиваемые операции

Все

Только отправление или получение

(остальные операции бесплатно)

Транзакции в состоянии простоя

Подлежит оплате

(запрос к пустой очереди считается оплачиваемой операцией)

Подлежит оплате

(операция получения, применяемая к пустой очереди, рассматривается как оплачиваемое сообщение)

Стоимость хранения

$0.07

(за ГБ/месяц)

$0.00

Стоимость передачи исходящих данных

$0.12 - $0.19

(в зависимости от географического расположения)

$0.12 - $0.19

(в зависимости от географического расположения)

  • Оплата передачи основывается на общем объеме данных, исходящих из центров обработки данных Azure через Интернет в течение заданного расчетного периода.

  • За передачу данных между службами Azure, расположенными в пределах одного и того же региона, плата не взимается.

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

  • Стоимость транзакций Служба управления доступом не важна при выполнении операций с сообщениями в очередях Служебная шина. Служебная шина получает один токен Служба управления доступом на один экземпляр объекта фабрики обмена сообщениями. Затем токен используется до истечения срока его действия (около 20 минут). Следовательно, объем операций обмена сообщениями в Служебная шина не является прямо пропорциональным количеству транзакций Служба управления доступом, необходимых для поддержки этих операций.

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

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

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

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

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

См. также

Показ:
© 2015 Microsoft