Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Это важно
Облачные службы (классическая версия) переведены в разряд устаревших для всех клиентов с 1 сентября 2024 года. Все существующие запущенные развертывания будут остановлены и завершены корпорацией Майкрософт, и данные будут окончательно потеряны начиная с октября 2024 года. Для новых развертываний следует использовать Облачные службы Azure с расширенной поддержкой. Это новая модель развертывания на основе Azure Resource Manager.
Облачные службы Azure являются примером концепции платформа как услуга (PaaS). Так же как и служба приложений Azure, эта технология предназначена для поддержки масштабируемых, надежных и недорогих в эксплуатации приложений. Аналогично тому, как служба приложений размещается на виртуальных машинах (VM), облачные службы Azure также размещены на них. Однако у вас есть больше контроля над виртуальными машинами. Вы можете установить собственное программное обеспечение на виртуальных машинах, использующих облачные службы Azure, и получить к ним удаленный доступ.
Дополнительный контроль, помимо прочего, усложняет использование. Если вам не нужны дополнительные параметры управления, обычно быстрее и проще запустить веб-приложение в функции Web Apps службы приложений, чем в Облачных службах Azure.
Существует два типа ролей облачных служб Azure. Единственное различие между двумя заключается в способе размещения вашей роли на виртуальных машинах.
Веб-роль: автоматически развертывает и размещает ваше приложение через службы Интернет-информационных служб (IIS).
Рабочая роль: не использует службы IIS и запускает автономное приложение.
Например, простое приложение может использовать только одну веб-роль, обслуживающую веб-сайт. Более сложное приложение может использовать веб-роль для обработки поступающих от пользователей запросов, а затем передавать эти запросы в рабочую роль для обработки. (Это сообщение может использовать Azure Service Bus или Azure Queue Storage.)
Как видно из предыдущего рисунка, все виртуальные машины в рамках отдельного приложения выполняются в одной облачной службе. Пользователи осуществляют доступ к приложению через отдельный общедоступный IP-адрес, при этом для виртуальных машин приложения выполняется автоматическая балансировка нагрузки. Платформа масштабирует и развертывает виртуальные машины в приложении облачных служб Azure таким образом, чтобы исключить единственную точку отказа оборудования.
Несмотря на то, что приложения выполняются в виртуальных машинах, важно понимать, что облачные службы Azure предоставляют PaaS, а не инфраструктуру как услугу (IaaS). Ниже рассматривается один из способов. В модели IaaS, такой как виртуальные машины Azure, сначала создайте и настройте среду, в которой будет работать приложение. Затем разверните приложение в этой среде. Вы несете ответственность за управление большей частью этой среды, включая развертывание новых исправленных версий операционной системы в каждой виртуальной машине. В отличие от этого, в PaaS среда как будто уже существует. Вам нужно всего лишь развернуть свое приложение. Управление платформой, на базе которой оно выполняется, включая развертывание новых версий операционной системы, осуществляется за вас.
Масштабирование и управление
При использовании облачных служб Azure вы не создаете виртуальные машины. Вместо этого предоставляется файл конфигурации, сообщающий Azure, сколько ресурсов вам требуется, например три экземпляра веб-роли и два экземпляра рабочей роли. Платформа создаст их самостоятельно. Вам все равно нужно выбрать размер для резервных виртуальных машин, но не требуется явно создавать их самостоятельно. Если ваше приложение сталкивается с высокой нагрузкой, вы можете запросить дополнительные виртуальные машины, после чего Azure создаст необходимые экземпляры. Если нагрузка уменьшается, вы можете выключить эти экземпляры и перестать за них платить.
В основном приложение облачных служб Azure можно сделать доступным пользователям за два следующих этапа. Сначала разработчик загружает приложение в зону тестирования платформы. Когда разработчик готов сделать приложение доступным, он использует портал Azure для переключения стадии промежуточного тестирования на производственную. Это переключение из промежуточной области в производственную можно выполнить без простоя, что позволяет обновить запущенное приложение до новой версии, не нарушая работу пользователей в нем.
Контроль
Кроме того, облачные службы Azure обеспечивают мониторинг. Как и модель виртуальных машин, эта модель обнаруживает неисправный физический сервер и перезапускает выполняемые на нем виртуальные машины на новом компьютере. Однако облачные сервисы Azure обнаруживают не только аппаратные сбои, но и неисправные виртуальные машины и приложения. В отличие от виртуальных машин, она использует агент внутри каждой веб-роли и рабочей роли, что позволяет в случае сбоя запустить новые виртуальные машины и экземпляры приложений.
Характер PaaS облачных служб Azure также имеет другие последствия. Одним из наиболее важных последствий является то, что следует создавать приложения, созданные на основе этой технологии, чтобы правильно выполняться при сбое любого экземпляра веб-роли или рабочей роли. Чтобы достичь этой цели, приложение Azure Cloud Services не должно поддерживать состояние в файловой системе собственных ВМ. В отличие от ВМ, созданных с помощью виртуальных машин, операции записи для виртуальных машин облачной службы Azure не сохраняются надолго. Нет ничего подобного диску данных в виртуальных машинах. Вместо этого приложение облачных служб Azure должно явным образом записывать все данные о состоянии в базу данных SQL, BLOB-объекты, таблицы или любое другое внешнее хранилище Azure. Создание приложений таким образом упрощает их масштабирование и делает их более устойчивыми к сбоям. Масштабируемость и устойчивость являются важными целями Azure Облачные службы.