Эта архитектура содержит рекомендации по проектированию критически важных рабочих нагрузок в Azure. В нем используются собственные возможности облака для повышения надежности и эффективности работы. Он применяет методологию проектирования для критически важных рабочих нагрузок, важных для архитектуры, к приложению с доступом к Интернету, где рабочая нагрузка осуществляется через общедоступную конечную точку и не требует подключения частной сети к другим ресурсам компании.
Важно!
Руководство поддерживается примером реализации производственного класса, демонстрирующей критически важные разработки приложений в Azure. Эту реализацию можно использовать в качестве основы для дальнейшего развития решений на первом шаге к рабочей среде.
Уровень надежности
Надежность является относительной концепцией, и для рабочей нагрузки, соответствующей надежности, она должна отражать бизнес-требования, связанные с ним, включая цели уровня обслуживания (SLO) и соглашения об уровне обслуживания (SLA), чтобы захватить процент времени, когда приложение должно быть доступно.
Эта архитектура ориентирована на SLO 99,99%, что соответствует разрешенной ежегодной простой в 52 минутах и 35 секундах. Поэтому все охватываемые решения по проектированию предназначены для достижения этого целевого SLO.
Совет
Чтобы определить реалистичный SLO, важно понимать соглашение об уровне обслуживания всех компонентов Azure в архитектуре. Эти отдельные числа следует агрегировать, чтобы определить составное соглашение об уровне обслуживания , которое должно соответствовать целевым целям рабочей нагрузки.
Ознакомьтесь с критически важными рабочими нагрузками: проектирование бизнес-требований.
Основные стратегии проектирования
Многие факторы могут повлиять на надежность приложения, например возможность восстановления после сбоя, региональной доступности, эффективности развертывания и безопасности. Эта архитектура применяет набор стратегий проектирования, предназначенных для решения этих факторов и обеспечения достижения целевого уровня надежности.
Избыточность на слоях
Развертывание в нескольких регионах в активной модели. Приложение распределяется между двумя или несколькими регионами Azure, обрабатывающими активный трафик пользователей.
Используйте Зоны доступности (AZ) для всех рассмотренных служб, чтобы максимально повысить доступность в одном регионе Azure, распределяя компоненты между физическими центрами обработки данных внутри региона.
Выберите ресурсы, поддерживающие глобальное распределение.
Ознакомьтесь с критически важными рабочими нагрузками: глобальное распределение.
Метки развертывания
Разверните региональную метку в виде единицы масштабирования, где логический набор ресурсов можно независимо подготовить для обеспечения соответствия требованиям. Каждая метка также применяет несколько вложенных единиц масштабирования, таких как интерфейсные API и фоновые процессоры, которые могут масштабироваться и выходить независимо.
Ознакомьтесь с критически важными рабочими нагрузками: архитектура единиц масштабирования.
Надежные и повторяемые развертывания
Примените принцип инфраструктуры как кода (IaC) с помощью технологий, таких как Terraform, для обеспечения управления версиями и стандартизованного операционного подхода для компонентов инфраструктуры.
Реализуйте конвейеры простоя синего и зеленого развертывания. Конвейеры сборки и выпуска должны быть полностью автоматизированы для развертывания меток в виде одной операционной единицы с использованием синих и зеленых развертываний с применением непрерывной проверки.
Применение согласованности среды во всех рассмотренных средах с одинаковым кодом конвейера развертывания в рабочих и предустановленных средах. Это устраняет риски, связанные с вариантами развертывания и процесса в разных средах.
Непрерывная проверка путем интеграции автоматизированного тестирования в рамках процессов DevOps, включая синхронизированное тестирование нагрузки и хаоса, чтобы полностью проверить работоспособность кода приложения и базовой инфраструктуры.
Ознакомьтесь с критически важными рабочими нагрузками: развертывание и тестирование.
Оперативная аналитика
Имеют федеративные рабочие области для данных наблюдаемости. Данные мониторинга для глобальных ресурсов и региональных ресурсов хранятся независимо. Централизованное хранилище наблюдаемости не рекомендуется избежать одной точки сбоя. Запросы между рабочими областями используются для достижения единого приемника данных и одной панели стекла для операций.
Создайте многоуровневую модель работоспособности, которая сопоставляет работоспособности приложений с моделью светофора для контекстуализации. Оценки работоспособности вычисляются для каждого отдельного компонента, а затем агрегируются на уровне потока пользователя и в сочетании с ключевыми нефункциональными требованиями, такими как производительность, как коэффициенты для вычисления работоспособности приложения.
Ознакомьтесь с критически важными рабочими нагрузками: моделирование работоспособности.
Архитектура
*Скачайте файл Visio этой архитектуры.
Компоненты этой архитектуры могут быть широко классифицированы таким образом. Документация по продуктам о службах Azure см. в разделе "Связанные ресурсы".
Глобальные ресурсы
Глобальные ресурсы являются долгой жизнью и делятся временем существования системы. Они могут быть глобально доступны в контексте модели развертывания с несколькими регионами.
Ниже приведены общие рекомендации по компонентам. Подробные сведения о решениях см. в разделе "Глобальные ресурсы".
Глобальная подсистема балансировки нагрузки
Глобальная подсистема балансировки нагрузки крайне важна для надежной маршрутизации трафика в региональные развертывания с некоторыми уровнями гарантии на основе доступности внутренних служб в регионе. Кроме того, этот компонент должен иметь возможность проверки трафика входящего трафика, например через брандмауэр веб-приложения.
Azure Front Door используется в качестве глобальной точки входа для всего входящего трафика HTTP(S) клиента, с возможностями Брандмауэр веб-приложений (WAF), применяемыми к защищенному трафику уровня 7. Он использует ПРОТОКОЛ TCP Anycast для оптимизации маршрутизации с помощью магистральной сети Майкрософт и обеспечивает прозрачную отработку отказа в случае ухудшения региональной работоспособности. Маршрутизация зависит от пользовательских проб работоспособности, которые проверка составной хит ключевых региональных ресурсов. Azure Front Door также предоставляет встроенную сеть доставки содержимого (CDN) для кэширования статических ресурсов для компонента веб-сайта.
Другой вариант — Диспетчер трафика, который является подсистемой балансировки нагрузки уровня 4 на основе DNS. Однако сбой не является прозрачным для всех клиентов, так как распространение DNS должно произойти.
Ознакомьтесь с критически важными рабочими нагрузками: глобальная маршрутизация трафика.
База данных
Все состояние, связанное с рабочей нагрузкой, хранится во внешней базе данных Azure Cosmos DB для NoSQL. Этот параметр был выбран, так как он имеет набор компонентов, необходимый для настройки производительности и надежности, как на стороне клиента, так и на сервере. Настоятельно рекомендуется, чтобы учетная запись с несколькими узлами была включена.
Примечание.
Хотя конфигурация записи с несколькими регионами представляет золотой стандарт для надежности, существует значительный компромисс по затратам, которые следует должным образом учитывать.
Учетная запись реплика с каждой региональной меткой, а также включает зональную избыточность. Кроме того, автомасштабирование включается на уровне контейнера, чтобы контейнеры автоматически масштабировали подготовленную пропускную способность по мере необходимости.
Дополнительные сведения см. в разделе "Платформа данных" для критически важных рабочих нагрузок.
Ознакомьтесь с критически важными рабочими нагрузками: глобально распределенное хранилище данных с несколькими записями.
Реестр контейнеров
Реестр контейнеров Azure используется для хранения всех образов контейнеров. Он имеет возможности геоизбыточного реплика, позволяющие ресурсам функционировать в качестве одного реестра, обслуживая несколько регионов с несколькими главными региональными реестрами.
В качестве меры безопасности разрешить доступ только к необходимым сущностям и пройти проверку подлинности этого доступа. Например, в реализации доступ администратора отключен. Таким образом, вычислительный кластер может извлекать изображения только с назначениями ролей Microsoft Entra.
Ознакомьтесь с критически важными рабочими нагрузками: реестр контейнеров.
Региональные ресурсы
Региональные ресурсы подготавливаются в рамках метки развертывания в одном регионе Azure. Эти ресурсы не используют ресурсы в другом регионе. Их можно удалить независимо или реплика в дополнительные регионы. Однако они совместно используют глобальные ресурсы друг друга.
В этой архитектуре единый конвейер развертывания развертывает метку с этими ресурсами.
Ниже приведены общие рекомендации по компонентам. Подробные сведения о решениях см. в разделе "Региональные ресурсы меток".
Внешний интерфейс
Эта архитектура использует одностраничное приложение (SPA), которое отправляет запросы в серверные службы. Преимущество заключается в том, что вычислительные ресурсы, необходимые для веб-сайта, загружаются клиенту вместо серверов. Spa размещается как статический веб-сайт в учетной записи служба хранилища Azure.
Другим вариантом является Статические веб-приложения Azure, который содержит дополнительные рекомендации, такие как предоставление сертификатов, подключение к глобальной подсистеме балансировки нагрузки и другие факторы.
Статическое содержимое обычно кэшируется в хранилище, близком к клиенту, с помощью сети доставки содержимого (CDN), чтобы данные можно было быстро обслуживать без прямого взаимодействия с внутренними серверами. Это экономичный способ повышения надежности и уменьшения задержки сети. В этой архитектуре встроенные возможности CDN Azure Front Door используются для кэширования статического содержимого веб-сайта в пограничной сети.
Вычислительный кластер
Серверное вычисление запускает приложение, состоящее из трех микрослужб и является бессерверным. Таким образом, контейнеризация — это соответствующая стратегия размещения приложения. Служба Azure Kubernetes (AKS) был выбран, так как он соответствует большинству бизнес-требований и Kubernetes широко применяется во многих отраслях. AKS поддерживает расширенные топологии масштабируемости и развертывания. Для размещения критически важных приложений рекомендуется использовать уровень обслуживания AKS uptime, так как он обеспечивает гарантии доступности для уровня управления Kubernetes.
Azure предлагает другие вычислительные службы, такие как Функции Azure и службы приложение Azure. Эти варианты выгружают дополнительные обязанности по управлению в Azure за счет гибкости и плотности.
Примечание.
Избегайте хранения состояния в вычислительном кластере, учитывая эфемерный характер меток. Как можно больше, сохраняйте состояние во внешней базе данных, чтобы обеспечить упрощение операций масштабирования и восстановления. Например, в AKS модули pod часто изменяются. Присоединение состояния к модулям pod приведет к добавлению нагрузки на согласованность данных.
Ознакомьтесь с критически важными рабочими нагрузками: Оркестрация контейнеров и Kubernetes.
Региональный брокер сообщений
Чтобы оптимизировать производительность и поддерживать скорость реагирования во время пиковой нагрузки, проект использует асинхронное обмен сообщениями для обработки интенсивных системных потоков. Так как запрос быстро подтверждается обратно в интерфейсные API, запрос также помещается в очередь в брокер сообщений. Эти сообщения впоследствии используются серверной службой, которая, например, обрабатывает операцию записи в базу данных.
Вся метка без отслеживания состояния, за исключением определенных точек, таких как брокер сообщений. Данные помещается в очередь брокера в течение короткого периода времени. Брокер сообщений должен гарантировать по крайней мере один раз доставки. Это означает, что сообщения будут находиться в очереди, если брокер становится недоступным после восстановления службы. Тем не менее, это ответственность потребителя, чтобы определить, нужны ли эти сообщения обработке. Очередь удаляется после обработки сообщения и хранения в глобальной базе данных.
В этой структуре используется Центры событий Azure. Дополнительная учетная запись служба хранилища Azure подготовлена для проверка назначения. Центры событий — это рекомендуемый вариант для вариантов использования, требующих высокой пропускной способности, например потоковой передачи событий.
Для вариантов использования, требующих дополнительных гарантий сообщений, рекомендуется Служебная шина Azure. Он позволяет выполнять двухфазные фиксации с клиентским курсором, а также функции, такие как встроенная очередь недоставленных писем и возможности дедупликации.
Дополнительные сведения см. в разделе "Службы обмена сообщениями" для критически важных рабочих нагрузок.
Ознакомьтесь с критически важными рабочими нагрузками: архитектура, связанная с событиями.
Региональное хранилище секретов
Каждая метка имеет собственный Azure Key Vault , который хранит секреты и конфигурацию. Существуют общие секреты, такие как строка подключения в глобальную базу данных, но есть также информация, уникальная для одной метки, например центры событий строка подключения. Кроме того, независимые ресурсы избегают одной точки сбоя.
Ознакомьтесь с критически важными рабочими нагрузками: защита целостности данных.
Конвейер развертывания
Конвейеры сборки и выпуска для критически важных приложений должны быть полностью автоматизированы. Поэтому никаких действий не нужно выполнять вручную. Эта конструкция демонстрирует полностью автоматизированные конвейеры, которые развертывают проверенную метку последовательно каждый раз. Другой альтернативный подход заключается в развертывании только последовательного обновления для существующей метки.
Репозиторий исходного кода
GitHub используется для управления версиями, предоставляя высокодоступную платформу на основе Git для совместной работы с кодом приложения и кодом инфраструктуры.
Конвейеры непрерывной интеграции и непрерывной доставки (CI/CD)
Автоматизированные конвейеры необходимы для создания, тестирования и развертывания рабочей нагрузки миссии в предварительной и рабочей средах. Azure Pipelines выбирается с помощью набора средств с широкими возможностями, предназначенными для Azure и других облачных платформ.
Другим выбором является GitHub Actions для конвейеров CI/CD. Добавленное преимущество заключается в том, что исходный код и конвейер можно сопоставить. Тем не менее, Azure Pipelines был выбран из-за более широких возможностей CD.
Ознакомьтесь с критически важными рабочими нагрузками: DevOps.
Агенты сборки
Агенты сборки, размещенные корпорацией Майкрософт, используются этой реализацией для снижения сложности и затрат на управление. Локальные агенты можно использовать для сценариев, для которых требуется защищенное состояние безопасности.
Примечание.
Использование локальных агентов демонстрируется в реализации Подключение эталонной реализации Подключение.
Ресурсы для наблюдения
Операционные данные из приложения и инфраструктуры должны быть доступны для обеспечения эффективных операций и максимальной надежности. Эта ссылка предоставляет базовые показатели для обеспечения целостной наблюдаемости приложения.
Единый приемник данных
- Azure Log Analytics используется в качестве единого приемника для хранения журналов и метрик для всех компонентов приложения и инфраструктуры.
- приложение Azure Аналитика используется в качестве средства управления производительностью приложений (APM) для сбора всех данных мониторинга приложений и хранения его непосредственно в Log Analytics.
Данные мониторинга глобальных ресурсов и региональных ресурсов должны храниться независимо. Единое централизованное хранилище наблюдаемости не рекомендуется избежать одной точки сбоя. Запросы между рабочими областями используются для достижения одной панели стекла.
В этой архитектуре ресурсы мониторинга в регионе должны быть независимыми от самой метки, так как если вы сломите метку, вы все равно хотите сохранить наблюдаемость. Каждая региональная метка имеет собственную выделенную Аналитика приложения и рабочую область Log Analytics. Ресурсы подготавливаются для каждого региона, но они выходят за пределы меток.
Аналогичным образом данные из общих служб, таких как Azure Front Door, Azure Cosmos DB и реестр контейнеров, хранятся в выделенном экземпляре рабочей области Log Analytics.
Архивация данных и аналитика
Операционные данные, которые не требуются для активных операций, экспортируются из Log Analytics в служба хранилища Azure учетные записи как для хранения данных, так и для предоставления аналитического источника для AIOps, который можно применить для оптимизации модели работоспособности приложений и операционных процедур.
Ознакомьтесь с критически важными рабочими нагрузками: прогнозные действия и операции искусственного интеллекта.
Потоки запросов и процессора
На этом изображении показан поток запроса и фонового процессора эталонной реализации.
Описание этого потока представлено в следующих разделах.
Поток запросов веб-сайта
Запрос веб-интерфейса пользователя отправляется в глобальную подсистему балансировки нагрузки. Для этой архитектуры глобальный балансировщик нагрузки — Azure Front Door.
Вычисляются правила WAF. Правила WAF положительно влияют на надежность системы путем защиты от различных атак, таких как межсайтовые скрипты (XSS) и внедрение SQL. Azure Front Door возвращает ошибку запрашивающей стороне, если правило WAF нарушается и обработка останавливается. Если правила WAF не нарушены, Azure Front Door продолжает обработку.
Azure Front Door использует правила маршрутизации для определения серверного пула для пересылки запроса. Как запросы соответствуют правилу маршрутизации. В этой эталонной реализации правила маршрутизации позволяют Azure Front Door направлять запросы пользовательского интерфейса и интерфейсного API на разные серверные ресурсы. В этом случае шаблон "/*" соответствует правилу маршрутизации пользовательского интерфейса. Это правило направляет запрос в внутренний пул, содержащий учетные записи хранения со статическими веб-сайтами, на которых размещено одностраничное приложение (SPA). Azure Front Door использует приоритет и вес, назначенные серверным службам в пуле, чтобы выбрать серверную часть для маршрутизации запроса. Методы маршрутизации трафика в источник. Azure Front Door использует пробы работоспособности, чтобы гарантировать, что запросы не направляются в серверные серверы, которые не являются работоспособными. Spa обслуживается из выбранной учетной записи хранения со статическим веб-сайтом.
Примечание.
Термины серверные пулы и серверные серверы в Azure Front Door Classic называются группами источников и источниками в Azure Front Door уровня "Стандартный" или "Премиум".
Spa выполняет вызов API к узлу интерфейсного интерфейса Azure Front Door. Шаблон URL-адреса запроса API — "/api/*".
Поток запросов интерфейсного API
Правила WAF оцениваются как на шаге 2.
Azure Front Door соответствует запросу правилу маршрутизации API по шаблону "/api/*". Правило маршрутизации API направляет запрос в внутренний пул, содержащий общедоступные IP-адреса для контроллеров Ingress NGINX, которые знают, как направлять запросы в правильную службу в Служба Azure Kubernetes (AKS). Как и раньше, Azure Front Door использует приоритет и вес, назначенные серверным службам, для выбора правильной серверной части контроллера входящего трафика NGINX.
Для запросов GET интерфейсный API выполняет операции чтения в базе данных. Для этой эталонной реализации база данных — это глобальный экземпляр Azure Cosmos DB. Azure Cosmos DB имеет несколько функций, которые делают его хорошим выбором для критически важных рабочих нагрузок, включая возможность легко настраивать регионы с несколькими записью, что позволяет автоматически выполнять отработку отказа для операций чтения и записи в вторичные регионы. API использует клиентский пакет SDK, настроенный с логикой повторных попыток для взаимодействия с Azure Cosmos DB. Пакет SDK определяет оптимальный порядок доступных регионов Azure Cosmos DB для взаимодействия с учетом параметра ApplicationRegion.
Для запросов POST или PUT интерфейсный API выполняет запись в брокер сообщений. В эталонной реализации брокер сообщений Центры событий Azure. Кроме того, можно выбрать служебная шина. Обработчик позже считывает сообщения из брокера сообщений и выполняет все необходимые операции записи в Azure Cosmos DB. API использует клиентский пакет SDK для выполнения операций записи. Клиент можно настроить для повторных попыток.
Фоновый поток процессора
Фоновые процессоры обрабатывают сообщения от брокера сообщений. Фоновые процессоры используют клиентский пакет SDK для выполнения операций чтения. Клиент можно настроить для повторных попыток.
Фоновые процессоры выполняют соответствующие операции записи в глобальном экземпляре Azure Cosmos DB. Фоновые процессоры используют клиентский пакет SDK, настроенный для повторного подключения к Azure Cosmos DB. Список предпочтительных регионов клиента можно настроить с несколькими регионами. В этом случае при сбое записи повтор будет выполнен в следующем предпочтительном регионе.
Области проектирования
Мы рекомендуем изучить эти области проектирования для рекомендаций и рекомендаций при определении критически важной архитектуры.
| Область проектирования | Description |
|---|---|
| Проектирование приложений | Шаблоны проектирования, позволяющие масштабировать и обрабатывать ошибки. |
| Платформа приложений | Варианты и способы устранения рисков инфраструктуры для потенциальных случаев сбоя. |
| Платформа данных | Выбор в технологиях хранилища данных, информированный оценкой необходимых объемов, скоростей, разнообразием и характеристиками достоверности. |
| Сеть и подключение | Рекомендации по маршрутизации входящего трафика на метки. |
| Моделирование работоспособности | Аспекты наблюдаемости с помощью анализа влияния клиента коррелируют мониторинг, чтобы определить общую работоспособность приложения. |
| Развертывание и тестирование | Стратегии для конвейеров CI/CD и рекомендаций по автоматизации с включенными сценариями тестирования, такими как синхронизированное тестирование нагрузки и тестирование внедрения сбоев (хаос). |
| Безопасность | Устранение векторов атак с помощью модели Microsoft Zero Trust. |
| Операционные процедуры | Процессы, связанные с развертыванием, управлением ключами, исправлением и обновлениями. |
** Указывает рекомендации по области разработки, относящиеся к этой архитектуре.
Связанные ресурсы
Документацию по продуктам в службах Azure, используемых в этой архитектуре, см. в следующих статьях.
- Azure Front Door
- Azure Cosmos DB
- Реестр контейнеров Azure;
- Мониторинг базы данных SQL Azure с помощью служб анализа SQL Azure (предварительная версия) в Log Analytics.
- Azure Key Vault
- Служебная шина Azure
- Служба Azure Kubernetes (AKS)
- Azure Application Insights
- Центры событий Azure
- Хранилище BLOB-объектов Azure
Развертывание архитектуры
Разверните эталонную реализацию, чтобы получить полное представление о рассмотренных ресурсах, в том числе о том, как они работают в критически важном контексте. В нем содержится руководство по развертыванию, предназначенное для иллюстрации подхода, ориентированного на решение для разработки критически важных приложений в Azure.
Следующие шаги
Если вы хотите расширить базовую архитектуру с сетевыми элементами управления для входящего и исходящего трафика, см. эту архитектуру.