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

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

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

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

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

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

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

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

Первым шагом в переплатформировке веб-приложения является определение бизнес-целей. Необходимо задать немедленные цели, такие как цели уровня обслуживания (SLO) и целевые показатели оптимизации затрат, а также будущие цели для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру веб-приложения в облаке. Определите целевой 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" и Java в приложениях контейнеров Azure.
  • Высокий уровень обслуживания. Служба приложений предоставляет высокий уровень обслуживания, соответствующий требованиям для рабочей среды.
  • Сокращение затрат на управление. Служба приложений — это полностью управляемое решение для размещения.
  • Возможность контейнеризации. Служба приложений работает с реестрами образов частных контейнеров, такими как Реестр контейнеров 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 может использовать средство миграции для упрощения процесса миграции.
  • Согласованность с локальными конфигурациями. Она поддерживает различные версии сообщества PostgreSQL, включая версию, которую в настоящее время использует Contoso Fibre.
  • Устойчивость. Гибкое развертывание сервера автоматически создает резервные копии серверов и сохраняет их в хранилище, избыточном между зонами (ZRS) в одном регионе. Компания Contoso может восстановить базу данных в любой момент времени в течение периода хранения резервных копий. Возможность резервного копирования и восстановления создает лучший 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 использовала платформу абстракции кэша (Spring Cache) и требовала только минимальных изменений конфигурации для обмена поставщиком кэша. Он позволил им переключиться с поставщика Ehcache на поставщик Redis.

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

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

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

  • Глобальная защита. Она обеспечивает улучшенную защиту глобальных веб-приложений без ущерба для производительности.
  • Защита botnet. Команда может отслеживать и настраивать параметры для решения проблем безопасности, связанных с ботнетами.
  • Четность с локальной средой. Локальное решение выполнялось за брандмауэром веб-приложения, управляемым ИТ-службой.
  • Простота использования. Брандмауэр веб-приложений интегрируется с 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 повышает безопасность, проверяя весь исходящий трафик с периферийных узлов, чтобы повысить безопасность сети. Contoso Fibre требуется Бастион Azure для развертывания расширенной безопасности с узла перехода в подсети DevOps.

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

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

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

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

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

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

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

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

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

Используйте отказоустойчивость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 Cloud и устойчивость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 для идентификатора Microsoft Entra упрощает этот процесс. Он использует 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.

Среды rightsize

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

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

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

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

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

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

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

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