Корпоративное развертывание, использующее App Service Environment

Microsoft Entra ID

Шлюз приложений Azure

Служба приложений Azure

Брандмауэр Azure

Виртуальная сеть Azure

Приватный канал Azure

Эта эталонная архитектура демонстрирует общую корпоративную рабочую нагрузку, которая использует Azure App Service Environment версии 3. В нем также описываются рекомендации по укреплению безопасности рабочей нагрузки.

Замечание

App Service Environment версии 3 является основным компонентом этой архитектуры. Версии 1 и 2 были прекращены 31 августа 2024 года.

Architecture

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

Эталонная реализация для этой архитектуры доступна в GitHub.

Рабочий процесс

Вы можете развернуть App Service Environment двумя способами:

Как внешняя Среда службы приложений с общедоступным IP-адресом
Как internal App Service Environment с внутренним IP-адресом, принадлежащим внутренней подсистеме балансировки нагрузки (ILB)

Эта референтная архитектура развертывает корпоративное веб-приложение во внутренней среде App Service, также называемой ILB App Service Environment. Используйте App Service Environment с внутренним балансировщиком нагрузки (ILB) в сценариях, требующих следующих возможностей:

Размещение приложений интрасети с повышенной безопасностью в облаке и доступ к ним через VPN типа "сеть — сеть" или Azure ExpressRoute.
Предоставьте уровень защиты для приложений с помощью брандмауэра веб-приложения (WAF).
Размещение приложений в облаке, которые не перечислены на серверах общедоступной системы доменных имен (DNS).
Создавайте интернет-изолированные серверные приложения, с которыми интерфейсные приложения могут интегрироваться высоко безопасным образом.

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

Эта эталонная реализация развертывает веб-приложение с именем Voting App, которое взаимодействует с частным веб-API и функцией. Он также развертывает макет веб-приложения с именем Test App для демонстрации развертываний нескольких приложений. В эталонной реализации каждое приложение службы приложений выполняется в собственном плане службы приложений, что обеспечивает независимое масштабирование при необходимости.

Простое приложение для голосования в этой реализации позволяет пользователям просматривать существующие записи, создавать новые записи и голосовать за существующие записи. Веб-API создает и извлекает записи и голоса. Данные хранятся в базе данных Azure SQL. Чтобы продемонстрировать асинхронные обновления данных, веб-приложение помещает в очередь новых добавленных голосов в экземпляре Service Bus. Функция извлекает голоса из очереди и обновляет базу данных SQL. Azure Cosmos DB хранит макет рекламы, которую веб-приложение извлекает для отображения в браузере. Приложение использует Azure Managed Redis для управления кэшем. Оптимизированный сбалансированный уровень Azure Managed Redis настроен в той же виртуальной сети, что и App Service Environment, и запускается в своей собственной подсети. Эта настройка обеспечивает повышенную безопасность и изоляцию для кэша.

Веб-приложения — это единственные компоненты, доступные из Интернета. Интернет-трафик должен проходить через Azure Application Gateway, который защищен WAF. Интернет-клиент не может получить доступ к API или приложению-функции.

Components

