Рекомендации по размещению веб-приложений ASP.NET Core в Azure

Статья
04/11/2023

Совет

Это фрагмент из книги, архитектор современных веб-приложений с ASP.NET Core и Azure, доступный в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно читать в автономном режиме.

Скачать в формате PDF

"Руководители бизнес-подразделений обходятся без участия ИТ-отдела, без труда приобретая облачные приложения (SaaS) и оплачивая их по принципу подписки на журнал. После того как услуга больше не нужна, они могут просто отменить подписку, не оставляя после себя простаивающего без дела оборудования".
- Дарил Пламмер, аналитик Gartner

Microsoft Azure обеспечит соответствие любым требованиям для приложений с любой архитектурой. Вы можете разместить самый простой статический веб-сайт или сложное приложение, состоящее из десятков служб. Для монолитных веб-приложений ASP.NET Core и вспомогательных услуг существует ряд хорошо известных рекомендуемых конфигураций. Приведенные в этой статье рекомендации сгруппированы по виду размещаемых ресурсов (полное приложение, отдельные процессы или данные).

Веб-приложения

Вариант размещения веб-приложений:

Веб-приложения службы приложений
Контейнеры (несколько вариантов)
виртуальные машины;

В большинстве сценариев рекомендуемый вариант — веб-приложения службы приложений, в том числе простые приложения на основе контейнеров. Для архитектуры микрослужб следует рассмотреть подход на основе контейнеров. Если вам требуется больший контроль над машинами, на которых выполняется ваше приложение, рассмотрите возможность использования виртуальных машин Azure.

Веб-приложения службы приложений

Веб-приложения службы приложений предоставляют полностью управляемую платформу, оптимизированную для размещения веб-приложений. Это предложение на основе модели "платформа как услуга" (PaaS) позволяет вам сосредоточиться на бизнес-логике, передав все задачи по организации инфраструктуры для выполнения и масштабирования приложения на сторону Azure. Некоторые основные возможности веб-приложений служб приложений:

Оптимизация принципов DevOps (непрерывная интеграция и поставка, несколько окружений, A/B-тестирование, поддержка скриптов).
Глобальная масштабируемость и высокий уровень доступности.
Подключения к платформам SaaS и локальным данным.
Безопасность и соответствие требованиям.
Интеграция Visual Studio.

Самым оптимальным вариантом для большинства веб-приложений является служба приложений Azure. Процессы развертывания и управления являются уже интегрированными в платформу, при этом имеется возможность оперативного масштабирования сайтов для удовлетворения высоких нагрузок по трафику, а встроенные инструменты для балансировки нагрузки и управления трафиком обеспечивают высокую доступность. Вы можете с легкостью перенести существующие сайты в Службу приложений Azure с помощью инструмента миграции в Интернете. Вы можете использовать специальное приложение с открытым кодом из коллекции веб-приложений или создать новый сайт с помощью удобных для вас инструментов и платформы. С помощью функции веб-заданий вы можете с легкостью реализовать фоновую обработку заданий в своем веб-приложении службы приложений. Если у вас есть приложение ASP.NET, размещенное локально и использующее локальную базу данных, то существует четкий путь миграции. Вы можете использовать веб-приложение Службы приложений с Базой данных SQL Azure (или безопасный доступ к локальному серверу баз данных, если это предпочтительнее).

Recommended migration strategy for on-premises .NET apps to Azure App Service

В большинстве случаев перейти с локально размещенного приложения ASP.NET на веб-приложение Службы приложений очень просто. Само приложение практически не нужно изменять. Его можно быстро развернуть в облаке, где веб-приложению доступны преимущества, обеспечиваемые множеством функций Службы приложений.

Помимо приложений, которые не оптимизированы для облака, веб-приложения Службы приложений Azure станут оптимальным решением для простых монолитных (нераспределенных) приложений, как многие приложения ASP.NET Core. При таком подходе требуется базовая архитектура, простая в понимании и управлении:

Basic Azure architecture

