Была ли эта страница полезной?
Ваш отзыв об этом контенте важен для нас. Расскажите нам о том, что вы думаете.
Дополнительный отзыв?
1500 символов осталось
Экспорт (0) Печать
Развернуть все
Развернуть Свернуть

Создание приложений, использующих темы и подписки служебной шины

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

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

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

Шина-обслуживания1

Чтобы развить этот сценарий, к системе было добавлено новое требование: владелец магазина хочет отслеживать, как работает хранилище, в режиме реального времени.

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

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

Сообщения отправляются в раздел так же, как и в очередь. При этом сообщения принимаются из разделов не напрямую; они принимаются из подписок. Подписку на раздел можно воспринимать как виртуальную очередь, получающую копии сообщений, отправленных в этот раздел. Из подписки сообщения принимаются так же, как и из очереди.

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

Шина-обслуживания2

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

Для поддержки панели управления следует создать вторую подписку на раздел, как показано здесь:

Шина-обслуживания3

С данной конфигурацией каждое сообщение от терминалов становится доступным для подписок Dashboard и Inventory.

В разделе Создание приложений, использующих очереди служебной шины описывается регистрация учетной записи Служебная шина и создание пространство имен службы. Для использования Служебная шина пространство имен службы приложение должно ссылаться на сборку Служебная шина, а именно на Microsoft.ServiceBus.dll. Самый простой способ указать ссылку на зависимости Служебная шина — установить пакет Nuget для Служебная шина. Сборку можно также найти в пакете SDK Azure в клиентских библиотеках Azure для .NET. Скачать пакет можно на странице загрузки пакета SDK для Azure.

Операции управления для Служебная шина сущностей обмена сообщениями (очереди и разделы публикации/подписки) выполняются при помощи класса NamespaceManager. Служебная шина использует модель безопасности на основе утверждений, которая использует Microsoft Azure Active Directory Access Control (также называется Access Control Service или ACS). Требуются соответствующие учетные данные для того, чтобы создать экземпляр NamespaceManager для конкретного пространство имен службы. Класс TokenProvider представляет собой поставщика токенов безопасности со встроенными методами-фабрики, которые возвращают некоторые хорошо известные поставщики токенов. Мы будем использовать метод CreateSharedAccessSignatureTokenProvider для хранения учетных данных SAS. Экземпляр NamespaceManager конструируется с базовым адресом Служебная шина пространство имен службы и поставщиком токенов.

Класс NamespaceManager предоставляет методы создания, перечисления и удаления сущностей обмена сообщениями. Отрезок, показанный здесь, иллюстрирует, что экземпляр NamespaceManager создан и использован для создания раздела DataCollectionTopic.

Uri uri = ServiceBusEnvironment.CreateServiceUri("sb", "ingham-blog", string.Empty);
    string name = "RootManageSharedAccessKey";
    string key = "abcdefghijklmopqrstuvwxyz";
     
    TokenProvider tokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(name, key);
    NamespaceManager namespaceManager = new NamespaceManager(uri, tokenProvider);
 
    namespaceManager.CreateTopic("DataCollectionTopic");

Обратите внимание, что существуют перегрузки метода CreateTopic, которые можно использовать для настройки свойств раздела. Например, можно установить значение срока жизни по умолчанию (TTL) для сообщений, отправленных в раздел. Далее добавьте подписки Inventory и Dashboard.

namespaceManager.CreateSubscription("DataCollectionTopic", "Inventory");
    namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard");

Для операций времени выполнения в Служебная шина сущностях; например, для отправки и получения сообщений приложение во-первых должно создать объект MessagingFactory. Схожий с NamespaceManager класс, экземпляр MessagingFactory instance создан из базы адресов пространство имен службы и поставщика токенов.

MessagingFactory factory = MessagingFactory.Create(uri, tokenProvider);

Сообщения, отправляемые и получаемые в очередях Служебная шина, являются экземплярами класса BrokeredMessage. Данный класс состоит из набора стандартных свойств (например Label иTimeToLive), словаря, который используется для хранения свойств приложения, и набора произвольных данных приложения. Приложение может настроить тело путем прохода в любой сериализуемый объект (следующий пример проходит в объект SalesData, который представляет данные о продажах из POS терминала), который будет использовать сериализуемый объект DataContractSerializer. Альтернативно может быть предоставлено Stream.

BrokeredMessage bm = new BrokeredMessage(salesData);
    bm.Label = "SalesReport";
    bm.Properties["StoreName"] = "Redmond";
    bm.Properties["MachineID"] = "POS_1";

Самый простой способ отправки сообщений в раздел заключается в том, чтобы использовать CreateMessageSender для создания объекта MessageSender непосредственно из экземпляра MessagingFactory.

MessageSender sender = factory.CreateMessageSender("DataCollectionQueue");
    sender.Send(bm);

Аналогично случаю с очередями, наиболее простой способ получения сообщений из очереди — использовать объект MessageReceiver, который можно создать напрямую из MessagingFactory, используя CreateMessageReceiver. Можно использовать один из двух различных режимов приема (ReceiveAndDelete и PeekLock), как описано в разделе Создание приложений, использующих очереди служебной шины.

Обратите внимание, что при создании MessageReceiver для подписок параметр entityPath имеет форму topicPath/subscriptions/subscriptionName. Следовательно, для создания MessageReceiver для подписки Inventory в разделе DataCollectionTopicentityPath должен равняться DataCollectionTopic/subscriptions/Inventory. Код будет выглядеть следующим образом:

MessageReceiver receiver = factory.CreateMessageReceiver("DataCollectionTopic/subscriptions/Inventory");
    BrokeredMessage receivedMessage = receiver.Receive();
    try
    {
        ProcessMessage(receivedMessage);
        receivedMessage.Complete();
    }
    catch (Exception e)
    {
        receivedMessage.Abandon();
    }

Пока что в этой статье все сообщения, отправленные в раздел, были доступны всем зарегистрированным подпискам. Ключевая фраза — "были доступны". Хотя подписки Служебная шина видят все сообщения, отправленные в раздел, можно копировать только часть этих сообщений в виртуальную очередь подписки. Это делается с помощью фильтров подписок. При создании подписки можно предоставить выражение фильтра в форме предиката SQL92, которое будет работать со свойствами сообщения (как системными, например Label, так и свойствами приложения, например StoreName в предыдущем примере).

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

Шина-обслуживания4

Чтобы настроить эту маршрутизацию, подписку Dashboard нужно создать так:

SqlFilter dashboardFilter = new SqlFilter("StoreName = ‘Redmond’");
  namespaceManager.CreateSubscription("DataCollectionTopic", "Dashboard", dashboardFilter);

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

В этой статье показано, как использовать публикацию и подписку на основе разделов в Служебная шина.

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

  • Временная развязка — производители и потребители сообщений не обязаны быть подключены к сети одновременно.

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

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

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

Показ:
© 2015 Microsoft