Шаблон надежного веб-приложения для Java

В этой статье приводятся рекомендации по реализации шаблона Reliable Web App. В этом шаблоне описывается, как переформатировать веб-приложения для миграции в облако. Он предоставляет предписательную архитектуру, код и рекомендации по настройке, которые соответствуют принципам Azure Well-Architected Framework.

Зачем использовать шаблон Надежных веб-приложений для Java?

Шаблон Reliable Web App — это набор принципов и методов реализации, определяющих способ переплатформирования веб-приложений при их переносе в облако. Он подчеркивает минимальные обновления кода, чтобы обеспечить успех в облаке. В этом руководстве используется эталонная реализация в качестве согласованного примера на протяжении всего. Он следует пути переплатформирования вымышленной компании Contoso Fiber, чтобы дать представление о бизнес-контексте для вашей собственной миграции. Прежде чем Contoso Fibre реализует шаблон Reliable Web App для Java, он работает монолитной локальной локальной системой управления учетными записями клиентов (CAMS), созданной с помощью платформы Spring Boot.

Реализация шаблона Reliable Web App

Найдите конкретные рекомендации, необходимые в следующих разделах этой статьи:

• Бизнес-контекст: согласуйте это руководство с бизнес-контекстом и научитесь определять немедленные и долгосрочные цели, которые влияют на принятие решений по переплатформированию.

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

• Руководство по коду. Реализация шаблонов проектирования повторных попыток, автоматического останова и Cache-Aside для повышения надежности и производительности веб-приложения в облаке.

• Руководство по настройке: настройка проверки подлинности и авторизации, управляемых удостоверений, управляемых удостоверений, управляемых сред, инфраструктуры как кода (IaC) и мониторинга.

Бизнес-контекст

Первым шагом в переплатформировке веб-приложения является определение бизнес-целей. Задайте непосредственные цели, такие как цели уровня обслуживания (SLOS) и целевые показатели оптимизации затрат, а также будущие цели для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру приложения в облаке. Определите целевой SLO для вашего веб-приложения, например, 99,9% времени безотказной работы. Вычислите составное соглашение об уровне обслуживания (SLA) для всех служб, влияющих на доступность веб-приложения.

Contoso Fibre хочет расширить локальное веб-приложение CAMS, чтобы достичь других регионов. Для удовлетворения повышенного спроса на веб-приложение компания устанавливает следующие цели:

• Примените недорогие изменения кода с высокой ценностью.
• Достичь целевой метрики уровня обслуживания (SLO) 99,9%.
• Внедрение методик DevOps.
• Создание сред с оптимизированными затратами.
• Повышение надежности и безопасности.

Contoso Fibre определяет, что локальная инфраструктура не является экономически эффективным решением для масштабирования приложения. Компания решает, что перенос веб-приложения CAMS в Azure является наиболее экономичным способом достижения своих непосредственных и будущих целей.

Руководство по архитектуре

Шаблон Reliable Web App содержит несколько важных архитектурных элементов. Вам нужна система доменных имен (DNS) для управления разрешением конечных точек, брандмауэром веб-приложения для блокировки вредоносного HTTP-трафика и подсистемой балансировки нагрузки для маршрутизации и защиты входящих запросов пользователей. Платформа приложений размещает код веб-приложения и вызывает внутренние службы через частные конечные точки в виртуальной сети. Средство мониторинга производительности приложений записывает метрики и журналы, которые помогут вам понять веб-приложение.

Проектирование архитектуры

Создайте инфраструктуру для поддержки метрик восстановления, таких как цель времени восстановления (RTO) и цель точки восстановления (RPO). RTO влияет на доступность и должно поддерживать SLO. Определите RPO и настройте избыточность данных для соответствия RPO.

