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

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

Почему шаблон Надежных веб-приложений для Java?

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Основные архитектурные элементы шаблона Reliable Web App.

Разработка архитектуры

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

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

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

  

  Рисунок 2. Шаблон Reliable Web App со второй областью и звездообразной топологией.

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

Выбор правильных служб Azure

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

Например, до перехода в облако веб-приложение Contoso Fibre CAMS было локальным монолитным веб-приложением Java. Это приложение Spring Boot с базой данных PostgreSQL. Веб-приложение — это бизнес-приложение поддержки. Это сотрудники. Сотрудники Contoso Fibre используют приложение для управления вариантами поддержки от своих клиентов. Веб-приложение страдало от распространенных проблем в развертывании масштабируемости и функций. Эта отправная точка, их бизнес-цели и SLO привели к выбору их услуг.

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

  • Естественное прогрессия: Contoso Fibre развернул файл Spring Boot jar на локальном сервере и хотел свести к минимуму количество перепроектирования для этой модели развертывания. Служба приложений обеспечивает надежную поддержку запуска приложений Spring Boot, и это была естественная прогрессия для Contoso Fibre, чтобы использовать Служба приложений. Приложения контейнеров Azure также являются привлекательной альтернативой для этого приложения. Дополнительные сведения см. в статье "Что такое Azure Spring Apps" и Java в azure Container Apps.
  • Высокий уровень обслуживания: оно имеет высокий уровень обслуживания, соответствующий требованиям для рабочей среды.
  • Сокращение затрат на управление: это полностью управляемое решение для размещения.
  • Возможность контейнеризации: Служба приложений работает с реестрами образов частных контейнеров, такими как Реестр контейнеров Azure. Contoso Fibre может использовать эти реестры для контейнеризации веб-приложения в будущем.
  • Автомасштабирование. Веб-приложение может быстро увеличивать, уменьшать и выходить на основе трафика пользователей.

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

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

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

  • Надежность. Модель развертывания гибкого сервера поддерживает высокий уровень доступности, избыточный между зонами, в нескольких зонах доступности. Эта конфигурация поддерживает теплый резервный сервер в другой зоне доступности в одном регионе Azure. Конфигурация реплицирует данные синхронно на резервный сервер.
  • Репликация между регионами: она имеет функцию реплики чтения, которая позволяет асинхронно реплицировать данные в базу данных реплики только для чтения в другом регионе.
  • Производительность. Она обеспечивает прогнозируемую производительность и интеллектуальную настройку для повышения производительности базы данных с помощью реальных данных об использовании.
  • Сокращение затрат на управление. Это полностью управляемая служба Azure, которая снижает обязательства по управлению.
  • Поддержка миграции. Она поддерживает миграцию базы данных из локальных баз данных PostgreSQL с одним сервером. Они могут использовать средство миграции для упрощения процесса миграции.
  • Согласованность с локальными конфигурациями: она поддерживает различные версии сообщества PostgreSQL, включая версию, которую в настоящее время использует Contoso Fibre.
  • Устойчивость. Гибкое развертывание сервера автоматически создает резервные копии серверов и сохраняет их с помощью хранилища, избыточного между зонами (ZRS) в одном регионе. Они могут восстановить базу данных в любой момент времени в течение периода хранения резервных копий. Возможность резервного копирования и восстановления создает лучший RPO (допустимый объем потери данных), чем Contoso Fibre может создать локальную среду.

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

  • Интеграция с Azure Monitor. Она обеспечивает лучшую интеграцию с Azure Monitor.
  • Обнаружение аномалий: оно автоматически обнаруживает аномалии производительности.
  • Устранение неполадок. Это помогает диагностировать проблемы в работающем приложении.
  • Мониторинг. Он собирает сведения о том, как пользователи используют приложение, и позволяет легко отслеживать пользовательские события.
  • Разрыв видимости. Локальное решение не было решения для мониторинга производительности приложений. Application Insights обеспечивает простую интеграцию с платформой приложений и кодом.

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

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

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

  • Глобальная балансировка нагрузки: это подсистема балансировки нагрузки уровня 7, которая может направлять трафик в нескольких регионах.
  • Брандмауэр веб-приложения: он интегрируется изначально с Azure Брандмауэр веб-приложений.
  • Гибкость маршрутизации. Это позволяет группе приложений настраивать входящий трафик, который должен поддерживать будущие изменения в приложении.
  • Ускорение трафика. Он использует любую рассылку для достижения ближайшей точки присутствия Azure и поиска самого быстрого маршрута к веб-приложению.
  • Личные домены: он поддерживает пользовательские доменные имена с гибкой проверкой домена.
  • Пробы работоспособности: приложению требуется интеллектуальный мониторинг проб работоспособности. Azure Front Door использует ответы из пробы, чтобы определить лучший источник для маршрутизации клиентских запросов.
  • Поддержка мониторинга. Она поддерживает встроенные отчеты со всеми панелями мониторинга как для Front Door, так и для шаблонов безопасности. Вы можете настроить оповещения, которые интегрируются с Azure Monitor. Он позволяет журналу приложений каждый запрос и неудачные пробы работоспособности.
  • Защита от атак DDoS: она имеет встроенную защиту от атак DDoS уровня 3-4.
  • Сеть доставки содержимого: она размещает Contoso Fibre для использования сети доставки содержимого. Сеть доставки содержимого обеспечивает ускорение сайта.

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

  • Глобальная защита: она обеспечивает улучшенную глобальную защиту веб-приложений без ущерба для производительности.
  • Защита botnet: команда может отслеживать и настраивать параметры для решения проблем безопасности, связанных с ботнетами.
  • Паритетность с локальной средой: локальное решение выполнялось за брандмауэром веб-приложения, управляемым ИТ-службой.
  • Простота использования: Брандмауэр веб-приложений интегрируется с Azure Front Door.

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

  • Шифрование: оно поддерживает шифрование при хранении и передаче.
  • Поддержка управляемого удостоверения. Службы приложений могут использовать управляемые удостоверения для доступа к хранилищу секретов.
  • Мониторинг и ведение журнала. Это упрощает доступ к аудиту и создает оповещения при изменении хранимых секретов.
  • Интеграция. Она обеспечивает встроенную интеграцию с хранилищем конфигурации Azure (Конфигурация приложений) и платформой веб-размещения (Служба приложений).

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

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

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

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

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

