Разработка приложений с Windows Azure Cloud Services

Windows Azure Cloud Services

Базовым сервисом платформы Windows Azure является Cloud Services (ранее Hosted Services). В таблицу 5.1 сведены данные о том, каким образом реализует ту или иную функцию или сценарий Cloud Services и Web Sites.

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

увеличить изображение
Рис. 5.1. Стандартная модель MVC

Для того, чтобы понять принцип работы ролевой модели, можно взять в качестве примера типичное Web-приложение, написанное с использованием паттерна разработки MVC (Model-View-Controller). Типичное Web-приложение состоит из представления (Web-интерфейса пользователя), контроллера (слоя бизнес-логики, служащего также прослойкой между представлением и слоем доступа к источнику данных) и слоем доступа к источнику данных. Архитектура большинства Web-приложений на высоком уровне может быть сведена именно к такому разделению. Конечный же пользователь имеет доступ к приложению по конечной точке доступа (ссылке) по HTTP либо HTTPS.

Рис. 5.2. Архитектура Cloud Service

В контексте ролевой модели будет выглядеть следующим образом – представление меняет свое название на Web-роль, контроллер – на Worker-роль, слой доступа к источнику данных же может быть реализован внутри отдельной Worker-роли. Для получения данных от представления (Web-роли) обработчиком-контроллером (Worker-ролью) традиционно используется Middleware в виде сервиса очередей. При этом сервисом Middleware может выступать как Windows Azure Storage Queue, так и Windows Azure Service Bus (о которых будет рассказано в соответствующих главах курса). Использование Middleware приводит к одной из best practice разработки отказоустойчивых распределенных приложений – вместо разработки тесносвязанной системы (в которой потеря одного из компонентов, например, Web-роли, будет означать неработоспособность всей системы и потерю данных) разработчик может использовать Middleware в режиме брокера (Brokered Messaging) – Web-роль не знает о том, сколько обработчиков обрабатывает приходящие с нее сообщения, есть ли эти обработчики, находятся ли они оффлайн или онлайн, и, если такого не предусмотрено, не знает о статусе обработки этих сообщений, кладя при этом сообщения в сервис Middleware (очередь), где они хранятся до тех пор, пока не собираются сборщиком мусора либо не обрабатываются экземплярами Worker-роли. При этом связность системы значительно ослабляется – выход из строя части системы с большей степенью вероятности не приведет к сбою всей системы.

Как уже было сказано, для каждой из ролей существует определенное количество экземпляров, выполняющих аналогичную копию роли. Это значит, что пользователь, войдя по ссылке на Web-сайт, может попасть как на первый экземпляр Web-роли, так и на второй, или на любой, находящийся в ротации балансировщика нагрузки. Это накладывает серьезные ограничения на некоторые привычные практики разработки – например, необходимо учитывать, что балансировщик нагрузки Windows Azure не является "липким", то есть нет гарантии, что пользователь, зайдя на сайт с утра и попав на экземпляр Web-роли №1, вечером попадет на тот же самый экземпляр. Учитывать это необходимо тогда, когда разработчиком реализуется механизм хранения пользовательских данных, например, сессии. В том случае, если данные сессии сохраняются локально на экземпляре Web-роли, с увеличением количества экземпляров будет увеличиваться степень вероятности того, что пользователь не увидит своих данных при следующем входе. В таких случаях рекомендуется использовать внешнее хранилище.

Примечание

Основные характеристики типов ролей:

• Web-роль. Web-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых установлен IIS 7/7.5 и по умолчанию открыты несколько стандартных портов доступа по HTTP. Безопасность Web-роли может быть обеспечена сертификатом, привязанным к любой точке входа HTTPS.
• Worker-роль. Worker-роль содержит набор экземпляров-серверов с виртуальными машинами, на которых выполняется (обычно – в бесконечном цикле) определенная бизнес-логика, часто получающая данные для своей работы из Web-роли. По умолчанию входящие подключения в виртуальную машину, установленную на экземпляре Worker-роли, запрещены. Можно провести аналогию с Windows-сервисом (обычно проекты Worker-ролей используют аналогичную Windows-сервису программную модель) – наследуясь от RoleEntryPoint, класс , выполняющий бизнес-логику Worker-роли, использует три метода – OnStart() (вызывается при запуске роли, возвращает статус Busy балансировщику нагрузки до тех пор, пока не указано иное), Run() (выполняется постоянно, содержит основную логику) и OnStop() (выполняется при отключении роли, 30 секунд, может быть использован для закрытия подключений, удаления объектов и так далее). Подробнее про жизненный цикл Worker-роли – в приложении 1.

Рис. 5.3. Роли в Cloud Service