Изменить

Базовое веб-приложение

Служба приложений Azure
Azure Key Vault
Azure Monitor
База данных SQL Azure

В этой архитектуре показаны основные компоненты базового веб-приложения. Архитектуру можно использовать для создания веб-приложения, а затем настройки приложения в соответствии с вашими потребностями.

Архитектура

Diagram showing the reference architecture for a basic web application in Azure.

Скачайте файл Visio для этой архитектуры.

Компоненты

  • Служба приложений Azure — это полностью управляемая платформа для создания и развертывания облачных приложений. Он позволяет определить набор вычислительных ресурсов для запуска, развертывания веб-приложений и настройки слотов развертывания.
  • Слоты развертывания позволяют выполнять развертывание, а затем переключать его с рабочим развертыванием. Это дает возможность избежать развертываний непосредственно в рабочей среде. Дополнительные рекомендации см. в разделе "Проектирование выпусков" и "Развертывание ".
  • IP-адрес: приложение Служба приложений имеет общедоступный IP-адрес и доменное имя. К доменному имени добавляется имя поддомена azurewebsites.net, например: contoso.azurewebsites.net.
  • Azure DNS — это служба размещения для доменов DNS, которая предоставляет разрешение имен с помощью инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure. Чтобы использовать имя личного домена (например contoso.com), создайте записи DNS, сопоставляющие имя личного домена с IP-адресом. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени с веб-приложениями Azure.
  • База данных SQL Azure — это реляционная база данных как услуга в облаке. База данных SQL использует свою базу кода совместно с ядром СУБД Microsoft SQL Server. В зависимости от требований приложения можно также использовать службу База данных Azure для MySQL или База данных Azure для PostgreSQL. Эти альтернативы являются полностью управляемыми службами баз данных на основе ядра субД MySQL с открытым исходным кодом и Postgres.
  • Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом, которая позволяет сотрудникам получать доступ к облачным приложениям, разработанным для вашей организации.
  • Azure Monitor — это решение для сбора, анализа и действия в журналах и метрик в средах.
  • Azure Key Vault поддерживает управление секретами, управление ключами и управление сертификатами. Он может хранить секреты приложений, такие как строка подключения базы данных.

Рекомендации

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

План службы приложений

План Служба приложений имеет разные ценовые категории. Каждая ценовая категория поддерживает несколько размеров экземпляров , которые отличаются по количеству ядер и памяти. Вы можете изменить ценовую категорию после развертывания, выбрав пункт "Масштаб (Служба приложений план)" в области навигации слева. Ниже приведены некоторые Служба приложений рекомендации.

  • Запустите рабочую нагрузку рабочей нагрузки на ценовых категориях "Базовый", "Стандартный" и "Премиум ". В этих трех уровнях приложение работает на выделенных экземплярах виртуальных машин и выделяет ресурсы, которые могут масштабироваться.
  • Используйте уровни "Стандартный" и "Премьер", если требуется автомасштабирование и TLS/SSL.
  • Создайте другой план Служба приложений для тестирования и разработки. Используйте уровни "Бесплатный" и "Общий ( предварительная версия) для тестирования и разработки для повышения эффективности затрат. Но не используйте уровни "Бесплатный " и "Общий" для рабочих нагрузок. Общие ресурсы не могут масштабироваться.
  • Не забудьте удалить планы, которые вы не используете, например тестовые развертывания. Плата за план службы приложений начисляется посекундно. Плата взимается за экземпляры в плане Служба приложений, даже если приложение остановлено. Дополнительные сведения о планах и выставлении счетов Служба приложений см. в следующем разделе:

Приведенный ниже шаблон ARM развертывается в ценовой категории "Стандартный".

