Опубликован: 28.01.2014 | Доступ: свободный | Студентов: 2033 / 171 | Длительность: 14:33:00
Лекция 4:

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

Аннотация: Использование Windows Azure как платформы-как-сервиса, описание архитектуры, использование, на примере многослойного приложения ASP.NET, которое необходимо развернуть в облако и в дальнейшем производить сложное масштабирование всех слоёв по отдельности.

Windows Azure Cloud Services

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

Таблица 5.1. Сравнительные анализ функциональности Web Sites и Cloud Services
Web Sites Cloud Services
Модель использования SaaS PaaS
Рекомендуемый тип приложений Web-приложения, состоящие из клиентской разметки и какой-либо обработки на стороне сервера. Можно масштабировать весь сервис, но не часть его. Приложения, каждый компонент которых необходимо масштабировать отдельно от других. Например, в момент большой нагрузки можно масштабировать только обработчик на стороне сервера, конвертирующий видеофайлы, но оставить количество экземпляров для веб-интерфейса.
Модель развертывания
  • Quick Create – создание пустого сайта,
  • Quick Create with Database – создание пустого сайта и ассоциированной с ним базы данных MySQL/Windows Azure SQL Database,
  • Using the Gallery – создание сайта из подготовленного образа галереи образов Windows Azure Web Sites
  • Web-роль – слой приложения, выполняющий роль веб-интерфейса, взаимоействующего с пользователем,
  • Worker-роль – слой приложения, выполняющий роль обработчика данных.
Сложность миграции существующего приложения Низкая. Существующее веб-приложение можно мигрировать в Web Sites без изменений. Средняя/высокая. В зависимости от ситуации может быть необходимо переосмысление архитектуры существующего приложения для эффективного разделения на Web/Worker-роли.
Администрирование Низкая степень контроля – масштабирование сервиса, сервисы FTP, Team Foundation Services, Git. Запуск веб-сайта (например, WordPress или Drupal) можно осуществить в несколько кликов мышкой. Средняя степень контроля – администраторский доступ, доступ по удаленному рабочему столу RDP к экземплярам ролей, запуск кода с повышенными правами, start-up задачи. Возможна автоматизация администрирования.
Возможность развертывания приложений с использованием Git/FTP Да Да
Поддержка распространенных языков программирования IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP IIS-совместимые технологии, ASP.NET, ASP, Node.js, PHP, Java
Поддержка MySQL Встроенная, с использованием портала управления Есть, но с использованием ClearDB. На портале управления интегрировать сервис с MySQL нельзя.
Стенды (тестовая, production) Нет Да
Доступ по RDP Нет Да
Возможность интеграции сторонних фреймворков Нет Да
Ориентировочное время развертывания <1 минуты Несколько минут
Установка программного обеспечения на сервер Нет Через подключение RDP, Startup-задачи

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

Стандартная модель MVC

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

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

Архитектура Cloud Service

Рис. 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.
Роли в Cloud Service

Рис. 5.3. Роли в Cloud Service
Руслан Муравьев
Руслан Муравьев

Сайт dreamspark пишет что код истек :(

Andriy Zymenko
Andriy Zymenko

Этот курс требует оновления https://portal.azure.com/#create/hub здесь нет пункта Web Site в разделе Compute. К тому же для создание трубуется подписка

Эльнур Умербек
Эльнур Умербек
Казахстан, Астана, Евразийский национальный университет им. Л.Н.Гумилева, 2012