• Выберите надежность инфраструктуры. Определите количество зон доступности и регионов, необходимых для удовлетворения требований к доступности. Добавьте зоны доступности и регионы, пока составное соглашение SLA не будет соответствовать вашей целевой норме уровня обслуживания (SLO). Шаблон Reliable Web App поддерживает несколько регионов для конфигурации "активный—активный" или "активный—пассивный". Например, эталонная реализация использует активно-пассивную конфигурацию для достижения SLO 99.9%.

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

  

  Схема, показывающая шаблон Надежных веб-приложений, расширенный для многорегионного развертывания с помощью концентратора и периферийной топологии сети. Архитектура включает в себя два региона Azure, каждый из которых содержит собственный набор ресурсов веб-приложения и внутренних служб. Запросы пользователей обрабатываются DNS и проходят через глобальный балансировщик нагрузки, который направляет трафик в основной или вторичный регион в зависимости от доступности. Каждый регион содержит брандмауэр веб-приложения и подсистему балансировки нагрузки, которая защищает и распределяет запросы на платформу веб-приложений. Веб-приложения в обоих регионах подключаются к внутренним службам, таким как базы данных и хранилище, с помощью частных конечных точек в соответствующих виртуальных сетях. Виртуальная сеть концентратора, представленная в одном регионе, содержит общие ресурсы, такие как брандмауэр сети и узел бастиона для безопасного управления виртуальными машинами. Периферийные виртуальные сети размещают приложения и службы данных и подключаются к центру для централизованной безопасности и управления. На схеме показан поток запросов пользователей, разделение границ общедоступной и частной сети, использование элементов управления безопасностью и избыточность, предоставляемая путем развертывания ресурсов в нескольких регионах.

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

Выберите нужные службы Azure

При перемещении веб-приложения в облако выберите службы Azure, которые соответствуют вашим бизнес-требованиям и соответствуют функциям локального веб-приложения. Это выравнивание помогает свести к минимуму усилия по переформировки. Например, используйте службы, которые позволяют поддерживать один и тот же движок СУБД и поддерживать существующие промежуточное ПО и фреймворки.

Перед миграцией, веб-приложение CAMS компании Contoso Fiber является размещенным локально, монолитным приложением на Java. Это приложение Spring Boot с базой данных PostgreSQL. Веб-приложение — это приложение поддержки для сотрудников, связанное с линейным бизнесом (LOB). Они используют это для управления запросами службы поддержки клиентов. Приложение сталкивается с распространенными проблемами с масштабируемостью и развертыванием функций. Эта отправная точка, наряду с бизнес-целями и соглашениями об уровне обслуживания, влияет на их выбор службы.

В следующем списке приведены рекомендации по выбору подходящих служб Azure для веб-приложения и описано, почему Contoso Fibre выбирает определенные службы:

• Платформа приложений: Используйте Службу приложений Azure в качестве платформы приложений. Contoso Fibre использует службу приложений по следующим причинам:

  • Естественное прогрессирование: Contoso Fibre развертывает JAR-файл Spring Boot на локальном сервере и хочет свести к минимуму объем перезагрузки для этой модели развертывания. Служба приложений обеспечивает надежную поддержку запуска приложений Spring Boot, что делает его подходящим вариантом. Приложения контейнеров Azure также подходят для этого приложения. Дополнительные сведения см. в разделе "Общие сведения о контейнерных приложениях" и обзоре Java для приложений контейнеров.

  • Высокий уровень обслуживания: Служба приложений обеспечивает высокий уровень обслуживания, соответствующий рабочим требованиям.

  • Сокращение затрат на управление: Служба приложений — это управляемое решение для размещения.

  • Возможность контейнеризации: Служба приложений интегрируется с реестрами частных образов контейнеров, такими как Реестр контейнеров Azure. Contoso Fibre может использовать эти реестры для контейнеризации веб-приложения в будущем.

  • Автомасштабирование: Веб-приложение может быстро увеличивать масштаб, уменьшать масштаб, выполнять внутреннее и внешнее масштабирование в зависимости от пользовательского трафика.