Azure Virtual Network — это частная Azure облачная сеть, принадлежащую вашей организации. Она обеспечивает расширенную сетевую безопасность и изоляцию. Эта архитектура развертывает App Service Environment в подсети корпоративной виртуальной сети. App Service Environment позволяет вашей организации жестко контролировать сетевое пространство и ресурсы, к которым он обращается с помощью групп безопасности сети (NSG) и частных конечных точек.
Шлюз приложений — это подсистема балансировки нагрузки веб-трафика на уровне приложения, которая содержит разгрузку протокола TLS или SSL и WAF. В этой архитектуре Шлюз приложений принимает входящий трафик на общедоступный IP-адрес и направляет его в конечную точку приложения в App Service Environment ILB. Эта маршрутизация на уровне приложения может направлять трафик в несколько приложений в одном ILB (внутренней балансировке нагрузки) App Service Environment. Дополнительные сведения см. в разделе " Многосайтовое размещение шлюза приложений".
Azure Firewall — это облачная служба брандмауэра с отслеживанием состояния, встроенная в Azure. Она обеспечивает высокий уровень доступности и неограниченное масштабируемость облака, а также поддерживает правила фильтрации входящих и исходящих подключений. В этой архитектуре Azure Firewall ограничивает исходящий трафик из веб-приложения. Таблица маршрутов настроена для маршрутизации исходящего трафика, который не проходит через каналы частной конечной точки в брандмауэр. Для простоты эта архитектура настраивает все частные конечные точки в подсети служб.
Microsoft Entra ID — это продукт для идентификации и доступа к сети, обеспечивающий управление правами доступа и разрешениями для Azure ресурсов и служб. Управляемые удостоверения предоставляют удостоверения службам и приложениям. Они могут пройти проверку подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra. Этот подход удаляет необходимость явной настройки учетных данных для этих приложений. Эта архитектура присваивает управляемую идентичность веб-приложению.
Azure Key Vault — это облачная служба, которая безопасно хранит конфиденциальные данные, такие как секреты, ключи шифрования и сертификаты. Эта архитектура использует Key Vault для хранения секретов и учетных данных, необходимых приложениям. Используйте этот параметр вместо хранения секретов непосредственно в приложении.
GitHub Actions — это функция автоматизации рабочих процессов, встроенная в GitHub, которая обеспечивает непрерывную интеграцию и непрерывную доставку (CI/CD). В этой архитектуре App Service Environment находится в виртуальной сети, поэтому виртуальная машина служит в качестве сервера-посредника для развертывания приложений в планах службы приложений. Действие создает приложения за пределами виртуальной сети. Для повышения безопасности и простого подключения протокола Remote Desktop (RDP) и Secure Shell (SSH) рекомендуется использовать Azure Bastion для поля перехода.

Конфигурация с несколькими сайтами

Внутренняя App Service Environment может размещать несколько веб-приложений и API с конечными точками HTTP. Эти приложения не предоставляются в общедоступном Интернете, так как IP-адрес ILB можно получить только из виртуальной сети. Шлюз приложений выборочно предоставляет эти приложения в Интернете. App Service Environment назначает URL-адрес по умолчанию каждому приложению службы приложений как <default-appName>.<app-service-environment-domain>.appserviceenvironment.net. Создается приватная DNS-зона private DNS, которая сопоставляет доменное имя App Service Environment с внутренним IP-адресом балансировщика нагрузки App Service Environment. Этот подход позволяет избежать пользовательского DNS-доступа к приложениям в виртуальной сети.

Шлюз приложений настроен для включения прослушивателя , который принимает HTTP-запросы на IP-адрес шлюза. Для простоты эта реализация не использует регистрацию общедоступного DNS-имени. Необходимо изменить файл localhost на компьютере, чтобы указать произвольный URL-адрес IP-адреса шлюза приложений. Прослушиватель использует самозаверяющий сертификат для обработки этих запросов.

Шлюз приложений имеет внутренние пулы для каждого URL-адреса приложения службы приложений по умолчанию. Правило маршрутизации настроено для подключения прослушивателя к внутреннему пулу.

параметры HTTP определяют, будет ли подключение между шлюзом и App Service Environment зашифрованным. Эти параметры также переопределяют входящий заголовок узла HTTP с именем узла из внутреннего пула. Эта реализация использует сертификаты по умолчанию, созданные для URL-адресов приложений по умолчанию App Service Environment, а шлюз доверяет этим сертификатам. Запрос перенаправляется по url-адресу по умолчанию соответствующего приложения.

Частный DNS, связанный с виртуальной сетью , перенаправит этот запрос на IP-адрес ILB. Затем App Service Environment пересылает запрос в запрошенную службу приложений. Любая связь HTTP в App Service Environment приложениях проходит через частный DNS. Необходимо настроить прослушиватель, внутренний пул, правило маршрутизации и параметры HTTP в шлюзе приложений для каждого приложения App Service Environment.

Просмотрите файлы appgw.bicep и dns.bicep, чтобы узнать, как эти конфигурации позволяют нескольким сайтам. Веб-приложение testapp — это пустое приложение, созданное для демонстрации этой конфигурации.