Рисунок 3. Роль шаблонов проектирования.

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

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

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

3. Шаблон "В сторону кэша": шаблон "Кэш-в сторону" добавляется и извлекается из кэша чаще, чем хранилище данных. Реализуйте этот шаблон для запросов к базе данных.

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

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

Используйте отказоустойчивость4j, упрощенную библиотеку отказоустойчивости для реализации шаблона повторных попыток в 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";
    }

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

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

Используйте документацию Spring Circuit Breaker и Отказоустойчивость4j для реализации шаблона разбиения цепи. Например, эталонная реализация реализует шаблон разбиения цепи путем декорирования методов атрибутом разбиения цепи.

Реализация шаблона "Кэш в сторону"

Добавьте шаблон 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 значение (выражено в миллисекундах), чтобы контролировать, сколько времени данные должны оставаться в кэше, прежде чем вытеснить его.

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

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

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

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

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

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

  Spring Boot Starter for Microsoft Entra ID упрощает этот процесс, используя Spring Security и Spring Boot для простой настройки. Он предлагает различные потоки проверки подлинности, автоматическое управление маркерами и настраиваемые политики авторизации, а также возможности интеграции с компонентами Spring Cloud. Это обеспечивает простую интеграцию Идентификатора Microsoft Entra и OAuth 2.0 с приложениями Spring Boot без настройки библиотеки или параметров вручную.

  Например, эталонная реализация использует платформа удостоверений Майкрософт (идентификатор Microsoft Entra) в качестве поставщика удостоверений для веб-приложения. Он использует код авторизации 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 для создания регистрации приложения идентификатора 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. Эта библиотека позволяет интегрироваться с идентификатором 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 для проверки подлинности и авторизации.

  @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 управление привилегированными пользователями, чтобы предоставить JIT-доступ для привилегированных операций. Например, разработчикам часто требуется доступ на уровне администратора для создания и удаления баз данных, изменения схем таблиц и изменения разрешений пользователя. При JIT-доступе удостоверения пользователей получают временные разрешения для выполнения привилегированных задач.

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

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

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

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

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

Правильные среды размера

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

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

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

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

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

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

azd env set APP_ENVIRONMENT prod

Реализация автомасштабирования

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

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

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

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

Автоматическое развертывание ресурсов

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

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

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

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

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

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

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

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

• Сбор данных телеметрии приложения. Используйте автоинструментацию в приложение Azure 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, подчеркивая необходимые изменения во время начального этапа внедрения. В этом примере используется веб-приложение системы управления учетными записями клиентов (CAMS) для вымышленной компании Contoso Fibre. Contoso Fibre задает следующие цели для своего веб-приложения:

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

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

Рис. 4. Архитектура эталонной реализации. Скачайте файл Visio этой архитектуры.