• Управление удостоверениями: Используйте идентификатор Microsoft Entra в качестве решения для управления удостоверениями и доступом. Contoso Fibre использует идентификатор Microsoft Entra по следующим причинам:

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

  • Масштабируемость: Идентификатор Microsoft Entra масштабируется для поддержки более крупных сценариев.

  • Элемент управления удостоверениями пользователя: Сотрудники центра обработки вызовов могут использовать существующие корпоративные удостоверения.

  • Поддержка протокола авторизации: Идентификатор Microsoft Entra поддерживает OAuth 2.0 для управляемых удостоверений.

• База данных: Используйте службу, которая позволяет сохранить тот же ядро СУБД. Используйте дерево принятия решений в хранилище данных для руководства по выбору. Contoso Fibre использует модель развертывания гибкого сервера Базы данных Azure для PostgreSQL по следующим причинам:

  • Надёжность: Гибкая модель развертывания сервера поддерживает зонально-избыточную высокую доступность в нескольких зонах доступности. Эта конфигурация поддерживает теплый резервный сервер в другой зоне доступности в одном регионе Azure. Конфигурация реплицирует данные синхронно на резервный сервер.

  • Репликация между регионами: База данных Azure для PostgreSQL предоставляет функцию реплики чтения для асинхронной репликации данных в базу данных реплики только для чтения в другом регионе.

  • Производительность: База данных Azure для PostgreSQL обеспечивает прогнозируемую производительность и интеллектуальную настройку, которая повышает производительность базы данных с помощью реальных данных об использовании.

  • Сокращение затрат на управление: Эта управляемая служба Azure сокращает обязательства по управлению.

  • Поддержка миграции: Она поддерживает миграцию баз данных из локальных баз данных PostgreSQL с одним сервером. Contoso Fiber может использовать средство миграции для упрощения процесса миграции.

  • Согласованность с локальными конфигурациями: Она поддерживает различные версии сообщества PostgreSQL, включая версию, которую в настоящее время использует Contoso Fibre.

  • Восстановимость: Гибкое развертывание сервера автоматически создает резервные копии серверов и сохраняет их в хранилище, избыточном между зонами (ZRS) в одном регионе. Contoso Fibre может восстановить базу данных в любой момент времени в течение периода хранения резервных копий. Возможность резервного копирования и восстановления создает лучший RPO по сравнению с локальными средами.

• Мониторинг производительности приложений: Используйте Application Insights для анализа телеметрии в приложении. Contoso Fibre использует Application Insights по следующим причинам:

  • Интеграция с Azure Monitor: Она обеспечивает лучшую интеграцию с Azure Monitor.

  • Обнаружение аномалий: Он автоматически обнаруживает аномалии производительности.

  • Устранение неполадок: Это помогает диагностировать проблемы в работающем приложении.

  • Контроль: Он собирает данные об использовании для приложения и отслеживает пользовательские события.

  • Разрыв видимости: Локальное решение не имеет решения для мониторинга производительности приложений. Application Insights обеспечивает простую интеграцию с платформой приложений и кодом.

• Кэш: Выберите, следует ли добавлять кэш в архитектуру веб-приложения. Azure Redis в управляемом режиме — это основное решение для кэширования в Azure. Это управляемое хранилище данных в памяти на основе программного обеспечения Redis. Contoso Fiber добавляет Azure Managed Redis по следующим причинам:

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

  • Разнообразная поддержка: Это единое расположение кэша, которое может использовать все экземпляры веб-приложения.

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

  • Незакреплённые сеансы: Кэш позволяет веб-приложению экстернализовать состояние сеанса и использовать незакреплённые сеансы. Большинство веб-приложений Java, работающих в локальной среде, используют кэширование на стороне клиента. Этот подход не хорошо масштабируется и увеличивает объем памяти на узле. Управляемый Redis Azure предоставляет управляемую масштабируемую службу кэша для повышения масштабируемости и производительности приложений. Contoso Fibre использовал Spring Cache в качестве платформы абстракции кэша и требовал только минимальные изменения конфигурации для перехода с поставщика Ehcache на поставщик Redis.