Сведения о сценарии

App Service — это решение как услуга (PaaS), в котором размещаются различные приложения на Azure, включая веб-приложения, приложения API, функции и мобильные приложения. Вы можете использовать App Service Environment для развертывания приложений службы приложений в подсети в собственной виртуальной сети Azure. Этот подход обеспечивает изолированную, высокомасштабируемую и выделенную среду для облачных рабочих нагрузок.

Соображения

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

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

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

App Service Environment (среда службы приложений)

Внутренняя App Service Environment находится в корпоративной виртуальной сети и скрыта от общедоступного Интернета. Он позволяет защитить внутренние службы, такие как веб-API и функции, на уровне сети. Доступ к любому App Service Environment приложению с конечной точкой HTTP можно получить через ILB из виртуальной сети. Шлюз приложений перенаправит запросы к веб-приложению через подсистему балансировки нагрузки. Веб-приложение проходит через подсистему балансировки нагрузки для доступа к API. Критически важные компоненты серверной части, такие как API и функция, не могут быть доступны из общедоступного Интернета.

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

Application Gateway

Шлюз приложений может использовать ПРОТОКОЛ TLS или SSL для шифрования и защиты всего трафика из веб-браузеров. Шифрование можно настроить двумя способами:

Шифрование завершается на шлюзе: Для этого метода серверные пулы настроены для HTTP. Шифрование останавливается на шлюзе, а трафик между шлюзом и службой приложений незашифровывается. Шифрование является интенсивным ЦП, поэтому незашифрованный трафик в серверной части повышает производительность и позволяет упростить управление сертификатами. Такой подход обеспечивает умеренный уровень безопасности, так как конфигурация сети защищает серверную часть.
Сквозное шифрование: В некоторых сценариях с определенными требованиями к безопасности или соответствию трафик может быть зашифрован между шлюзом и приложением. Эта конфигурация использует подключения HTTPS и требует сертификатов в серверном пуле.

Эта эталонная реализация использует самозаверяемые сертификаты для Шлюз приложений. Для рабочего кода используйте сертификат, выданный центром сертификации (ЦС).

Список поддерживаемых типов сертификатов см. в разделе "Сертификаты", поддерживаемые для завершения TLS.
Сведения о создании шифрования, завершаемого шлюзом, см. в разделе Настройка шлюза приложений с завершением TLS с помощью портала Azure.

В следующем примере из appgw.bicep показано, как программным способом настроить прослушиватели HTTP.

httpListeners: [for item in appgwApplications: {
name: '${appgwListenerName}${item.name}'
properties: {
  frontendIPConfiguration: {
    id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
  }
  frontendPort: {
    id: '${appgwId}/frontendPorts/port_443'
  }
  protocol: 'Https'
  sslCertificate: {
    id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
  }
  hostName: item.hostName
  requireServerNameIndication: true
}
}]

Эталонная реализация демонстрирует сквозное шифрование трафика между шлюзом приложений и веб-приложениями в App Service Environment. Он использует SSL-сертификаты по умолчанию. Серверные пулы в этой реализации настроены для перенаправления трафика HTTPS. Они также переопределяют имя хоста, используя имена доменов по умолчанию, связанные с веб-приложениями. Шлюз приложений доверяет SSL-сертификатам по умолчанию, так как корпорация Майкрософт выдает их. Дополнительные сведения см. в разделе "Настройка службы приложений" с помощью шлюза приложений. В следующем примере appgw.bicep показано, как эталонная реализация настраивает этот подход.

backendHttpSettingsCollection: [for item in appgwApplications: {
name: '${appgwHttpSettingsName}${item.name}'
properties: {
  port: 443
  protocol: 'Https'
  cookieBasedAffinity: 'Disabled'
  pickHostNameFromBackendAddress: true
  requestTimeout: 20
  probe: {
    id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
  }
}
}]

Замечание