База данных SQL

  • Используйте База данных SQL Azure для уменьшения затрат на управление. База данных SQL Azure создает логическую конструкцию, которая выступает в качестве центральной административной точки для коллекции баз данных. Эта логическая конструкция снижает затраты на управление. Каждая база данных в группе развертывается с определенным уровнем служб. В каждой группе базы данных не могут совместно использовать ресурсы. Затраты на вычисления для сервера отсутствуют, но необходимо указать уровень для каждой базы данных. Таким образом, производительность может быть лучшей из-за выделенных ресурсов, но стоимость может быть выше.
  • Оцените потребности в производительности и выберите подходящие уровни базы данных и производительности. Служба "База данных SQL" поддерживает уровни служб "Базовый", "Стандартный" или "Премиум", а также несколько уровней производительности для каждого из них, которые измеряются в единицах передачи данных (DTU).

Регион

  • Создайте план Служба приложений и База данных SQL в том же регионе, чтобы свести к минимуму задержку в сети. Обычно лучше выбирать регион, ближайший к пользователям приложения.
  • Группа ресурсов также привязана к региону. Он указывает, где хранятся метаданные развертывания. Поместите группу ресурсов и ее ресурсы в один регион, чтобы увеличить доступность во время развертывания.
  • Используйте калькулятор цен для оценки затрат.
  • См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.

Рекомендации

Эти рекомендации реализуют основные принципы хорошо спроектированной платформы Azure. Основные принципы — это набор руководящих принципов, которые повышают качество рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Оптимизация производительности

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

Масштабирование приложения в службе приложений

Есть два способа масштабировать приложение службы приложений:

  • Увеличение масштаба означает изменение размера экземпляра. Размер определяет доступный объем памяти, хранилища и количество ядер для каждого экземпляра виртуальной машины. Вертикальное масштабирование выполняется вручную путем изменения размера экземпляров или уровня плана.
  • Горизонтальное масштабирование означает добавление экземпляров для обработки повышенной нагрузки. В каждой ценовой категории есть ограничение на число экземпляров. Горизонтальное масштабирование можно выполнить вручную, изменив количество экземпляров или настроив автомасштабирование для автоматического добавления или удаления экземпляров Azure в зависимости от расписания и (или) метрик производительности. Каждая операция масштабирования выполняется быстро, как правило, в течение секунд.

Чтобы включить автомасштабирование, создайте профиль автомасштабирования, определяющий минимальное и максимальное количество экземпляров. Профили на основе расписания можно настроить для активации событий масштабирования. Например, можно создать отдельные профили для дней недели и выходных. Профиль может содержать правила для добавления или удаления экземпляров. Например, добавление двух экземпляров, если использование ЦП превышает 70 % в течение 5 минут.

Рекомендации по масштабированию веб-приложения:

  • Максимальное ограничение масштабирования вверх и вниз. Он может активировать перезапуск приложения. Вместо этого горизонтальное масштабирование. Выберите уровень и размер, которые соответствуют вашим требованиям к производительности при обычной нагрузке, а затем масштабируйте экземпляры для обработки изменений в томе трафика.
  • Примените функцию автомасштабирования. Если объем рабочей нагрузки для вашего приложения стабилен и прогнозируем, создайте профили и расписание для своевременного добавления экземпляров. Если рабочая нагрузка не предсказуема, используйте автоматическое масштабирование на основе правил для реагирования на изменения нагрузки по мере их возникновения. Можно использовать оба подхода одновременно.
  • Используйте использование ЦП для правил автомасштабирования. Обычно в качестве метрики для правил автомасштабирования хорошо подходит загрузка ЦП. Но мы рекомендуем провести нагрузочный тест для приложения, определить потенциальные узкие места и в соответствии с ними создать правила автомасштабирования.
  • Задайте более короткий период охлаждения для добавления экземпляров и более длительный период охлаждения для удаления экземпляров. Правила автомасштабирования включают период охлаждения . Период охлаждения — это интервал ожидания после завершения действия масштабирования перед началом нового действия масштабирования. Период ожидания позволяет стабилизировать систему перед новым масштабированием. Например, 5 минут при добавлении экземпляра и 60 минут при его удалении. Лучше быстро добавлять новые экземпляры под тяжелой нагрузкой, чтобы обрабатывать дополнительный трафик, а затем постепенно уменьшать масштаб.

Масштабирование баз данных SQL

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