• Подсистема балансировки нагрузки: Веб-приложения, использующие платформу как услуга (PaaS), должны использовать Azure Front Door, Шлюз приложений Azure или оба в зависимости от архитектуры и требований веб-приложения. Используйте дерево принятия решений подсистемы балансировки нагрузки , чтобы выбрать правильную подсистему балансировки нагрузки. Contoso Fiber требует балансировщика нагрузки уровня 7, который может направлять трафик между несколькими регионами и многорегионное веб-приложение для достижения SLO 99,9%. Компания использует Azure Front Door по следующим причинам:

  • Глобальная балансировка нагрузки: Подсистема балансировки нагрузки уровня 7 может маршрутизировать трафик в нескольких регионах.

  • Брандмауэр веб-приложения: Он интегрируется изначально с брандмауэром веб-приложений Azure.

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

  • Ускорение трафика: Технология использует маршрутизацию anycast, чтобы достичь ближайшего узла Azure и найти самый быстрый маршрут к веб-приложению.

  • Личные домены: Он поддерживает пользовательские доменные имена с гибкой проверкой домена.

  • Пробы работоспособности: Приложению требуется интеллектуальный мониторинг проб работоспособности. Azure Front Door использует ответы из пробы, чтобы определить лучший источник для маршрутизации клиентских запросов.

  • Поддержка мониторинга: Azure Front Door поддерживает встроенные отчеты со встроенной панелью мониторинга как для Azure Front Door, так и для шаблонов безопасности. Он предоставляет оповещения, которые интегрируются с Azure Monitor. Azure Front Door позволяет логировать каждый запрос и фиксировать неудачные результаты проверки работоспособности.

  • Защита от атак типа "отказ в обслуживании" (DDoS): Он имеет встроенную защиту от атак DDoS на уровне 3 и уровне 4.

  • Сеть доставки содержимого: Это позволяет компании Contoso Fiber использовать сеть доставки содержимого. Сеть доставки содержимого обеспечивает ускорение сайта.

• Брандмауэр веб-приложения: Используйте брандмауэр веб-приложения Azure , чтобы обеспечить централизованную защиту от распространенных веб-эксплойтов и уязвимостей. Contoso Fibre использует брандмауэр веб-приложения Azure по следующим причинам:

  • Глобальная защита: Она обеспечивает улучшенную защиту глобальных веб-приложений при сохранении производительности.

  • Защита ботнета: Команда может отслеживать и настраивать параметры для решения проблем безопасности, связанных с ботнетами.

  • Соответствие локальной среде: Локальное решение выполняется за файрволом веб-приложения, которым управляет IT-служба.

  • Простота использования: Брандмауэр веб-приложений Azure интегрируется с Azure Front Door.

• Диспетчер секретов: Используйте Azure Key Vault , если у вас есть секреты для управления в Azure. Contoso Fibre использует Key Vault по следующим причинам:

  • Шифрование: Оно поддерживает шифрование в состоянии покоя и в процессе передачи.

  • Поддержка управляемой идентификации: Службы приложений могут использовать управляемую идентификацию для доступа к хранилищу секретов.

  • Мониторинг и ведение журнала: Key Vault упрощает доступ к аудиту и создает оповещения при изменении хранимых секретов.

  • Интеграция: Key Vault обеспечивает встроенную интеграцию с хранилищем конфигурации Azure (Конфигурация приложений Azure) и платформой веб-размещения (служба приложений).

• Безопасность конечных точек: Используйте Приватный канал Azure для доступа к решениям PaaS через частную конечную точку в виртуальной сети. Трафик между виртуальной сетью и службой перемещается по магистральной сети Майкрософт. Contoso Fibre использует приватный канал по следующим причинам:

  • Расширенное взаимодействие с безопасностью: Он позволяет приложению приватно обращаться к службам на платформе Azure и сокращает сетевой объем хранилищ данных для защиты от утечки данных.

  • Минимальные усилия: Частные конечные точки поддерживают платформу веб-приложения и платформу базы данных, которую использует веб-приложение. Обе платформы отражают существующие локальные конфигурации, поэтому требуется минимальное изменение.