Параметр pickHostNameFromBackendAddress переопределяет заголовок HTTP Host с внутренним адресом. Такой подход может привести к проблемам с файлами cookie, URL-адресами перенаправления и сходством сеансов. Дополнительные сведения о последствиях и альтернативных конфигурациях см. в разделе "Сохранение исходного имени узла HTTP".

Брандмауэр веб-приложений

Web Application Firewall на шлюзе приложений защищает веб-приложения от вредоносных атак, таких как внедрение SQL. Он также интегрируется с Azure Monitor для мониторинга атак с помощью журнала в режиме реального времени. Чтобы включить Web Application Firewall, необходимо настройку шлюза в соответствии с требованиями. Эталонная реализация включает WAF программным способом в appgw.bicep файле с помощью следующего кода.

webApplicationFirewallConfiguration: {
  enabled: true
  firewallMode: 'Detection'
  ruleSetType: 'OWASP'
  ruleSetVersion: '3.2'
}

Virtual Network

Можно ассоциировать NSG с одной или несколькими подсетями в виртуальной сети. Эти группы определяют правила безопасности, которые позволяют или запрещают поток трафика между различными Azure ресурсами. Эта архитектура связывает отдельную группу безопасности сети (NSG) для каждой подсети, что позволяет точно настраивать правила в зависимости от служб, находящихся в этой подсети.

Конфигурация NSG подсети App Service Environment находится в файле ase.bicep.
Конфигурация NSG (группы безопасности сети) для подсети шлюза приложений находится в файле appgw.bicep.

Обе конфигурации используют ресурс "type": "Microsoft.Network/networkSecurityGroups".

Частные конечные точки Private обеспечивают подключение усиленной безопасности между клиентами и службами Azure через частную сеть. Они предоставляют частный IP-адрес для службы Azure, которая обеспечивает расширенный трафик безопасности к ресурсу Azure Private Link. Платформа проверяет сетевые подключения и разрешает только подключения, предназначенные для указанного ресурса Private Link.

Частные конечные точки поддерживают такие политики сети, как группы безопасности сети (NSG), маршруты, определяемые пользователем (UDR), и группы безопасности приложений. Чтобы повысить безопасность, включите частные конечные точки для любой службы Azure, поддерживающей их. Чтобы защитить службу в виртуальной сети, отключите общедоступный доступ, чтобы заблокировать доступ из общедоступного Интернета. Эта архитектура настраивает частные конечные точки для служб, поддерживающих ее, включая Service Bus, базу данных SQL, Key Vault и Azure Cosmos DB. Конфигурацию можно просмотреть в privatendpoints.bicep.

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

Azure Firewall

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

Дополнительные сведения см. в статье Настройка брандмауэра с использованием сетевой конфигурации среды App Service. Брандмауэр отслеживает и управляет трафиком, который не проходит через частные конечные точки и таблицу маршрутов виртуальной сети.

Microsoft Entra ID

Microsoft Entra ID предоставляет функции безопасности для проверки подлинности приложений и авторизации доступа к ресурсам. В этой эталонной архитектуре используются два ключевых компонента Microsoft Entra ID: управляемые удостоверения и управление доступом на основе ролей Azure (Azure RBAC).

В облачных приложениях необходимо защитить учетные данные, необходимые для проверки подлинности в облачных службах. В идеале учетные данные никогда не должны отображаться на рабочих станциях разработчиков или в системе управления версиями. Key Vault безопасно хранит учетные данные и секреты, но приложение должно пройти аутентификацию в Key Vault для того, чтобы получить их. Управляемые удостоверения для ресурсов Azure предоставляют службам Azure автоматически управляемую идентичность в Microsoft Entra ID. Это удостоверение можно использовать для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra, включая Key Vault без учетных данных в приложении.

Azure RBAC управляет доступом к ресурсам Azure путем определения следующих условий:

Какая сущность имеет доступ, например пользователь, управляемое удостоверение или субъект безопасности
Какой тип доступа у него есть, например владелец, участник, читатель или администратор
Область доступа, например ресурс, группа ресурсов, подписка или группа управления

