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

Приложения-контейнеры Azure

Azure Cosmos DB

Служебная шина Azure

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

Пример рабочей нагрузки — это контейнерное приложение микрослужб. Она повторно использует ту же рабочую нагрузку, определенную в архитектуре микрослужб в службе Azure Kubernetes (AKS). Эта архитектура переносит рабочую нагрузку в Container Apps, используя их в качестве платформы приложений.

Это важно

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

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

Совет

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

Архитектура

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

Службы, которые разделяют одну и ту же среду, получают следующие преимущества:

Внутреннее обнаружение входящего трафика и службы
Одна рабочая область Log Analytics для ведения журнала во время выполнения
Безопасный метод управления секретами и сертификатами

Поток данных

Служба приема: Получает клиентские запросы, буферизирует их, а затем публикует их в служебной шине Azure. Это единственная точка доступа в нагрузку приложения.
Служба рабочего процесса: Обрабатывает сообщения из Service Bus и перенаправляет их в базовые микрослужбы.
Служба пакетов: управляет пакетами. Служба поддерживает собственное состояние в Azure Cosmos DB.
Служба планировщика дронов: планирует беспилотные летательные аппараты и отслеживает беспилотные летательные аппараты в полете. Служба поддерживает собственное состояние в Azure Cosmos DB.
Служба доставки: Управляет запланированными или транзитными поставками. Служба поддерживает собственное состояние в Azure Managed Redis.
Извлечение секретов: Так как это существующая рабочая нагрузка, для получения секретов среды выполнения доступ к Azure Key Vault получают только некоторые компоненты. Другие службы получают эти секреты из среды Container Apps.
Журналы и метрики: Среда и все приложения контейнеров генерируют журналы и метрики, которые функции Azure Monitor собирают и визуализируют.
Образы контейнеров: Образы контейнеров извлекаются из существующего реестра контейнеров Azure, который ранее использовался для AKS и развернут в среде приложений контейнеров.

Компоненты

Рабочая нагрузка использует следующие службы Azure в координации друг с другом:

Контейнерные приложения — это бессерверная платформа контейнеров, которая упрощает оркестрацию и управление контейнерами. В этой архитектуре контейнерные приложения служат основной платформой размещения для всех микрослужб.

Следующие функции заменяют многие возможности предыдущей архитектуры AKS:
- Встроенное обнаружение служб
- Управляемые конечные точки HTTP и HTTP/2
- Встроенная балансировка нагрузки
- Ведение журналов и мониторинг
- Автомасштабирование на основе http-трафика или событий на основе автомасштабирования на основе Kubernetes (KEDA)
- Обновления приложений и управление версиями
Реестр контейнеров — это управляемая служба реестра для хранения образов частных контейнеров и управления ими. В этой архитектуре это источник всех образов контейнеров, развернутых в среде Container Apps. Реестр тот же, что используется в реализации AKS.
Azure Cosmos DB — это глобально распределенная служба базы данных с несколькими моделями. В этой архитектуре служба планировщика дронов использует Azure Cosmos DB в качестве хранилища данных.
Azure DocumentDB — это полностью управляемая служба базы данных, совместимая с MongoDB для создания современных приложений. В этой архитектуре служба пакетов использует Azure DocumentDB в качестве хранилища данных.
Служебная шина — это облачная служба обмена сообщениями, которая обеспечивает асинхронную связь и гибридную интеграцию. В этой архитектуре он обрабатывает асинхронные сообщения между службой приема и микрослужбой рабочих процессов на основе задач. Остальные службы в существующем приложении разработаны таким образом, чтобы другие службы могли вызывать их с помощью HTTP-запросов.
Azure Redis Managed — это служба кэширования в памяти. В этой архитектуре уменьшается задержка и улучшается пропускная способность для часто используемых данных доставки дронов.
Key Vault — это облачная служба для безопасного хранения и доступа к секретам, таким как ключи API, пароли и сертификаты. В этой архитектуре планировщик дронов и службы доставки используют управляемые удостоверения, назначенные пользователем, для проверки подлинности в Key Vault и получения секретов, необходимых для требований среды выполнения.
Azure Monitor — это комплексное решение для мониторинга, которое собирает и анализирует данные телеметрии. В этой архитектуре он собирает и сохраняет метрики и журналы из всех компонентов приложения через рабочую область Log Analytics. Эти данные используются для мониторинга приложения, настройки оповещений и панелей мониторинга и выполнения анализа первопричин сбоев.
- Application Insights — это служба управления производительностью приложений, которая предоставляет расширяемые возможности мониторинга. В этой архитектуре каждая служба инструментируется с помощью пакета SDK Application Insights для мониторинга производительности приложений.