Дополнительные сведения см. в статье Масштабирование ресурсов отдельной базы данных в Базе данных SQL Azure.

Надежность

На момент написания статьи соглашение об уровне обслуживания (SLA) для Служба приложений составляет 99,95%. Соглашения об уровне обслуживания в службе приложений действуют как для одного, так и для нескольких экземпляров. Соглашение об уровне обслуживания для База данных SQL составляет 99,99% для уровней "Базовый", "Стандартный" и "Премиум".

Резервные копии

База данных SQL обеспечивает восстановление и геовосстановление на определенный момент времени для восстановления потери данных. Эти функции доступны на всех уровнях и включаются автоматически. Нет необходимости настраивать расписание или параметры резервного копирования.

Эффективность работы

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

При назначении ресурсов группам ресурсов рассмотрите следующие возможности:

  • Жизненный цикл. Обычно в группу ресурсов лучше объединять ресурсы с одинаковым жизненным циклом.
  • Доступ. Управление доступом на основе ролей Azure (RBAC) можно использовать для применения политик доступа к ресурсам в группе.
  • Выставление счетов. Вы сможете просматривать сведенные затраты для группы ресурсов.

Дополнительные сведения см. в обзоре Azure Resource Manager.

Конфигурации приложений

  • Сохраняйте конфигурацию в виде настроек приложений. Определите параметры приложения в шаблонах Resource Manager или с помощью PowerShell. В среде выполнения параметры приложений доступны из приложения как переменные среды.
  • Ни в коем случае не помещайте пароли, ключи доступа или строки подключения в систему управления версиями. Вместо этого передайте секреты в качестве параметров в скрипт развертывания, который сохраняет эти значения в качестве параметров приложения.
  • При переключении слотов развертывания по умолчанию заменяются и параметры приложения. Если вам нужны разные рабочие и промежуточные параметры, можно создать параметры приложения, которые прилипают к слоту и не переключятся.

Диагностика и мониторинг

DevOps

  • Используйте шаблоны ARM для развертывания ресурсов Azure и их зависимостей. Сопровождающий шаблон ARM развертывает одно веб-приложение. Все ресурсы изолированы в одной базовой рабочей нагрузке. Эта изоляция упрощает связывание конкретных ресурсов рабочей нагрузки с командой. Затем команда может самостоятельно управлять всеми аспектами этих ресурсов. Эта изоляция позволяет команде DevOps выполнять непрерывную интеграцию и непрерывную доставку (CI/CD).
  • Используйте различные шаблоны ARM и интегрируйте их со службами Azure DevOps. Эта настройка позволяет создавать разные среды в минутах. Например, можно реплика рабочих сценариев или сред нагрузочного тестирования только при необходимости и экономии на затратах.
  • Подготовка нескольких экземпляров веб-приложения. Вы не хотите, чтобы веб-приложение зависел от одного экземпляра и потенциально создавало одну точку сбоя. Несколько экземпляров повышают устойчивость и масштабируемость.

Дополнительные сведения см. в разделе DevOps в Azure Well-Architected Framework.

Проектирование выпусков и развертывание

  • Используйте шаблоны Azure Resource Manager для подготовки ресурсов Azure. Шаблоны упрощают автоматическое развертывание с помощью PowerShell или Azure CLI.
  • Разверните приложение (файлы кода, двоичные файлы и файлы содержимого). Здесь у вас есть несколько вариантов, в том числе: развертывание из локального репозитория Git, с помощью Visual Studio или непрерывное развертывание из системы управления версиями в облаке. Дополнительные сведения см. в статье о развертывании приложения в службе приложений Azure.

Приложение Служба приложений всегда имеет один слот productionразвертывания. Рабочий слот представляет рабочий сайт. Мы рекомендуем создать еще и промежуточный слот для развертывания обновлений. Промежуточный слот предоставит следующие преимущества:

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

