Базовые технологии, использованные для реализации Microsoft Windows Azure

4.9. Архитектура Windows Azure и реализация облачных Web-сервисов

Перейдем теперь собственно к предмету рассмотрения – архитектуре Azure и реализации облачных Web-сервисов средствами .NET.

Архитектура Azure представлена на рис. 4.5.

Рис. 4.5. Архитектура Windows Azure

Fabric - это сеть взаимосвязанных узлов: Commodity –серверы, высокоскоростные роутеры, переключатели, волоконно-оптические коннекторы.

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

Главные сервисы Windows Azure следующие:

- Compute: Хостинг масштабируемых сервисов на платформе Windows Server 2008.

- Storage: управление данными (не реляционными).

- Network: Ресурсы для взаимодействия со внешними приложениями (Service Bus).

Функции Fabric Controller:

- Fault Domains: Единица обработки ошибок в ЦОД (например, кластер машин).

- Update Domains: модификация областей при апгрейдах (ОС, сервисы).

Владельцы приложений описывают требуемые ресурсы в виде дескрипторов ресурсов (моделей сервисов).

Fabric Controller автоматически предоставляет требуемые ресурсы.

Fabric Controller обеспечивает устойчивость ресурсов к ошибкам и быстрый доступ к ним, раннее обнаружение ошибок в приложениях, создание дополнительных экземпляров по требованию. Экземпляры размещаются поверх fault и update domains.

В Azure различаются роли Web и Worker (см. рис. 4.6). По существу, каждая роль в Azure – это определенная разновидность приложения.

Рис. 4.6. Роли Web и Worker

Web-роль – это интерактивное .NET – приложение, обслуживаемое IIS, - Web Application или Web Service Windows Communication Foundation (WCF).

Worker-роль – это независимый изолированный фоновый процесс. Предоставляются способы доступа к нему со стороны внешних приложений.

Fabric Agent сохраняет метрики ресурсов, такие, как использования и ошибки.

Модель сервисов: Определение сервисов. Файл ServiceDefiniton.csdef определяет общую структуру сервиса:

• vmsize: ядра CPU (1 – 8) и память для виртуальной машины VM (1.7 – 15 GB)
• full/partial trust: поддерживается исполнение native-кода
• Endpoint: внутренние и внешние точки взаимодействия (http, https, tcp)
• LocalStorage: временная память на сервере, на котором исполняется объект
• ConfigurationSettings: имена параметров конфигурации

Файл определения сервиса обрабатывается во время развертывания приложения.

Структура файла определения сервисов изображена на рис. 4.7.

Рис. 4.7. Структура файла ServiceDefiniton.csdef

Модель сервисов: Конфигурация сервисов. Файл ServiceConfiguration.csdef задает конфигурацию сервисов. В нем указывается число экземпляров каждой роли и определяются значения для установок конфигурации.

Содержимое файла ServiceConfiguration может быть изменено во время выполнения.

Структура файла конфигурации сервисов изображена на рис. 4.8.

Рис. 4.8. Структура файла ServiceConfiguration.csdef

Диаграмма классов Windows Azure Role API изображена на рис. 4.9.

Рис. 4.9. Диаграмма классов Windows Azure Role API

Класс BasicEntryPoint (с потомками MyWebRole и MyWorkerRole) содержит методы жизненного цикла - onStart(), onStop(), run().

Класс RoleEnvironment имеет потомков Role и RoleInstance.

Реализация ролей изображена на рис. 4.10.

Рис. 4.10. Реализация ролей

В реализации роли определяется класс-потомок RoleEntryPoint и перегружаются методы жизненного цикла. Обычно перегружается метод OnStart(). Регистрируется обработчик, который прослушивает изменения в конфигурации учетной записи облачной памяти. Когда обнаруживается изменение, роль повторно стартуется (переиспользуется).

Реализация ролей Web и Worker изображена на рис. 4.11.

Рис. 4.11. Реализация ролей Web и Worker

При реализации Web Role нет никаких отличий от стандартов ASP.NET Web Forms, ASP.NET MVC или WCF-приложений.

При реализации Worker Role переопределяется метод Run() класса RoleEntryPoint. Этот метод служит в качестве главного потока исполнения для этой роли.

Альтернатива: можно прослушивать внешние HTTP(S) - или TCP- коммуникационные точки для входящих сообщений.

Взаимодействие между ролями изображено на рис. 4.12.

Рис. 4.12. Взаимодействие между ролями

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

Это предпочтительный метод для надежного обмена сообщениями.

Экземпляры ролей могут также взаимодействовать непосредственно с помощью TCP- или HTTP(S) - соединений.

Взаимодействие между ролями на основе WCF/TCP изображено на рисунках 4.13, 4.14, 4.15.

Рис. 4.13. Взаимодействие между ролями на основе WCF/TCP: сервис

Рис. 4.14. Взаимодействие между ролями на основе WCF/TCP: хостинг

Рис. 4.15. Взаимодействие между ролями на основе WCF/TCP: клиент

В примере реализуется сервис xxx. С помощью атрибутов определяется контракт сервиса. Для конфигурирования worker-роли добавляются внешние или внутренние коммуникационные точки. Реализуется хостинг WCF-сервиса. При реализации клиента, при использовании внутренних коммуникационных точек отправитель должен выполнять балансировку загрузки вручную. Необходимо использовать RoleEnvironment.Roles["TargetRole"] для поиска этих коммуникационных точек.