Альтернативные варианты

Расширенная архитектура микрослужб AKS описывает альтернативный сценарий этого примера, использующего Kubernetes.

Подробности сценария

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

Fabrikam, Inc., вымышленная компания, реализует рабочую нагрузку доставки дронов, где пользователи запрашивают беспилотник, чтобы забрать товары для доставки. Когда клиент планирует пикап, в внутренней системе назначается беспилотный летательный аппарат и уведомляет пользователя о предполагаемом времени сбора.

Приложение микрослужб было развернуто в кластере AKS. Но команда Fabrikam не воспользовались расширенными или платформенными функциями AKS. Они переносили приложение в контейнерные приложения, что позволило им выполнить следующие действия:

При перемещении приложения из AKS в контейнерные приложения применяются минимальные изменения кода. Изменения в коде касались библиотек наблюдаемости, которые обогащают журналы и метрики информацией об узлах Kubernetes, что не актуально в новой среде.
Развертывание инфраструктуры и рабочей нагрузки с помощью шаблонов Bicep: для развертывания контейнеров приложений необходимы манифесты YAML Kubernetes.
Опубликовать приложение через управляемый вход. Встроенная поддержка внешнего контроллера ingress на базе HTTPS для предоставления службы приема устранила необходимость настраивать собственный контроллер ingress.
Извлечение образов контейнеров из реестра контейнеров. Контейнерные приложения совместимы с любым базовым образом Linux, хранящимся в любом доступном репозитории.
Используйте функцию редакции для поддержки потребностей жизненного цикла приложения. Они могут выполнять несколько версий конкретного приложения-контейнера и разделить трафик между ними для сценариев тестирования A/B или синего или зеленого развертывания.
Используйте управляемое удостоверение для проверки подлинности с помощью Key Vault и реестра контейнеров.

Потенциальные варианты использования

Разверните приложение на основе микрослужб браунфилда в платформу как службу (PaaS), чтобы упростить управление и избежать сложности запуска оркестратора контейнеров. Рабочая нагрузка браунфилда экономила деньги с помощью этой архитектуры в ходе развертывания Kubernetes по следующим причинам:

Выбор профилей рабочей нагрузки
Меньше времени на выполнение задач второй фазы для операционной команды.
Возможность избежать чрезмерного выделения ресурсов

Замечание

Не все рабочие нагрузки обеспечивают такую экономию затрат.

Рассмотрим другие распространенные способы использования контейнерных приложений:

Запустите контейнерные рабочие нагрузки на платформе без серверов и на основе потребления.
Автомасштабирование приложений на основе трафика HTTP или HTTPS и триггеров на основе событий, поддерживаемых KEDA.
Свести к минимуму затраты на обслуживание контейнерных приложений.
Развертывание конечных точек API.
Поддержка приложений для фоновой обработки.
Обработка событий-ориентированной обработки.

Optimizations

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

Улучшение управления секретами

Рабочая нагрузка использует гибридный подход для управления секретами. Управляемые удостоверения применяются только к службам, в которых переключение на управляемые удостоверения не требует изменений кода. Планировщик дронов и службы доставки используют управляемые удостоверения, назначаемые пользователем, вместе с Key Vault для доступа к сохраненным секретам. Остальные службы требуют внесения изменений в код для внедрения управляемых удостоверений, вследствие чего они используют секреты, предоставляемые средой "Приложения контейнеров".

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