Swapping slots for production and staging deployments

  • Если потребуется вернуться к предыдущей версии, убедитесь, что все изменения схемы базы данных имеют обратную совместимость.
  • Не используйте слоты рабочего развертывания для тестирования, так как для всех приложений в одном плане службы приложений используются одни и те же экземпляры виртуальных машин. Например, нагрузочные тесты могут привести к ухудшению производительности активного рабочего сайта. Вместо этого создайте дополнительные планы службы приложений для рабочей и тестовой сред. Поместив тестовые развертывания в отдельный план, можно изолировать их от рабочей версии.

Безопасность

В этом разделе перечислены рекомендации по безопасности, относящиеся к службам Azure, описанным в этой статье. Это не полный список рекомендаций по обеспечению безопасности. Дополнительные сведения о безопасности см. в статье "Защита приложения в службе приложение Azure".

Аудит Баз данных SQL

Аудит поможет вам обеспечить соответствие нормативным требованиям и получать важные сведения об отклонениях и аномалиях, которые могут указывать на бизнес-проблемы или потенциальные нарушения безопасности. См. статью Приступая к работе с аудитом базы данных SQL.

Слоты развертывания

Каждый слот развертывания имеет общедоступный IP-адрес. Защитите непроизводственные слоты с помощью имени входа Microsoft Entra, чтобы только члены вашей команды разработки и DevOps могли достичь этих конечных точек.

Ведение журнала

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

SSL

Приложение Служба приложений включает конечную точку SSL в поддомене azurewebsites.net без дополнительных затрат. Конечная точка SSL содержит групповой сертификат для доменного имени *.azurewebsites.net. Чтобы применить пользовательское доменное имя, самостоятельно предоставьте для него сертификат. Для этого проще всего приобрести сертификат непосредственно на портале Azure. Также вы можете импортировать сертификаты других центров сертификации. Дополнительные сведения см. в статье о покупке и настройке SSL-сертификата для службы приложение Azure.

HTTPS не включен по умолчанию в развертывании шаблона ARM. Из соображений безопасности следует принудительно применять в приложении протокол HTTPS, перенаправляя все HTTP-запросы. Вы можете реализовать HTTPS в приложении или использовать правило перезаписи URL-адресов, как описано в включении HTTPS для приложения в службе приложение Azure.

Проверка подлинности

Мы рекомендуем выполнить проверку подлинности через поставщика удостоверений (IDP), например идентификатор Microsoft Entra, Facebook, Google или Twitter. Используйте в потоке аутентификации маркеры OAuth 2 или OpenID Connect (OIDC). Идентификатор Microsoft Entra предоставляет функциональные возможности для управления пользователями и группами, создания ролей приложений, интеграции локальных удостоверений и использования внутренних служб, таких как Microsoft 365 и Skype для бизнеса.

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

Рассмотрите возможность использования Служба приложений проверки подлинности для реализации потока проверки подлинности OAuth или OIDC. Аутентификация службы приложений дает следующие преимущества:

  • Простота настройки.
  • Вам не нужно писать код для сценариев аутентификации.
  • Поддержка делегированной авторизации с помощью маркеров доступа OAuth для использования ресурсов от имени пользователя.
  • Встроенные кэши маркеров.

Аутентификация службы приложений имеет и ряд ограничений:

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

Развертывание этого сценария

Эта архитектура включает в себя план службы приложение Azure и пустое приложение. Он использует База данных SQL Azure, Azure Key Vault для хранения строка подключения базы данных и Azure Monitor для ведения журналов, мониторинга и оповещений.

Выполните следующую команду, чтобы создать группу ресурсов для развертывания. Нажмите кнопку "Попробовать", чтобы использовать внедренную оболочку.

az group create --name basic-web-app --location eastus

Выполните следующую команду, чтобы развернуть веб-приложение и поддержку инфраструктуры. При появлении запроса введите имя пользователя и пароль. Эти значения используются для доступа к экземпляру База данных SQL Azure.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Подробные сведения и дополнительные варианты развертывания см. в шаблонах ARM, используемых для развертывания этого решения.

Базовый шаблон ARM веб-приложения

Следующие шаги

Советы по устранению неполадок в приложениях.

Документация по продукту:

Модули Microsoft Learn.