• Безопасность сети: Используйте брандмауэр Azure для управления входящим и исходящим трафиком на уровне сети. Используйте Бастион Azure для подключения к виртуальным машинам с усиленной безопасностью, не открывая порты протокола удалённого рабочего стола или защищённого терминала (RDP/SSH). Contoso Fibre принимает топологию сети концентратора и периферийной сети и помещает общие службы безопасности сети в концентратор. Брандмауэр Azure проверяет исходящий трафик из периферийных компонентов, чтобы повысить безопасность сети. Компания использует Azure Bastion для развертываний с повышенной безопасностью с узла перехода в подсети DevOps.

Руководство по коду

Чтобы успешно переместить веб-приложение в облако, необходимо обновить код веб-приложения, используя шаблоны Retry, Circuit Breaker и Cache-Aside.

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

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

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

3. Шаблон Cache-Aside загружает данные по запросу в кэш из хранилища данных. Реализуйте этот шаблон для запросов к базе данных.

Реализация шаблона повторных попыток

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

Используйте Resilience4j, легковесную библиотеку для обеспечения отказоустойчивости, чтобы реализовать паттерн повторных попыток в Java. Чтобы добавить паттерн повторных попыток, эталонная реализация декорирует метод контроллера listServicePlans плана обслуживания аннотациями Retry. Код повторяет вызов списка планов обслуживания из базы данных, если первоначальный вызов завершается ошибкой. Политика повторных попыток для эталонной реализации включает максимальные попытки, длительность ожидания и исключения для повторных попыток. Настройте политику повторных попыток в файле application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

Реализация шаблона Circuit Breaker

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

Используйте Spring Cloud Circuit Breaker и Resilience4j для реализации шаблона прерывания цепи. Эталонное внедрение применяет шаблон Circuit Breaker, оформляя методы атрибутом Circuit Breaker.

Реализация шаблона Cache-Aside

Добавьте шаблонCache-Aside в веб-приложение для улучшения управления данными в памяти. Шаблон назначает приложению ответственность за обработку запросов данных и обеспечение согласованности между кэшем и постоянным хранилищем, например базой данных. Он сокращает время отклика, повышает пропускную способность и сокращает потребность в увеличении масштаба. Она также снижает нагрузку на основное хранилище данных, что повышает надежность и оптимизацию затрат. Чтобы реализовать шаблон Cache-Aside, выполните следующие рекомендации.

• Настройте приложение для использования кэша. Чтобы включить кэширование, добавьте spring-boot-starter-cache пакет в качестве зависимости в ваш файл pom.xml. Этот пакет предоставляет конфигурации по умолчанию для кэша Redis.

• Кэшировать необходимые данные. Примените шаблон Cache-Aside к данным с высоким уровнем необходимости, чтобы повысить эффективность работы. Используйте Azure Monitor для отслеживания ЦП, памяти и хранилища базы данных. Эти метрики помогают определить, можно ли использовать меньший номер SKU базы данных после применения шаблона Cache-Aside. Чтобы кэшировать определенные данные в коде, добавьте заметку @Cacheable . Эта аннотация указывает Spring, какие методы должны иметь кэшированные результаты.

• Сохраняйте свежие данные кэша. Планирование регулярных обновлений кэша для синхронизации с последними изменениями базы данных. Используйте волатильность данных и пользователю необходимо определить оптимальную частоту обновления. Эта практика гарантирует, что приложение использует шаблон Cache-Aside для обеспечения быстрого доступа и текущей информации. Параметры кэша по умолчанию могут не соответствовать веб-приложению. Эти параметры можно настроить в application.properties файле или переменных среды. Например, можно изменить spring.cache.redis.time-to-live значение (выражено в миллисекундах), чтобы контролировать, сколько времени данные должны оставаться в кэше до его удаления.

• Обеспечение согласованности данных. Реализуйте механизмы обновления кэша сразу после операций записи базы данных. Используйте обновления на основе событий или выделенные классы управления данными, чтобы обеспечить согласованность кэша. Согласованная синхронизация кэша с изменениями базы данных является центральной для шаблона Cache-Aside.

Руководство по настройке

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

