В этой статье показано, как спланировать реализацию шаблона Reliable Web App. Шаблон Reliable Web App — это набор принципов и методов реализации, определяющих способ изменения веб-приложений (переплатформ) при миграции в облако. Он фокусируется на минимальных обновлениях кода, необходимых для успешного выполнения в облаке.
Чтобы упростить применение этого руководства, существует эталонная реализация шаблона Reliable Web App, который можно развернуть.
Архитектура эталонной реализации. Скачайте файл Visio этой архитектуры.
В следующем руководстве в качестве примера используется эталонная реализация. Чтобы спланировать реализацию шаблона Reliable Web App, выполните следующие действия.
Определение бизнес-целей
Первоначальный шаг перехода на облачные вычисления — сформулировать бизнес-цели. Шаблон Reliable Web App подчеркивает важность настройки как непосредственных, так и будущих целей для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру веб-приложения в облаке.
Пример: вымышленная компания Contoso Fibre хотела расширить локальное веб-приложение системы управления учетными записями клиентов (CAMS), чтобы получить доступ к другим регионам. Для удовлетворения повышенного спроса на веб-приложение они установили следующие цели:
- Применение изменений кода с низкими затратами и высокой стоимостью
- Достичь цели уровня обслуживания (SLO) 99,9%
- Внедрение методик DevOps
- Создание оптимизированных для затрат сред
- Повышение надежности и безопасности
Contoso Fibre определила, что локальная инфраструктура не является экономически эффективным решением для масштабирования приложения. Поэтому они решили, что перенос веб-приложения CAMS в Azure является самым экономичным способом достижения своих непосредственных и будущих целей.
Выбор правильных управляемых служб
При перемещении веб-приложения в облако следует выбрать службы Azure, которые соответствуют вашим бизнес-требованиям и соответствуют текущим функциям локального веб-приложения. Выравнивание помогает свести к минимуму усилия по переформировки. Например, используйте службы, которые позволяют поддерживать один и тот же ядро СУБД и поддерживать существующие по промежуточного слоя и платформы. В следующих разделах приведены рекомендации по выбору нужных служб Azure для веб-приложения.
Пример. До перехода в облако веб-приложение Contoso Fibre camS было локальным монолитным веб-приложением Java. Это приложение Spring Boot с базой данных PostgreSQL. Веб-приложение — это бизнес-приложение поддержки. Это сотрудники. Сотрудники Contoso Fibre используют приложение для управления вариантами поддержки от своих клиентов. Локальное веб-приложение страдает от распространенных проблем. К этим проблемам относятся расширенные временная шкала для создания и доставки новых функций и сложности масштабирования различных компонентов приложения при более высокой нагрузке.
Платформа приложений
Выберите лучшую платформу размещения приложений для веб-приложения. Azure имеет множество различных вариантов вычислений для удовлетворения ряда требований к веб-приложениям. Сведения о сужающих параметрах см. в дереве принятия решений вычислений Azure.
Пример: Contoso Fibre выбрал службу приложение Azure в качестве платформы приложений по следующим причинам:
Естественное прогрессирование. Contoso Fibre развернул файл Spring Boot
jarна локальном сервере и хотел свести к минимуму количество перезадачи для этой модели развертывания. Служба приложений обеспечивает надежную поддержку запуска приложений Spring Boot, и это была естественная прогрессия для Contoso Fibre, чтобы использовать Служба приложений. Azure Spring Apps также является привлекательной альтернативой для этого приложения. Если веб-приложение Contoso Fibre CAMS использовало Jakarta EE вместо Spring Boot, Azure Spring Apps лучше подходит. Дополнительные сведения см. в статье "Что такое Azure Spring Apps" и Java EE, Jakarta EE и MicroProfile в Azure.Высокий уровень обслуживания. Он имеет высокий уровень обслуживания, соответствующий требованиям для рабочей среды.
Сокращение затрат на управление. Это полностью управляемое решение для размещения.
Возможность контейнеризации. Служба приложений работает с реестрами образов частных контейнеров, такими как Реестр контейнеров Azure. Contoso Fibre может использовать эти реестры для контейнеризации веб-приложения в будущем.
Автомасштабирование. Веб-приложение может быстро увеличивать, уменьшать и выходить на основе трафика пользователей.
Управление удостоверениями
Выберите оптимальное решение для управления удостоверениями для веб-приложения. Дополнительные сведения см. в статье "Сравнение решений по управлению удостоверениями" и методов проверки подлинности.
Пример: Contoso Fibre выбрал идентификатор Microsoft Entra ПО следующим причинам:
Проверка подлинности и авторизация. Он обрабатывает проверку подлинности и авторизацию сотрудников.
Масштабируемость. Она масштабируется для поддержки более крупных сценариев.
Элемент управления удостоверениями пользователя. Сотрудники могут использовать существующие корпоративные удостоверения.
Поддержка протоколов авторизации. Он поддерживает OAuth 2.0 для управляемых удостоверений.
База данных
Выберите лучшую базу данных для веб-приложения. Сведения об сужении параметров см. в дереве принятия решений хранилища данных Azure.
Пример: Contoso Fibre выбрал База данных Azure для PostgreSQL и вариант гибкого сервера по следующим причинам:
Надежность. Модель развертывания гибкого сервера поддерживает высокий уровень доступности, избыточный между зонами, в нескольких зонах доступности. Эта конфигурация и поддерживает теплый резервный сервер в другой зоне доступности в одном регионе Azure. Конфигурация реплика синхронизирует данные с резервным сервером.
Репликация между регионами. Он имеет функцию чтения реплика, которая позволяет асинхронно реплика te данные в базу данных только для чтения реплика в другом регионе.
Производительность. Она обеспечивает прогнозируемую производительность и интеллектуальную настройку для повышения производительности базы данных с помощью реальных данных об использовании.
Сокращение затрат на управление. Это полностью управляемая служба Azure, которая сокращает обязательства по управлению.
Поддержка миграции. Она поддерживает миграцию баз данных из локальных баз данных PostgreSQL с одним сервером. Они могут использовать средство миграции для упрощения процесса миграции.
Согласованность с локальными конфигурациями. Она поддерживает различные версии сообщества PostgreSQL, включая версию, которую в настоящее время использует Contoso Fibre.
Устойчивость. Гибкое развертывание сервера автоматически создает резервные копии серверов и сохраняет их с помощью хранилища, избыточного между зонами (ZRS) в одном регионе. Они могут восстановить базу данных в любой момент времени в течение периода хранения резервных копий. Возможность резервного копирования и восстановления создает лучший RPO (допустимый объем потери данных), чем Contoso Fibre может создать локальную среду.
Мониторинг производительности приложения
Выберите мониторинг производительности приложения для веб-приложения. Приложение Аналитика — это решение для управления производительностью приложений Azure (APM). Это функция решения для мониторинга Azure, Azure Monitor.
Пример: Contoso Fibre добавил приложение Аналитика по следующим причинам:
обнаружение аномалий; Она автоматически обнаруживает аномалии производительности.
Устранение неполадок. Это помогает диагностировать проблемы в работающем приложении.
Телеметрия. Он собирает сведения о том, как пользователи используют приложение, и позволяет легко отправлять пользовательские события, которые вы хотите отслеживать в приложении.
Локальный разрыв видимости. Локальное решение не было решения для мониторинга производительности приложений. Приложение Аналитика обеспечивает простую интеграцию с платформой приложений и кодом.
Cache
Выберите, следует ли добавлять кэш в архитектуру веб-приложения. Кэш Azure для Redis — это основное решение кэша Azure. Это управляемое хранилище данных в памяти на основе программного обеспечения Redis.
Пример: Contoso Fibre требует кэша, который обеспечивает следующие преимущества:
Скорость и объем. Он имеет высокую пропускную способность и низкую задержку чтения для часто доступных, медленно изменяющихся данных.
Разнообразная поддержка. Это единое расположение кэша, которое может использовать все экземпляры веб-приложения.
Внешнее хранилище данных. Локальные серверы приложений выполнили кэширование локальной виртуальной машины. Эта настройка не выгружает часто задаваемые данные, и не удалось сделать недопустимые данные.
Нестистионные сеансы. Кэш позволяет веб-приложению внешний режим сеанса использовать нестистиковые сеансы. Большинство веб-приложений Java, работающих в локальной среде, используют кэширование на стороне клиента. Кэширование на стороне клиента не масштабируется хорошо и увеличивает объем памяти на узле. С помощью Кэш Azure для Redis Contoso Fibre имеет полностью управляемую масштабируемую службу кэша для повышения масштабируемости и производительности своих приложений. Contoso Fibre использовал платформу абстракции кэша (Spring Cache) и только необходимы минимальные изменения конфигурации для замены поставщика кэша. Он позволил им переключиться с поставщика Ehcache на поставщик Redis.
Подсистема балансировки нагрузки
Выберите лучший балансировщик нагрузки для веб-приложения. Azure имеет несколько подсистем балансировки нагрузки. Дополнительные сведения о сужающих параметрах см . в разделе "Выбор оптимальной подсистемы балансировки нагрузки" для вашего приложения.
Пример: Contoso Fibre выбрал Front Door в качестве глобального балансировщика нагрузки по следующим причинам:
Гибкость маршрутизации. Она позволяет группе приложений настраивать входящий трафик, который должен поддерживать будущие изменения в приложении.
Ускорение трафика. Он использует любую рассылку для достижения ближайшей точки присутствия Azure и поиска самого быстрого маршрута к веб-приложению.
Личные домены. Он поддерживает пользовательские доменные имена с гибкой проверкой домена.
Пробы работоспособности. Приложению требуется интеллектуальный мониторинг проб работоспособности. Azure Front Door использует ответы из пробы, чтобы определить лучший источник для маршрутизации клиентских запросов.
Поддержка мониторинга. Он поддерживает встроенные отчеты со встроенными панелями мониторинга как для Front Door, так и для шаблонов безопасности. Вы можете настроить оповещения, которые интегрируются с Azure Monitor. Он позволяет журналу приложений каждый запрос и неудачные пробы работоспособности.
Защита от атак DDoS. Он имеет встроенную защиту от атак DDoS уровня 3-4.
Брандмауэр веб-приложения
Выберите брандмауэр веб-приложения для защиты веб-приложения от веб-атак. Azure Брандмауэр веб-приложений (WAF) — это брандмауэр веб-приложения Azure и обеспечивает централизованную защиту от распространенных веб-эксплойтов и уязвимостей.
Пример: Contoso Fibre выбрал Брандмауэр веб-приложений для следующих преимуществ:
Глобальная защита. Она обеспечивает повышенную глобальную защиту веб-приложений без ущерба для производительности.
Защита botnet. Вы можете настроить правила защиты ботов для отслеживания атак botnet.
Четность с локальной средой. Локальное решение выполнялось за брандмауэром веб-приложения, управляемым ИТ-службой.
Диспетчер секретов
Используйте Azure Key Vault , если у вас есть секреты для управления в Azure.
Пример: Contoso Fibre имеет секреты для управления. Они использовали Key Vault по следующим причинам:
Шифрование Он поддерживает шифрование при хранении и передаче.
Поддерживает управляемые удостоверения. Службы приложений могут использовать управляемые удостоверения для доступа к хранилищу секретов.
Мониторинг и ведение журнала. Он упрощает доступ к аудиту и создает оповещения при изменении хранимых секретов.
Интеграция. Он поддерживает два метода для доступа к секретам веб-приложения. Contoso Fibre может использовать параметры приложения на платформе размещения (Служба приложений), или они могут ссылаться на секрет в коде приложения (файл свойств приложения).
безопасность конечных точек.
Выберите, чтобы включить частный доступ только к службам Azure. Приватный канал Azure предоставляет доступ к решениям платформы как услуга через частную конечную точку в виртуальной сети. Трафик между виртуальной сетью и службой перемещается по магистральной сети Майкрософт.
Пример: Contoso Fibre выбрал Приватный канал по следующим причинам:
Улучшенная безопасность. Он позволяет приложению приватно обращаться к службам в Azure и сокращает сетевой объем хранилищ данных, помогая защититься от утечки данных.
Минимальные усилия. Частные конечные точки поддерживают платформу веб-приложения и платформу базы данных, которую использует веб-приложение. Обе платформы зеркало существующей локальной установки, поэтому необходимы минимальные изменения.
Выбор правильной архитектуры
После определения доступных средств для веб-приложения и выбора правильных облачных служб необходимо определить оптимальную архитектуру для веб-приложения. Архитектура должна поддерживать бизнес-требования, технические требования и цель уровня обслуживания.
Выбор избыточности архитектуры
Бизнес-цели определяют уровень инфраструктуры и избыточности данных, необходимых веб-приложению. SLO веб-приложения предоставляет хорошие базовые показатели для понимания требований к избыточности. Вычислите составное соглашение об уровне обслуживания для всех зависимостей по критическому пути доступности. Зависимости должны включать службы Azure и решения, отличные от Майкрософт.
Назначьте оценку доступности для каждой зависимости. Соглашения об уровне обслуживания (соглашения об уровне обслуживания) обеспечивают хорошую отправную точку, но соглашения об уровне обслуживания не учитывают код, стратегии развертывания и решения об архитектуре подключения.
Пример. Эталонная реализация использует два региона в активно-пассивной конфигурации. Contoso Fibre имеет 99,9 % SLO и требуется использовать два региона для удовлетворения SLO. Конфигурация "активный- пассивный" соответствует цели Contoso Fibre минимальных изменений кода для этого этапа в пути к облаку. Конфигурация "активный- пассивный" предоставляет простую стратегию данных. Это позволяет избежать необходимости настройки синхронизации данных на основе событий, сегментов данных или другой стратегии управления данными. Весь входящий трафик направляется в активный регион. Если сбой возникает в активном регионе, Contoso Fibre вручную инициирует план отработки отказа и направляет весь трафик в пассивный регион.
Выбор топологии сети
Выберите правильную топологию сети для ваших веб-приложений и сетевых требований. Топология сети концентратора и периферийной сети является стандартной конфигурацией в Azure. Она обеспечивает преимущества затрат, управления и безопасности. Он также поддерживает варианты гибридного подключения к локальным сетям.
Пример: Contoso Fibre выбрал концентратор и периферийную топологию сети, чтобы повысить безопасность развертывания в нескольких регионах при снижении затрат и затрат на управление.
Выбор избыточности данных
Обеспечение надежности данных путем распространения данных в регионах и зонах доступности Azure; чем больше географическое разделение, тем выше надежность.
Задайте целевую точку восстановления (RPO). RPO определяет максимальную допустимую потерю данных во время сбоя, определяя частоту реплика данных. Например, RPO за один час означает принятие до часа потери данных.
Реализуйте реплика данных. Выравнивание реплика данных с архитектурой и RPO. Azure обычно поддерживает синхронную реплика tion в зонах доступности. Использование нескольких зон для упрощения повышения надежности. Для веб-приложений с несколькими регионами в активно-пассивной установке реплика te data to the passive region as per the web app's RPO, гарантируя, что частота реплика tion превышает RPO. Для конфигураций "активный— активный" требуется синхронизация данных в режиме реального времени в разных регионах, что может потребовать корректировки кода.
Создайте план отработки отказа. Разработка плана отработки отказа (аварийного восстановления) для определения стратегий реагирования на сбои, определяемых временем простоя или потерей функциональных возможностей. Укажите цели времени восстановления (RTO) для максимально допустимого времени простоя. Убедитесь, что процесс отработки отказа быстрее RTO. Определите механизмы автоматической или ручной отработки отказа для согласованности и управления, а также подробно о возвращении к обычному процессу операций. Проверьте план отработки отказа, чтобы обеспечить эффективность.
Пример. Для База данных Azure для PostgreSQL эталонная реализация использует избыточность между зонами высокой доступности с резервными серверами в двух зонах доступности. База данных также асинхронно реплика tes к реплика чтения в пассивном регионе.
Следующий шаг
В этой статье показано, как спланировать реализацию шаблона Reliable Web App. Следующим шагом является применение методов реализации шаблона Reliable Web App.