Практикум по учебной дисциплине (стр. 4 )

Рис. 1. Стандартная модель MVC

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

Рис. 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 секунд, может быть использован для закрытия подключений, удаления объектов и так далее).

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

Ход практической работы.

Конфигурация Cloud Service

В данном случае под Cloud Services мы понимаем проект (набор файлов), который описывает облачный сервис, данный проект может использоваться средой разработки Visual Studio. Конфигурация состоит из двух XML-файлов:

Файл определения сервиса (Service Definition file, файл с расширением. csdef), содержащий описание ролей, точек входа в них (порты с указанными протоколами, открытые клиенту) и настройки конфигурации без заданных значений (например, строки подключения). Файл конфигурации сервиса (Service Configuration file, файл с расширением. cscfg), содержащий непосредственные значения для различных настроек, например, количество экземпляров-серверов, которые будут обслуживать конкретную роль, или значения для описанных в файле определения сервиса настроек конфигурации.

В файлах конфигурации Windows Azure также есть возможность задать два параметра, указывающих версию операционной системы, которая будет обслуживать развернутый сервис. Первый параметр – "семейство" операционной системы, атрибут osFamily в файле конфигурации сервиса. Может иметь следующие значения: 1 (Windows 2008), 2 (Windows 2008 R2), 3 (Windows 2012). Второй параметр – "версия" операционной системы, атрибут osVersion в файле конфигурации, имеющий вид типа WA-GUEST-OS-2.15_201305-01. Получающий подобную настройку сервис Windows Azure производит поиск конкретного образа операционной системы определенного разработчиком семейства. Необходимо упомянуть, что стандартным значением этой настройки является "*", которое обозначает, что сервис будет запущен на самой новой версии операционной системы и по мере выхода новых версий будет обновлён. Механизм обновления сначала обновляет все сервисы с указанным атрибутом osVersion="*".

Корректная настройка конфигурационных файлов имеет критическое значение для развертывания в облако. Оба конфигурационных файла при развертывании решения Cloud Service в Windows Azure попадают на обработку специальному автоматическому сервису Windows Azure Fabric, который, согласно этим файлам, производит поиск свободных ресурсов, удовлетворяющих конфигурации, инициирует создание и установку виртуальных машин и дальнейшее развертывание решения на эти виртуальные машины. Таким образом, если в конфигурации сервиса настроено N экземпляров для Web-роли и M экземпляров для Worker-роли, то конфигурация развернутого в облако решения примет вид, как на изображении.

Стенды

Непосредственно при развертывании разработчиком проводится настройка того расположения, в которое будет развернуто его решение. В Windows Azure Cloud Services доступно два расположения для развернутого решения – это Production и Staging (используемые для решения, работающего в реальной среде, и решения, развернутого для тестирования, соответственно). Эти расположения, называемые ячейками развертывания, фактически отличаются только доменным именем и внутренними правилами маршрутизации. Так, для Production-ячейки внутренними сервисами настраивается DNS-имя, которое указал разработчик при создании Cloud Service (например, http://appname. , собственное доменное имя указать при развертывании нельзя), для Staging же создается временное DNS-имя типа Ошибка! Недопустимый объект гиперссылки.. При переразвертывании решения в Staging-развертывание DNS-имя сбрасывается на новое.

В том же случае, если решение успешно прошло тестирование в Staging-ячейке, разработчик вместо развертывания решения в Production-ячейку, может нажатием кнопки на портале управления инициировать процедуру VIP Swap. Данная процедура отправляет запрос балансировщику нагрузки, который "меняет местами" Virtual IP, используемый для развертывания, и, таким образом, без каких-бы то ни было физических переносов и миграций за несколько минут решение в Staging-ячейке переходит в ячейку Production. Если же во время выполнения в ячейке Production выявляются ошибки, процедура VIP Swap может быть инициирована повторно, и разработчики могут исправить ошибки и протестировать решение в Staging-ячейке, недоступной конечному пользователю.

Рис. 4. VIP Swap

Масштабирование Cloud Service

Windows Azure Cloud Services могут быть автоматически масштабируемы на основе загрузки CPU или текущего количества сообщений в очереди сообщений хранилища Windows Azure. В панели администрирования Windows Azure Cloud Service пользователь может просматривать прогноз масштабирования, который сообщает о необходимости выполнить масштабирование для развернутого облачного сервиса. Для настройки автоматического масштабирования облачного сервиса необходимо указать период ожидания после каждого изменения масштаба. Пользователь может указать время ожидания в минутах перед следующим увеличением или уменьшением масштаба.

Рис. 5. Маштабирование Cloud Service

Режим автоматического масштабирования на основе количества сообщений позволяет увеличивать или уменьшать число экземпляров облачного сервиса, работающего с очередями, и гарантировать, что количество экземпляров будет изменяться в связи с потребностями (число сообщений в очереди будет вырастать или падать). При этом разработчик задает число сообщений в очереди, при котором Windows Azure будет автоматически масштабировать сервис.