Настройка проверки подлинности и авторизации пользователей

При переносе веб-приложений в Azure настройте механизмы проверки подлинности и авторизации пользователей. Следуйте приведенным ниже рекомендациям.

• Используйте платформу управления идентификацией. Используйте платформу удостоверений Майкрософт для разработчиков, чтобынастроить проверку подлинности веб-приложения. Эта платформа поддерживает приложения, которые используют один каталог Microsoft Entra, несколько каталогов Microsoft Entra из разных организаций, а также Майкрософт идентичности или социальные учетные записи.

  [Spring Boot Starter для Microsoft Entra ID](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide) использует Spring Security и Spring Boot для легкой настройки и интеграции. Он предоставляет различные потоки проверки подлинности, автоматическое управление маркерами, настраиваемые политики авторизации и возможности интеграции с компонентами Spring Cloud. Это средство обеспечивает простую интеграцию Идентификатора Microsoft Entra и OAuth 2.0 с приложениями Spring Boot без настройки библиотеки или параметров вручную.

  Эталонная реализация использует платформу идентификации Майкрософт (Microsoft Entra ID) в качестве поставщика идентификации для веб-приложения. Он использует код авторизации OAuth 2.0 для входа пользователя с учетной записью Microsoft Entra. Следующий фрагмент XML определяет две необходимые зависимости потока предоставления кода авторизации OAuth 2.0. Зависимость com.azure.spring: spring-cloud-azure-starter-active-directory позволяет использовать аутентификацию и авторизацию Microsoft Entra в приложении Spring Boot. Зависимость org.springframework.boot: spring-boot-starter-oauth2-client позволяет использовать аутентификацию и авторизацию OAuth 2.0 в приложении Spring Boot.

  <dependency>
      <groupid>com.azure.spring</groupid>
      <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
  </dependency>
  <dependency>
      <groupid>org.springframework.boot</groupid>
      <artifactid>spring-boot-starter-oauth2-client</artifactid>
  </dependency>
  

• Создайте регистрацию приложения. Идентификатор Microsoft Entra id требует регистрации приложения в основном клиенте. Регистрация приложения помогает гарантировать, что пользователи, получающие доступ к веб-приложению, имеют учетные записи в основном арендаторе. Эталонная реализация использует Terraform для создания регистрации приложения ID Microsoft Entra вместе с ролью Менеджера учетных записей для конкретного приложения.

  resource "azuread_application" "app_registration" {
    display_name     = "${azurecaf_name.app_service.result}-app"
    owners           = [data.azuread_client_config.current.object_id]
    sign_in_audience = "AzureADMyOrg"  # single tenant
  
    app_role {
      allowed_member_types = ["User"]
      description          = "Account Managers"
      display_name         = "Account Manager"
      enabled              = true
      id                   = random_uuid.account_manager_role_id.result
      value                = "AccountManager"
    }
  }
  

