В этой статье описывается, как развертывать критически важные веб-приложения с помощью службы приложение Azure. Архитектура использует шаблон надежного веб-приложения в качестве отправной точки. Используйте эту архитектуру, если у вас есть устаревшая рабочая нагрузка и требуется внедрить службы paaS.
Шаблон надежных веб-приложений для .NET предоставляет рекомендации по обновлению или переформировки веб-приложений, которые вы перемещаете в облако, минимизируя необходимые изменения кода и предназначенные для цели уровня обслуживания (SLO) 99,9%. Критически важные рабочие нагрузки имеют высокий уровень надежности и доступности. Чтобы достичь уровня SLO от 99,95%, 99,99%, или выше, необходимо применить дополнительные критически важные шаблоны проектирования и операционные ограничения. В этой статье описываются ключевые технические области, а также способы реализации и внедрения критически важных методик проектирования.
Примечание.
Руководство, приведенное в этой статье, основано на методологии проектирования и рекомендациях в серии критически важных рабочих нагрузок для платформы Well-Architected Framework.
В следующих разделах описано:
- Просмотрите существующую рабочую нагрузку, чтобы понять ее компоненты, потоки пользователей и системных потоков, а также требования к доступности и масштабируемости.
- Разработка и реализация архитектуры единиц масштабирования для оптимизации сквозной масштабируемости с помощью секционализации и стандартизации процесса добавления и удаления емкости.
- Реализуйте единицы без отслеживания состояния, временные единицы масштабирования или метки развертывания, чтобы обеспечить масштабируемость и развертывание без простоя.
- Определите, можно ли разделить рабочую нагрузку на компоненты, чтобы подготовиться к масштабируемости. Для масштабируемости и развязывания потоков требуются отдельные компоненты.
- Подготовьтесь к глобальному распределению , развернув рабочую нагрузку в нескольких регионах Azure, чтобы повысить близость к клиенту и подготовиться к потенциальным региональным сбоям.
- Отделяйте компоненты и реализуйте архитектуру на основе событий.
Архитектура
На следующей схеме применяются предыдущие рекомендации к шаблону надежного веб-приложения.
Скачайте файл Visio для этой архитектуры.
Красный прямоугольник представляет единицу масштабирования со службами, масштабируемыми вместе. Чтобы эффективно масштабировать их вместе, оптимизируйте размер каждой службы, номер SKU и доступные IP-адреса. Например, максимальное количество запросов, которые Конфигурация приложений Azure обслуживает, сопоставляется с числом запросов в секунду, которое предоставляет единица масштабирования. При добавлении дополнительной емкости в регионе необходимо также добавить дополнительные отдельные единицы масштабирования.
Эти отдельные единицы масштабирования не имеют зависимостей и взаимодействуют только с общими службами за пределами отдельной единицы масштабирования. Вы можете протестировать независимые единицы масштабирования заранее. Чтобы избежать влияния на другие области развертывания, разверните независимые единицы масштабирования и введите вариант замены служб в новом выпуске.
Для критически важных рабочих нагрузок независимые единицы масштабирования являются временными, что оптимизирует процессы развертывания и обеспечивает масштабируемость в пределах и в разных регионах. Избегайте хранения состояния в независимых единицах масштабирования. Рекомендуется использовать Кэш Azure для Redis для хранения в единице масштабирования и хранить только критически важное состояние или данные, которые также хранятся в базе данных. Если происходит сбой единиц масштабирования или переход на другой единицу масштабирования, может возникнуть замедление или новый вход, но Кэш Azure для Redis по-прежнему выполняется.
Приложение Аналитика исключается из единицы масштабирования. Исключите службы, которые хранят или отслеживают данные. Разделите их на собственную группу ресурсов с собственным жизненным циклом.
При замене единицы масштабирования или развертывании нового, сохраняйте исторические данные и используйте один экземпляр для каждого региона.
Дополнительные сведения см. в статье "Разработка приложений критически важных рабочих нагрузок в Azure".
Компоненты
Эта архитектура использует следующие компоненты.
- Служба приложений — это платформа размещения приложений.
- Кэш Azure для Redis кэширует запросы.
- Конфигурация приложений хранит параметры конфигурации.
- Sql Azure — это серверная база данных.
- Приложение Аналитика получает данные телеметрии из приложения.
Альтернативные варианты
В шаблоне надежного веб-приложения можно:
- Вместо Служба приложений используйте Служба Azure Kubernetes (AKS). Этот вариант хорошо подходит для сложных рабочих нагрузок, имеющих большое количество микрослужб. AKS обеспечивает больший контроль над базовой инфраструктурой и позволяет выполнять сложные многоуровневые настройки.
- Контейнеризация рабочей нагрузки. Служба приложений поддерживает контейнеризацию, но в этом примере рабочая нагрузка не контейнеризирована. Используйте контейнеры для повышения надежности и переносимости.
Дополнительные сведения см. в рекомендациях по платформе приложений для критически важных рабочих нагрузок в Azure.
Выбор платформы приложений
Уровень доступности зависит от выбора и конфигурации платформы приложений. Рассмотрим следующее критически важное руководство.
- По возможности используйте зоны доступности.
- Выберите нужную службу платформы для рабочей нагрузки.
- Контейнеризация рабочей нагрузки.
Группы доступности распределяют развертывания между несколькими доменами сбоя и обновления в центре обработки данных. Зоны доступности распределяют развертывания по отдельным центрам обработки данных в регионе Azure. Зоны доступности часто задаются приоритетами, но используемая стратегия зависит от рабочей нагрузки. Например, рабочие нагрузки с учетом задержки или чата могут воспользоваться приоритетами групп доступности. Если вы распределяете рабочую нагрузку между зонами доступности, это может увеличить задержку и стоимость трафика между зонами. При использовании зон доступности убедитесь, что все службы в единицах масштабирования поддерживают их. Все службы в шаблоне надежного веб-приложения поддерживают зоны доступности.
Выбор платформы данных
Выбранная платформа базы данных влияет на общую архитектуру рабочей нагрузки, особенно поддержку активной или пассивной конфигурации платформы. В шаблоне надежного веб-приложения используется SQL Azure, который не поддерживает собственные развертывания с активными активными операциями записи в нескольких экземплярах. Поэтому уровень базы данных ограничен активной пассивной стратегией. Стратегия "активный— активный" на уровне приложения возможна, если есть только реплика только для чтения, и вы записываете только в один регион.
Скачайте файл Visio для этой архитектуры.
Несколько баз данных распространены в сложных архитектурах, таких как архитектуры микрослужб, которые имеют базу данных для каждой службы. Несколько баз данных позволяют внедрять многозначную базу данных записи, например Azure Cosmos DB, что повышает доступность и низкую задержку. Задержка между регионами может создавать ограничения. Важно учитывать нефункциональные требования и факторы, такие как согласованность, оперативность, стоимость и сложность. Включите отдельные службы для использования отдельных хранилищ данных и специализированных технологий данных для удовлетворения их уникальных требований. Дополнительные сведения см. в разделе "Рекомендации по платформе данных" для критически важных рабочих нагрузок в Azure.
Определение модели работоспособности
В сложных многоуровневых рабочих нагрузках, распределенных по нескольким центрам обработки данных и географическим регионам, необходимо определить модель работоспособности. Определите потоки пользователей и системы, укажите и понять зависимости между службами, понять, что сбои или снижение производительности для одной из служб могут повлиять на общую рабочую нагрузку, а также отслеживать и визуализировать взаимодействие с клиентом, чтобы обеспечить надлежащий мониторинг и улучшить ручной и автоматизированный действия.
На предыдущей схеме показано, как сбой или снижение одного компонента, например Конфигурация приложений, может привести к снижению производительности для клиента.
Если вы отделяете компоненты в единицах масштабирования, это позволяет прекратить отправку трафика в затронутую часть приложения, например затронутую единицу масштабирования или полный регион.
Дополнительные сведения см. в статье " Моделирование работоспособности и наблюдаемость критически важных рабочих нагрузок в Azure".
Безопасность и сеть
Существуют строгие требования к сети и безопасности для рабочих нагрузок, которые переносятся из локального корпоративного развертывания. Не все установленные локальные процессы преобразуют в облачную среду. Оцените эти требования, если они применимы в облачных средах.
Удостоверение часто является основным периметром безопасности для шаблонов на основе облака. Корпоративным клиентам могут потребоваться более существенные меры безопасности. Для решения своих требований к безопасности сети большинство служб Azure PaaS могут использовать Приватный канал Azure для реализации сети в качестве периметра безопасности. Приватный канал может гарантировать, что службы доступны только из виртуальной сети. Все службы доступны только через частные конечные точки. На следующей схеме показано, как доступна единственная общедоступная конечная точка, доступная к Интернету, — Azure Front Door.
Скачайте файл Visio для этой архитектуры.
Для настройки сети в качестве периметра безопасности необходимо использовать шаблон надежного веб-приложения:
- Приватный канал для всех служб, поддерживающих ее.
- Azure Front Door premium — единственная общедоступная конечная точка, доступная к Интернету.
- Jumpboxes для доступа к службам через Бастион Azure.
- Локальные агенты сборки, которые могут получить доступ к службам.
Еще одним общим требованием к сети для критически важных приложений является ограничение исходящего трафика, чтобы предотвратить утечку данных. Ограничение исходящего трафика путем маршрутизации брандмауэра Azure через соответствующее устройство брандмауэра и фильтрацию его с помощью устройства. Критически важная архитектура базовых показателей Azure с сетевыми элементами управления использует брандмауэр и Приватный канал.
Развертывание и тестирование
Простой, вызванный ошибочными выпусками или человеческой ошибкой, может быть проблемой для рабочей нагрузки, которая всегда должна быть доступна. Ниже приведены некоторые ключевые области, которые следует учитывать:
- Развертывания без простоя
- Эфемерные развертывания синего и зеленого цвета
- Анализ жизненного цикла отдельных компонентов и группирование их вместе
- Непрерывная проверка
Развертывания без простоя являются ключевыми для критически важных рабочих нагрузок. Рабочая нагрузка, которая должна всегда работать и работать, не может иметь период обслуживания для развертывания более новых версий. Чтобы обойти это ограничение, критически важная архитектура Azure следует шаблону развертывания без простоя. Изменения развертываются как новые единицы масштабирования или метки, которые тестируются в конце, прежде чем трафик постепенно направляется к ним. После того как весь трафик направляется на новую метку, старые метки отключаются и удаляются.
Дополнительные сведения см. в статье "Развертывание и тестирование критически важных рабочих нагрузок в Azure".
Следующие шаги
- Обучение пути. Создание критически важных рабочих нагрузок в Azure
- Проект задачи: разработка критически важного веб-приложения
- Модуль Learn: проектирование модели работоспособности для критически важной рабочей нагрузки