Избегайте проектов, требующих единого режима редакции

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

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

Рассмотрите возможность работы на основе заданий

Служба рабочих процессов реализуется в качестве долго работающего приложения, работающего в контейнере. Но он также может выполняться как задание в контейнерных приложениях. Задание — это контейнерное приложение, которое запускается по запросу, выполняется до завершения на основе доступной работы, а затем завершает работу и освобождает ресурсы. Задания могут быть более экономичными, чем непрерывно работающие реплики. Перенос службы для выполнения как задание для Container Apps в зависимости от работы, доступной в очереди, может быть практическим вариантом. Он зависит от типичного объема очереди и от того, насколько ограничена, параллелизуема и оптимизирована написана служба рабочих процессов. Экспериментируйте и проверьте, чтобы определить оптимальный подход.

Контроль входа

Рабочая нагрузка использует встроенную функцию внешнего входа контейнерных приложений для предоставления службы ввода данных. Подход к управлению входящего трафика не обеспечивает возможность полностью разместить точку входящего трафика за брандмауэром веб-приложения (WAF) или включить ее в планы защиты от атак DDoS Azure. Для защиты всех рабочих нагрузок, подключенных к Интернету, необходимо использовать WAF. Чтобы достичь этой конфигурации в среде приложений контейнеров, необходимо отключить встроенный общедоступный входящий трафик и добавить шлюз приложений или Azure Front Door.

Замечание

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

Модернизация с помощью Dapr

Вы можете дополнительно модернизировать рабочую нагрузку, интегрируя с распределенной средой выполнения приложений (Dapr). Он добавляет абстракцию между кодом рабочей нагрузки и хранилищами состояний, системами обмена сообщениями и механизмами обнаружения служб. Дополнительные сведения см. в статье "Развертывание микрослужб с помощью приложений контейнеров и Dapr". Если рабочая нагрузка в Kubernetes уже использует Dapr или распространенные масштабировщики KEDA, миграция в Container Apps часто довольно простая и сохранит эту функциональность.

Миграция к аутентификации и авторизации пользователей

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

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

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

Надежность

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

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

Исправления помогают развертывать обновления приложений с нулевым временем простоя. Вы можете использовать ревизии для управления развертыванием обновлений приложений и распределения трафика между ревизиями для поддержки сине-зеленого развертывания и тестирования A/B.
Благодаря функциям наблюдаемости приложений-контейнеров вы можете ознакомиться с компонентами, которые выполняются в среде. Контейнерные приложения интегрируются с Application Insights и Log Analytics. Эти данные используются для отслеживания операций и настройки оповещений на основе метрик и событий в рамках системы наблюдаемости.

Мониторинг производительности помогает оценить приложение под нагрузкой. Метрики и журналы предоставляют данные для распознавания тенденций, исследования сбоев и выполнения анализа первопричин.
Используйте пробы работоспособности и готовности для обработки медленно запускаемых контейнеров и избегайте отправки трафика до их готовности. Реализация Kubernetes включает эти конечные точки. Продолжайте использовать их, если они предоставляют эффективные сигналы.
Когда служба неожиданно завершает работу, контейнерные приложения автоматически перезапускают ее. Обнаружение служб включено, чтобы служба рабочего процесса обнаружила свои подчиненные микрослужбы. Используйте политики устойчивости для обработки времени ожидания и внедрения логики разбиения цепи без необходимости дополнительного изменения кода.
Включите правила автомасштабирования для удовлетворения спроса по мере увеличения трафика и рабочих нагрузок.
Используйте динамические функции балансировки нагрузки и масштабирования контейнерных приложений для повышения доступности. Переподключите подсеть вашей среды, чтобы всегда было достаточно доступных IP-адресов для будущих реплик или заданий.
Избегайте хранения состояния непосредственно в среде Container Apps, так как все состояние теряется при завершении работы реплики. Экспортируйте состояние в выделенное хранилище состояния для каждой микрослужбы. Эта архитектура распределяет состояние между тремя различными хранилищами: Управляемый Redis Azure, Azure Cosmos DB для NoSQL и Azure DocumentDB.
Разверните все ресурсы, включая контейнерные приложения, с помощью топологии с несколькими зонами. Дополнительные сведения см. в разделе "Поддержка зоны доступности" в приложениях контейнеров.

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

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

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

