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

Часто задаваемые вопросы по ценообразованию шин обслуживания

Обновлено: Октябрь 2014 г.

Информацию о структуре ценообразования Шина службы Microsoft Azure можно найти в Часто задаваемых вопросах в следующем разделе. Также можно посетить Часто задаваемые вопросы о ценообразовании Azure Platform для общей Microsoft Azure информации о ценах. Дополнительные сведения о расценках на Служебная шина см. в разделе Сведения о ценах для служебной шины.

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

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

Любая передача данных в рамках рассматриваемого Azure региона осуществляется бесплатно. За любую передачу данных вне региона назначается цена за выход, которая составляет 0,15 $ за ГБ из Североамериканского и Европейского регионов, и 0,20 $ за ГБ из Азиатско-Тихоокеанского региона. Любая входящая передача данных осуществляется бесплатно.

Ретрансляция является Служебная шина сущностью, ретранслирующей сообщения между клиентами и сетевыми службами. Ретрансляция обеспечивает службу сохраняемыми, обнаруживаемыми Служебная шина адресами, надежным соединением с брандмауэром/возможностями прохождения NAT и дополнительными функциями, такими как автоматическая балансировка нагрузки. Ретрансляция является неявно создаваемым экземпляром и открывается под заданным Служебная шина адресом (URL-адрес пространство имен), когда служба WCF с включенной ретрансляцией или "слушатель ретрансляции" подключаются к этому адресу. Приложения создают слушателей ретрансляций посредством Служебная шина API, управляемых .NET, что обеспечивает особые версии стандартных WCF привязок, где включена ретрансляция.

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

В некоторых случаях к единичной ретрансляции в Служебная шина может подключаться несколько слушателей. Это может происходить со службами со сбалансированной нагрузкой, использующими netTCPRelay или *HttpRelay WCF привязки, или слушателями широковещательных событий, использующими netEventRelay WCF привязки. Ретрансляция Служебная шина считается "открытой" при наличии по крайней мере одного подключенного к ней слушателя ретрансляции. Добавление дополнительного слушателя к открытой ретрансляции не изменяет состояние данной ретрансляции в целях составления счетов. Количество отправителей ретрансляции (клиенты, вызывающие или отправляющие сообщения ретрансляциям), подключенных к ретрансляции также не оказывает влияния на подсчет часов ретрансляции.

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

  1. Отправление сообщения к Служебная шина ретрансляции считается "проводимой полностью" отправкой слушателю, который получает сообщение, а не отправкой к Служебная шина ретрансляции с последующей доставкой слушателю ретрансляции. Следовательно, вызов службы типа запрос-ответ (размером до 64 КБ) на уровне слушателя ретрансляции приведет к двум оплачиваемым сообщениям: одно оплачиваемое сообщение для запроса и одно оплачиваемое сообщение для ответа (при ответе размером также <= 64 КБ). Это отличается от использования очереди для посредничества между клиентом и службой. В последнем случае соответствующая схема запрос-ответ требует отправку запроса к очереди с последующим удалением из очереди/доставкой от очереди службе, с последующей отправкой ответа другой очереди и удалением из очереди/доставкой от этой очереди клиенту. При таком же размере (<= 64 КБ) полное проведение схемы посредничества очереди отразится в четырех оплачиваемых сообщениях, что в два раза превышает плату за такую же схему при использовании ретрансляции. Конечно существуют преимущества в использовании очередей для достижения этой схемы, такие как срок службы и выравнивание нагрузки. Эти преимущества могут оправдать дополнительные расходы.

  2. Ретрансляции, открытые посредством привязки NetTCPRelay WCF, рассматривают сообщения не как индивидуальные, а как поток данных через систему. Другими словами, только отправитель и слушатель имеют видимость в кадрировании индивидуальных сообщений отправленных/полученных посредством этой привязки. Таким образом, для ретрансляций, использующих netTCPRelay привязки, все данные рассматриваются как поток в целях вычисления оплачиваемых сообщений. В данном случае Служебная шина вычислит общую сумму данных, отправленных или полученных посредством индивидуальных ретрансляций за 5-минутный период, и разделит эту сумму на 64 КБ с целью определения количества оплачиваемых сообщений для рассматриваемой ретрансляции на протяжении данного периода времени.

Нет, Служебная шина не назначает плату за хранение. Тем не менее, существует квота, ограничивающая максимальный объем данных, который может храниться в базе данных для каждой очереди/темы. См. Есть ли у служебной шины квоты использования? раздел ниже.

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

  • 5 триллионов сообщений

  • 2 миллиона часов ретрансляции

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

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

  • Размер очереди/раздела — вы указываете максимальный размер очереди или раздела при создании. У данной квоты есть значения 1, 2, 3, 4, или 5 ГБ. При достижении максимального размера, последующие входящие сообщения будут отклонены, вызывающий код получит исключение.

  • Количество параллельных соединений

    • Очередь/раздел/подписка — количество параллельных соединений TCP в очереди/разделе/подписке ограничено до 100. После достижения этой квоты последующие запросы на дополнительные соединения будут отклонены, вызывающий код получит исключение. Для каждой фабрики сообщений Служебная шина поддерживает одно соединение TCP, если какой-либо клиент, созданный такой фабрикой сообщений, имеет ожидающую активную операцию либо завершил операцию менее 60 секунд назад. Операции REST не считаются параллельными TCP-подключениями.

  • Количество параллельных слушателей на ретрансляции — количество параллельных слушателей NetTcpRelay и NetHttpRelay на ретрансляции ограничено 25 (1 на ретрансляцию NetOneway).

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

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

  • Квоты размера сообщения

    • Очередь/Тема/Подписка

      • Размер сообщения — каждое сообщение ограничено суммарным размером 256 КБ, включая заголовки сообщения.

      • Размер заголовка сообщения — каждый заголовок сообщения ограничен размером 64 КБ.

    • Ретрансляции NetOneway и NetEvent — каждое сообщение ограничено суммарным размером 64 КБ, включая заголовки сообщения.

    • Ретрансляции Http и NetTcp — Служебная шина не применяет верхний предел для размера данных сообщений.

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

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

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

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

Для дополнительных сведений о квотах см. Квоты Service Bus.

Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2015 Microsoft