Небольшого количества ресурсов в одной группе ресурсов, как правило, достаточно для управления таким приложением. Приложения, которые обычно развертываются как единое целое (в отличие от приложений, состоящих из множества отдельных процессов), — хороший вариант для такого подхода с базовой архитектурой. Несмотря на простую архитектуру, такой подход позволяет масштабировать размещенное приложение как вертикально (добавляя ресурсы в узлах), так и горизонтально (увеличивая количество узлов) в соответствии с ростом спроса. Автоматическое масштабирование позволяет настроить приложение для автоматической регулировки количества узлов, на которых размещается приложение, на основе показателей спроса и средней нагрузки узлов.

Веб-приложения службы приложений для контейнеров

В дополнение к поддержке непосредственного размещения веб-приложений, можно использовать веб-приложения службы приложений для контейнеров для запуска контейнерных приложений в Windows и Linux. Эта служба позволяет без труда развертывать и запускать контейнерные приложения, которые можно масштабировать по мере развития вашего бизнеса. Для таких приложений доступны все возможности веб-приложений службы приложений, перечисленные выше. Кроме того, веб-приложения для контейнеров поддерживают оптимизированный конвейер CI/CD с использованием Docker Hub, Реестра контейнеров Azure и GitHub. Определять конвейеры сборки и развертывания с публикацией изменений в реестр можно с помощью Azure DevOps. Эти изменения затем можно тестировать в промежуточной среде и автоматически развертывать в рабочей среде с помощью слотов развертывания, которые обеспечивают обновление без простоя. Возврат к предыдущей версии выполняется так же просто.

Существует несколько сценариев, в которых веб-приложения для контейнеров особенно полезны. Если у вас есть приложения, которые можно упаковать в контейнеры Windows или Linux, вы можете легко их разместить с помощью этого набора инструментов. Просто опубликуйте контейнер, а затем настройте веб-приложения для контейнеров, чтобы извлечь последнюю версию этого образа из реестра по выбору. Этот подход предусматривает миграцию без прекращения оптимизации приложения и переход с классической модели размещения на модель с оптимизацией для облачных сред.

Migrate containerized on-premises .NET application to Azure Web Apps for Containers

Такой подход также эффективен, если ваша команда разработчиков способна освоить процесс разработки на основе контейнеров. "Внутренний цикл" разработки приложений с контейнерами включает в себя сборку приложений с контейнерами. Изменения, внесенные в код и в конфигурацию контейнера, передаются в систему управления версиями. После этого система автоматизированной сборки публикует новые образы контейнера в реестре, таком как Docker Hub или Реестр контейнеров Azure. Эти образы затем используются в качестве основы для дополнительной разработки, а также для развертываний в рабочей среде, как показано на следующей схеме:

End to End Docker DevOps Lifecycle Workflow

Разработка с использованием контейнеров имеет множество преимуществ, особенно если контейнеры используются в рабочей среде. Одна и та же конфигурация контейнеров используется для размещения приложения в каждой среде, в которой оно работает, от локального компьютера разработки для сборки и тестирования до рабочей среды. Это значительно снижает вероятность возникновения конфликтов из-за различий в конфигурациях компьютеров или в версиях программного обеспечения. Разработчики также могут использовать любые удобные для них средства, включая ОС, так как контейнеры можно запускать в любой операционной системе. Иногда распределенные приложения с большим числом контейнеров могут оказаться крайне ресурсоемкими для запуска на одиночном компьютере разработки. В таком случае целесообразно воспользоваться Kubernetes и Azure Dev Spaces (см. следующий раздел).

Так как части больших приложений разделены на небольшие независимые микрослужбы, можно использовать другие модели организации разработки для улучшения работы приложения. Можно не работать непосредственно с отдельными службами, а использовать шлюз API, который упрощает доступ и позволяет размежевать клиент и его серверную часть. Наличие у службы отдельных серверных частей для разных внешних интерфейсов также позволяет службе развиваться вместе с ее пользователями. Доступ к стандартным службам можно обеспечить с помощью сцепленного контейнера, в котором могут находиться общие библиотеки подключения пользователей, и с использованием модели "посол".

Microservices sample architecture with several common design patterns noted.

Ознакомьтесь с дополнительными сведениями о моделях разработки, которые следует учитывать при создании систем на базе микрослужб.