• Принудительное применение авторизации в приложении. Используйте управление доступом на основе ролей (RBAC), чтобы назначить минимальные привилегии ролям приложений. Определите определенные роли для различных действий пользователей, чтобы избежать перекрытия и обеспечить ясность. Сопоставите пользователей с соответствующими ролями и убедитесь, что у них есть доступ только к необходимым ресурсам и действиям. Настройте Spring Security для использования Spring Boot Starter для Microsoft Entra ID. Эта библиотека обеспечивает интеграцию с идентификатором Microsoft Entra и помогает обеспечить безопасную проверку подлинности пользователей. Настройте и включите библиотеку проверки подлинности Майкрософт (MSAL), чтобы получить доступ к дополнительным функциям безопасности. К этим функциям относятся кэширование маркеров и автоматическое обновление маркеров.

  Эталонная реализация создает роли приложений, которые отражают типы ролей пользователей в системе управления учетными записями Contoso Fibre. Роли переводятся в разрешения во время авторизации. Примеры ролей, относящихся к приложениям в CAMS, включают диспетчер учетных записей, представитель службы поддержки уровня 1 (L1) и представитель службы полей. Роль Диспетчера учетных записей имеет разрешения на добавление новых пользователей и клиентов приложений. Представитель службы полей может создавать запросы в службу поддержки. Атрибут PreAuthorize ограничивает доступ к определенным ролям.

      @GetMapping("/new")
      @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
      public String newAccount(Model model) {
          if (model.getAttribute("account") == null) {
              List<ServicePlan> servicePlans = accountService.findAllServicePlans();
              ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
              NewAccountRequest accountFormData = new NewAccountRequest();
              accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
              model.addAttribute("account", accountFormData);
              model.addAttribute("servicePlans", servicePlans);
          }
          model.addAttribute("servicePlans", accountService.findAllServicePlans());
          return "pages/account/new";
      }
      ...
  

  Чтобы интегрироваться с идентификатором Microsoft Entra, эталонная реализация использует поток предоставления кода авторизации OAuth 2.0 . Этот поток позволяет пользователю входить с помощью учетной записи Майкрософт. В следующем фрагменте кода показано, как настроить SecurityFilterChain для использования Microsoft Entra ID в целях аутентификации и авторизации.

  @Configuration(proxyBeanMethods = false)
  @EnableWebSecurity
  @EnableMethodSecurity
  public class AadOAuth2LoginSecurityConfig {
      @Bean
      SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
          http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
              .and()
                  .authorizeHttpRequests()
              .requestMatchers(EndpointRequest.to("health")).permitAll()
              .anyRequest().authenticated()
              .and()
                  .logout(logout -> logout
                              .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                              .clearAuthentication(true)
                              .invalidateHttpSession(true));
          return http.build();
      }
  }
  ...
  

• Предпочитайте временный доступ к хранилищу. Используйте временные разрешения для защиты от несанкционированного доступа и нарушений. Например, можно использовать подписанные URL-адреса (SAS) для ограничения доступа к периоду времени. Используйте SAS делегирования пользователей для обеспечения максимальной безопасности при предоставлении временного доступа. Это единственный SAS, использующий учетные данные идентификатора Microsoft Entra и не требующий постоянного ключа учетной записи хранения.

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

• Избегайте постоянных повышенных разрешений. Используйте Microsoft Entra Privileged Identity Management (PIM) для предоставления JIT-доступа для привилегированных операций. Например, разработчикам часто требуется доступ на уровне администратора для создания и удаления баз данных, изменения схем таблиц и изменения разрешений пользователя. При использовании JIT-доступа идентификации пользователей получают временные права на выполнение привилегированных задач.

Внедрение управляемых удостоверений

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

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

• Настройте минимальные привилегии. Используйте Azure RBAC для предоставления только разрешений, критически важных для операций, таких как создание, чтение, обновление и удаление (CRUD) в базах данных или доступ к секретам. Разрешения идентификаторов рабочей нагрузки являются постоянными, поэтому невозможно предоставить JIT или краткосрочные разрешения. Если Azure RBAC не охватывает конкретный сценарий, дополните Azure RBAC политиками доступа на уровне службы Azure.

• Обеспечение безопасности оставшихся секретов. Сохраните все оставшиеся секреты в Key Vault. Загрузите секреты из Key Vault при запуске приложения вместо каждого HTTP-запроса. Высокочастотный доступ в HTTP-запросах может превышать ограничения транзакций Key Vault. Хранение конфигураций приложений в конфигурации приложений.

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

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

• Оценка затрат. Используйте калькулятор цен Azure для оценки стоимости каждой среды.

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

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

• Используйте IaC для определения номеров SKU. Реализуйте IaC для динамического выбора и развертывания соответствующих SKU в зависимости от среды. Этот подход повышает согласованность и упрощает управление.

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

azd env set APP_ENVIRONMENT prod

Внедрение автомасштабирования

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

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

• Уточнение триггеров масштабирования. Используйте использование ЦП в качестве начального триггера масштабирования, если вы не знакомы с требованиями к масштабированию приложения. Уточните триггеры масштабирования, чтобы включить другие метрики, такие как ОЗУ, пропускная способность сети и выходные данные диска (ввода-вывода). Цель заключается в том, чтобы соответствовать поведению веб-приложения для повышения производительности.