Секреты

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

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

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

Так как эта архитектура использует встроенную функцию входящего трафика, это решение не обеспечивает возможность полностью разместить точку входящего трафика за WAF или включить ее в планы защиты от атак DDoS. Защитите все рабочие нагрузки, обращенные к вебу, с помощью брандмауэра веб-приложений. Дополнительные сведения об улучшениях входящего трафика см. в разделе "Реализация элемента управления входящего трафика".
При создании среды можно предоставить пользовательскую виртуальную сеть. В противном случае корпорация Майкрософт автоматически создает виртуальную сеть и управляет ею. Вы не можете управлять этой управляемой корпорацией Майкрософт виртуальной сетью, например путем добавления групп безопасности сети (NSG) или принудительного туннелирования трафика в брандмауэр исходящего трафика. В примере используется автоматически созданная виртуальная сеть, но настраиваемая виртуальная сеть улучшает управление безопасностью. Настраиваемая сеть позволяет применять NSG и маршрутизацию на основе пользовательских маршрутов (UDR) через брандмауэр Azure.

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

Удостоверения рабочей нагрузки

Контейнерные приложения поддерживают управляемые удостоверения Microsoft Entra, которые позволяют приложению проходить проверку подлинности в других ресурсах, защищенных идентификатором Microsoft Entra, например Key Vault, без управления учетными данными в приложении контейнера. Приложение-контейнер может использовать системно назначаемые идентификации, пользовательски назначаемые идентификации или оба типа. Для служб, не поддерживающих проверку подлинности идентификатора Microsoft Entra, сохраните секреты в Key Vault и используйте управляемое удостоверение для доступа к секретам.
Используйте одно выделенное управляемое удостоверение, назначаемое пользователем, для доступа к реестру контейнеров. Контейнерные приложения поддерживают использование другой управляемой учётной записи для выполнения рабочих нагрузок, а не для доступа к реестру контейнеров. Этот подход обеспечивает детализированный контроль доступа. Если в вашей рабочей нагрузке несколько сред контейнерных приложений, не используйте один и тот же идентификатор между экземплярами.
Используйте системно назначаемые управляемые идентичности для идентичностей рабочей нагрузки, чтобы связать жизненный цикл идентичности с жизненным циклом компонента рабочей нагрузки.

Дополнительные рекомендации по безопасности

Реализация Kubernetes этой рабочей нагрузки обеспечивает защиту с помощью возможностей Microsoft Defender для контейнеров. В этой архитектуре Defender для контейнеров оценивает уязвимость только контейнеров в реестре контейнеров. Defender для контейнеров не обеспечивает защиту среды выполнения для контейнерных приложений. Оцените дополнение к решениям безопасности, отличных от Майкрософт, если защита среды выполнения является обязательным требованием.
Не запускайте рабочую нагрузку в общей среде контейнерных приложений. Сегментируйте его из других рабочих нагрузок или компонентов, которые не нуждаются в доступе к этим микрослужбам. Создание отдельных сред контейнерных приложений. Приложения и задания, выполняемые в среде контейнерных приложений, могут обнаруживать и получать доступ к любой службе, которая выполняется в среде с включенной внутренней маршрутизацией.

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

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