Служба Azure Kubernetes

Служба Azure Kubernetes (AKS) управляет размещенной средой Kubernetes, позволяя быстро и легко развертывать контейнерные приложения и управлять ими, даже если вы никогда не оркестрировали контейнеры. Это позволяет устранить нагрузку, связанную с текущими операциями и обслуживанием, благодаря подготовке, обновлению и масштабированию ресурсов по требованию без перевода приложения в автономный режим.

AKS снижает сложность управления кластером Kubernetes и связанные временные затраты, делегируя ответственность за большую их часть облаку Azure. Размещенная в Azure служба Kubernetes отвечает за критические задачи, в частности за мониторинг работоспособности и техническое обслуживание. Кроме того, вы платите только за узлы агентов в своих кластерах, а не за главные узлы. AKS как управляемая служба Kubernetes обеспечивает следующее:

Автоматические обновления и исправления версий Kubernetes.
Простое масштабирование кластеров.
Самовосстанавливающуюся размещенную область управления (главные узлы).
Сокращение затрат — вы платите только за выполняющиеся узлы пула агентов.

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

Командам разработчиков, использующим AKS, также доступны преимущества, которые предоставляет Azure Dev Spaces. Azure Dev Spaces помогает командам сосредоточиться на разработке и быстрой последовательной доработке приложения для микрослужб, позволяя им работать непосредственно со всей архитектурой микрослужб или приложением в AKS. Azure Dev Spaces также дает возможность независимо обновлять части архитектуры микрослужб в режиме изоляции, не влияя на остальную часть кластера AKS или работу других разработчиков.

Azure Dev Spaces workflow example

Azure Dev Spaces:

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

Дополнительные сведения об Azure DevOps

Виртуальные машины Azure

Если вам требуется внести серьезные изменения в существующее приложение для работы в службе приложений, вы можете упростить миграцию в облако с помощью виртуальных машин. Тем не менее для корректной настройки, защиты и обслуживания виртуальных машин требуется гораздо больше времени и опыта по сравнению со службой приложений Azure. Если вы планируете использовать виртуальные машины Azure, необходимо учитывать затраты времени и ресурсов на текущее обслуживание, установку исправлений и обновлений, а также на управление средой виртуальных машин. Виртуальные машины Azure реализуются на основе концепции "инфраструктура как услуга" (IaaS), тогда как служба приложений построена на основе модели "платформа как услуга" (PaaS). Также следует учесть, может ли развертывание приложения как контейнера Windows в веб-приложении для контейнеров быть приемлемым вариантом для вашего сценария.

Логические процессы

Отдельные логические процессы, которые могут быть отделены от остальной части приложения, могут развертываться независимо от функций Azure в режиме "без сервера". Благодаря функциям Azure вы можете просто написать код для решения возникшей проблемы, не беспокоясь о приложении или инфраструктуре, необходимых для его выполнения. Вы можете выбрать различные языки программирования, включая C#, F#, Node.js, Python и PHP, что позволяет выбрать наиболее продуктивный язык для задачи. Как и в случае с большинством облачных решений, вы платите только за время использования и при необходимости всегда можете рассчитывать на возможность масштабирования с использованием функций Azure.

Data

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

Для работы с транзакционными и реляционными данными лучше всего подходят базы данных SQL Azure. Для данных, предназначенных преимущественно для высокопроизводительных операций чтения, эффективным решением будет кэш Redis на основе базы данных SQL Azure.

Неструктурированные данные JSON могут храниться разными способами, включая столбцы базы данных SQL, большие двоичные объекты, таблицы в службе хранилища Azure или Azure Cosmos DB. Среди этих вариантов лучшую производительность при обработке запросов обеспечивает служба Azure Cosmos DB. Это оптимальный вариант для работы с большим числом документов JSON, требующих поддержки запросов.

Для данных на основе промежуточных команд или событий, используемых для оркестрации поведения приложения, можно использовать служебную шину или очереди хранилища Azure. Служебная шина Azure обеспечивает большую гибкость и является оптимальным вариантом для нетривиального обмена сообщениями в пределах одного приложения или между приложениями.