• Укажите буфер горизонтального масштабирования. Задайте пороговые значения масштабирования, чтобы инициировать масштабирование до достижения максимальной емкости. Например, настройте масштабирование при 85% загрузке ЦП, а не ждите, пока она не достигнет 100%. Этот упреждающий подход помогает поддерживать производительность и избегать потенциальных узких мест.

Автоматизация развертывания ресурсов

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

• Используйте IaC. Разверните IaC с помощью конвейеров непрерывной интеграции и непрерывной доставки (CI/CD). Azure предоставляет предварительно созданные шаблоны Bicep, шаблоны Azure Resource Manager (шаблоны ARM) и шаблоны Terraform для каждого ресурса Azure.

• Используйте конвейер CI/CD. Используйте конвейер CI/CD для развертывания кода из системы контроля версий в различные среды, такие как тестовая, стейджинг и рабочая. Используйте Azure Pipelines, если вы работаете с Azure DevOps. Используйте GitHub Actions для проектов GitHub.

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

• Внедрение фреймворков для мокирования. Для тестирования с использованием внешних конечных точек используйте фреймворки для имитации. Эти платформы позволяют создавать имитированные конечные точки. Они устраняют необходимость настройки реальных внешних конечных точек и обеспечения унифицированных условий тестирования в разных средах.

• Выполнение проверок безопасности. Используйте статическое тестирование безопасности приложений (SAST), чтобы найти ошибки безопасности и ошибки программирования в исходном коде. Проводите анализ композиции программного обеспечения (SCA), чтобы изучить библиотеки и компоненты, отличные от Майкрософт, для рисков безопасности. Интегрируйте средства для этих анализов как в GitHub, так и в Azure DevOps.

Настройка мониторинга

Реализуйте мониторинг приложений и платформ, чтобы повысить эффективность работы и производительности веб-приложения. Чтобы реализовать мониторинг, следуйте приведенным ниже рекомендациям.

• Соберите данные телеметрии приложения. Используйте автоинструментацию в Application Insights для сбора данных телеметрии приложений, таких как пропускная способность запросов, средняя длительность запроса, ошибки и мониторинг зависимостей. Вам не нужно изменять код для использования этой телеметрии. Spring Boot регистрирует несколько основных метрик в Application Insights, таких как виртуальная машина Java (JVM), ЦП и Tomcat. Application Insights автоматически собирает данные из платформ ведения журнала, таких как Log4j и Logback.

  Эталонная реализация включает Application Insights через Terraform в конфигурации службы app_settings приложений:

  app_settings = {
      APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
      ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
      ...
  }
  

  Дополнительные сведения см. в следующих статьях:

  • Настройка Azure Monitor Application Insights для Spring Boot
  • Azure Monitor Application Insights для Java
  • Включение Azure Monitor OpenTelemetry для приложений Java
  • Использование Azure Monitor Application Insights с Spring Boot

• Создайте пользовательские метрики приложений. Реализуйте инструментирование на основе кода для записи телеметрии пользовательского приложения , добавив пакет SDK Application Insights и используя его API.

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

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

  # Configure diagnostic settings for app service
  resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
    name                           = "app-service-diagnostic-settings"
    target_resource_id             = azurerm_linux_web_app.application.id
    log_analytics_workspace_id     = var.log_analytics_workspace_id
    #log_analytics_destination_type = "AzureDiagnostics"
  
    enabled_log {
      category_group = "allLogs"
  
    }
  
    metric {
      category = "AllMetrics"
      enabled  = true
    }
  }
  

Развертывание эталонной реализации

Эталонная реализация поможет вам выполнить имитированную миграцию локального приложения Java в Azure с помощью Contoso Fibre. Он также выделяет необходимые изменения во время начального этапа внедрения.

Следующая архитектура представляет окончательное состояние реализации шаблона Надежного веб-приложения Contoso Fibre на основе их целей.

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

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

• Эталонная реализация