Ознакомьтесь с примером оценки цен для рабочей нагрузки. Используйте калькулятор цен Azure. Конфигурации различаются, поэтому настройте его в соответствии с вашим сценарием.
В этом сценарии Azure Cosmos DB, Azure Managed Redis и Service Bus Premium являются основными драйверами затрат.
Для контейнеров, которые обычно используют низкий объем ЦП и памяти, сначала оцените профиль рабочей нагрузки потребления. Оцените стоимость профиля потребления на основе использования, чтобы собрать базовые данные о затратах и оценить другие профили. Например, можно использовать выделенный профиль рабочей нагрузки для компонентов с высокой прогнозируемой и стабильной загрузкой и совместно использовать выделенные узлы. Для оптимизации затрат следует поддерживать количество узлов, кратное трем, для каждого специального профиля, чтобы обеспечить достаточное распределение вычислительных узлов и распределение реплик между зонами доступности.
Исключите затраты на вычисления в периоды бездействия, гарантируя, что компоненты могут масштабироваться до нуля, чтобы платить только при необходимости. Этот подход сокращает расходы на приложения, имеющие изменяющееся или нерегулярное использование. Проверки состояния обычно предотвращают полное масштабирование до нуля. В архитектуре можно повторно использовать службу рабочих процессов в качестве задания, чтобы воспользоваться преимуществами масштабирования до нуля в периоды простоя. Этот подход подходит хорошо с рабочими нагрузками, которые могут использовать план потребления.
Чтобы избежать сетевых расходов между регионами, разместите все компоненты, такие как хранилища состояний и реестр контейнеров, в одном регионе.

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

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

Используйте GitHub Actions или интеграцию Azure Pipelines для настройки конвейеров автоматической непрерывной интеграции и непрерывного развертывания (CI/CD).
Используйте режим с несколькими редакциями с разделением трафика для тестирования изменений в коде рабочей нагрузки и правилах масштабирования.
Интеграция с Application Insights и Log Analytics для предоставления аналитических сведений о рабочей нагрузке. Используйте ту же рабочую область Log Analytics, что и остальные компоненты рабочей нагрузки, чтобы сохранить все аналитические сведения о рабочей нагрузке вместе.
Используйте инфраструктуру как код (IaC), например, Bicep или Terraform, для управления всеми инфраструктурными развертываниями. К развертываниям относятся среда приложений контейнеров, реестр контейнеров и хранилища состояний микрослужбы. Отделяйте конвейеры развертывания микрослужб от конвейеров инфраструктуры, так как они часто не используют аналогичный жизненный цикл. Декларативный конвейер для инфраструктуры Azure должен развертывать все ресурсы, кроме ресурсов контейнерных приложений.
Используйте императивный подход к созданию, обновлению и удалению приложений контейнеров из среды. Особенно важно, если вы динамически настраиваете логику переключения трафика между редакциями. Используйте действие GitHub или задачу Azure Pipelines в рабочих процессах развертывания. Этот императивный подход можно использовать на основе определений приложений YAML . Чтобы свести к минимуму сбои проверки работоспособности, всегда убедитесь, что конвейер заполняет реестр контейнеров новым образом контейнера перед развертыванием приложения контейнера.

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

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

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

Рабочая нагрузка распределяется между несколькими приложениями микрослужб.
Каждая микрослужба является независимой и не обменивается состояниями с другими микрослужбами, что обеспечивает независимое масштабирование.
Используйте задания приложений контейнеров для ограниченных запусков процессов, чтобы реализовать временные среды выполнения и уменьшить потребление ресурсов для неактивных служб. Оцените последствия для производительности от масштабирования заданий и поддержания компонентов в теплом, готовом состоянии.
Автомасштабирование включено. Предпочитайте масштабирование на основе событий, а не на основе метрик, где это возможно. Например, служба рабочего процесса, если она разработана для поддержки, может масштабироваться на основе глубины очереди Service Bus. Автомасштабирование по умолчанию основано на HTTP-запросах. Во время переплатформирования важно начать с того же подхода масштабирования, а затем оценить оптимизации масштабирования позже.
Запросы динамически распределяются на доступные реплики версии.
Метрики, включая использование ЦП, памяти, сведения о пропускной способности и хранилище, доступны через Azure Monitor.

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

Выполните действия, описанные в README.md в репозитории примеров сценариев для приложений контейнеров.

Соавторы

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

Участники:

Джулиен Стреблер | Архитектор облачных решений
Стив Караваджал | Архитектор облачных решений
Саймон Курц | Архитектор облачных решений

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

Документация по контейнерным приложениям

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

Была ли эта страница полезна?