Доступ к сервисам предприятия с Windows Azure Service Bus

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

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

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

увеличить изображение
Рис. 11.1. Пример связанности

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

увеличить изображение
Рис. 11.2. Пример распределенной архитектуры

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

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

Первым компонентов Windows Azure Service Bus является рилей –маршрутизатор, который позволяет реализовать сценарий "прохода" запросов через NAT/брандмауэр и вынести сервис наружу. Это типичный сценарий, в котором за брандмауэром в корпоративном центре обработки данных находится сервис, который нужно вынести наружу без нарушений регламентов безопасности. C помощью рилея этот сценарий решается наиболее безопасным образом.

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

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

Рис. 11.3. Топики и подписки

Более сложным сценарием использования топиков и подписок является маршрутизатор на базе контента, когда нужно направить сообщение не всем подряд, а передать ее конкретным клиентам. Для этого существуют фильтры, на основании которых сообщения фильтруются и направляются в соответствующие очереди. Фильтры могут иметь один из трех типов: True/NotTrue (когда выполняется или не выполняется заданное условие), SQL-фильтр (когда фильтр задается в SQL-синтаксисе) и фильтр CorrelationId (когда фильтр отрабатывает, учитывая идентификатор корреляции каждого сообщения).

Рис. 11.4. Машрутизатор на базе контента

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

увеличить изображение
Рис. 11.5. Сервисы Windows Azure Service Bus