Вы можете обеспечить безопасный доступ к приложениям App Service Environment, строго контролируя необходимую роль и тип доступа для каждого приложения. Такой подход позволяет нескольким приложениям развертываться в одной App Service Environment из разных команд разработки. Например, одна команда может обрабатывать внешний интерфейс, и одна команда может обрабатывать серверную часть. Azure RBAC может ограничить доступ каждой команды к приложениям, над которыми они работают. Сведения о создании ролей, подходящих для вашей организации, см. в разделе Azure пользовательские роли.

Хранилище ключей

Некоторые службы поддерживают управляемые удостоверения и используют Azure RBAC для настройки разрешений для приложения. Например, см. встроенные роли Service Bus и Azure RBAC в Azure Cosmos DB. Чтобы предоставить эти разрешения, необходимо иметь доступ администратора доступа пользователей к подписке. Роль контрибьютора может разворачивать эти службы. Чтобы позволить более широкой команде разработчиков запускать сценарии развертывания, можно использовать собственный контроль доступа, который предоставляет каждая служба.

Для Service Bus используйте общедоступные ключи доступа.
Для Azure Cosmos DB используйте keys.

Если рабочая нагрузка требует доступа на основе служб, сохраните предварительно согласованные ключи в Key Vault. Доступ к хранилищу через управляемую учетную запись веб-приложения.

Приложения получают доступ к секретам, хранящимся в Key Vault. Они ссылаются на пару Key Vault ключей и значений. Файл sites.bicep определяет конфигурацию. Приложение для голосования использует следующий код.

properties: {
  enabled: true
  hostingEnvironmentProfile: {
    id: aseId
  }
  serverFarmId: votingWebPlanName.id
  siteConfig: {
    appSettings: [
      {
        name: 'ASecret'
        value: '@Microsoft.KeyVault(SecretUri=${applicationKeyVault::secretName.secretUriWithVersion})'
      }
    ]
  }
}

Оптимизация затрат

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

Используйте калькулятор цен Azure для оценки затрат. Дополнительные сведения см. в разделе "Оптимизация затрат" в Well-Architected Framework. Чтобы сэкономить деньги, зарезервированные экземпляры Azure предоставляют планы на один год или три года для многих ресурсов Azure.

Рассмотрим следующие факторы затрат для некоторых ключевых служб в этой архитектуре.

App Service Environment версии 3

Служба приложений имеет различные варианты ценообразования. App Service Environment развертывается с помощью плана обслуживания изолированной версии 2. Этот план включает несколько вариантов для размеров ЦП от I1v2 до I6v2. Эта эталонная реализация использует три экземпляра I1v2.

Application Gateway

Шлюз приложений имеет различные варианты ценообразования. Эта реализация использует шлюз приложений уровня "Стандартный" версии 2 и межсетевой экран веб-приложений версии 2, которые поддерживают автомасштабирование и зональную избыточность. Дополнительные сведения см. в разделе Scale Application Gateway версии 2 и Web Application Firewall версии 2.

Azure Управляемый Redis

Azure Управляемый Redis имеет различные варианты ценообразования.

Другие зависимости

Другие службы, которые помогают защитить App Service Environment также имеют несколько вариантов ценообразования:

Операционное превосходство

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

Скрипты развертывания в этой эталонной архитектуре развертывают App Service Environment, другие службы и приложения внутри App Service Environment. После развертывания этих приложений ваше предприятие может запланировать CI/CD для обслуживания приложений и обновлений. В этом разделе описаны распространенные методы, которые разработчики используют для CI/CD приложений App Service Environment.

Приложения можно развертывать в внутренней App Service Environment только из виртуальной сети. Используйте один из следующих методов для развертывания приложений App Service Environment:

Используйте виртуальную машину в виртуальной сети. Создайте виртуальную машину в виртуальной сети App Service Environment с помощью необходимых средств для развертывания. Чтобы открыть подключение RDP к виртуальной машине, используйте конфигурацию NSG. Скопируйте артефакты кода на виртуальную машину, соберите их и разверните в подсети App Service Environment. Этот метод хорошо подходит для настройки начальной среды разработки сборки и тестирования. Не используйте этот метод для рабочей среды, так как он не может масштабироваться в соответствии с требуемой пропускной способностью развертывания.
Используйте VPN-подключение типа "точка — сеть" из локальной рабочей станции. Расширьте виртуальную сеть App Service Environment до компьютера разработки. Развертывание с локальной рабочей станции. Этот метод также хорошо подходит для начальной среды разработки, но не подходит для рабочей среды.
Используйте Azure Pipelines. Реализуйте полный конвейер CI/CD, который заканчивается агентом, расположенным в виртуальной сети. Этот метод подходит для рабочих сред, требующих высокой пропускной способности развертывания. Конвейер сборки остается полностью вне виртуальной сети. Конвейер развертывания копирует встроенные объекты в агент сборки в виртуальной сети, а затем развертывается в подсети App Service Environment. Дополнительные сведения см. в разделе самостоятельно размещенные агенты Windows.

Мы рекомендуем использовать Azure Pipelines или другое средство CI/CD для рабочих сред. Файл voting-data-app.yml реализует конвейер CI/CD для веб-приложения в этой эталонной реализации. Аналогичные скрипты CI/CD поддерживают веб-API.

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

Динамически создайте агент сборки. Создайте агент сборки в конвейере операций разработки (DevOps) и разорвите его после завершения развертывания. Этот подход добавляет еще один шаг для DevOps, но упрощает обслуживание виртуальных машин.
Используйте контейнеры. Используйте контейнеры в качестве агентов сборки вместо виртуальных машин.
Развертывание без агента. Полностью избегайте использования агентов сборки, выполняя развертывание из zip-файла, расположенного вне виртуальной сети, обычно в облачной учетной записи хранения. App Service Environment и конвейер должны иметь доступ к учетной записи хранилища. Конец конвейера выпуска может поместить zip-файл в хранилище блобов. Затем среда App Service Environment может подхватить его и развернуть.

Этот подход включает следующие ограничения:
- Этот метод отключает DevOps от фактического процесса развертывания, что затрудняет мониторинг и трассировку проблем развертывания.
- В заблокированной среде с защищенным трафиком может потребоваться обновить правила доступа для zippped-файла в хранилище.
- Для развертывания из ZIP-файла необходимо установить определенные расширения и средства на App Service Environment.
Дополнительные сведения о методах развертывания приложений см. в разделе "Запуск приложения в службе приложений".

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки конструкции для эффективности производительности.

Разработка масштабируемых приложений

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

Автоматическое масштабирование шлюза приложений

Шлюз приложений поддерживает автомасштабирование. Эта функция позволяет шлюзу приложений увеличивать или уменьшать масштаб на основе шаблонов нагрузки трафика. Эталонная архитектура настраивает autoscaleConfiguration в файле appgw.bicep для масштабирования от 0 до 10 дополнительных экземпляров. Дополнительные сведения см. в разделе Scale Application Gateway и Web Application Firewall.

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

Чтобы развернуть эталонную реализацию для этой архитектуры, см. GitHub readme и следуйте скрипту для стандартного развертывания.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

Dhanashri Kshirsagar | Старший менеджер проекта по контенту

Другие участники:

Deep Bhattacharya | Архитектор облачных решений
Сухас Рао | Архитектор облачных решений

Чтобы просмотреть закрытые профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

Развертывание корпоративного уровня с высокой доступностью, использующее App Service Environment

Обратная связь

Были ли сведения на этой странице полезными?

Поделиться через

Корпоративное развертывание, использующее App Service Environment

Architecture

Рабочий процесс

Components

Конфигурация с несколькими сайтами

Сведения о сценарии

Соображения

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

App Service Environment (среда службы приложений)

Application Gateway

Брандмауэр веб-приложений

Virtual Network

Azure Firewall

Microsoft Entra ID

Хранилище ключей

Оптимизация затрат

App Service Environment версии 3

Application Gateway

Azure Управляемый Redis

Другие зависимости

Операционное превосходство

Эффективность производительности

Разработка масштабируемых приложений

Автоматическое масштабирование шлюза приложений

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

Соавторы

Дальнейшие шаги

Связанный ресурс

Обратная связь