Выбор варианта вычислений Azure для микрослужб

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

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

Вычислительные платформы Azure для микрослужб

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

Служба Azure Kubernetes (AKS)

Служба Azure Kubernetes (AKS) — это управляемая служба Kubernetes, которая предоставляет прямой доступ к API Kubernetes и плоскости управления. AKS предоставляет управление узлами, установку исправлений и автоматические обновления по желанию. Вы настраиваете политики кластера, сети и масштабирования.

Для микрослужб AKS поддерживает сетки служб, такие как Istio для управления трафиком и взаимной безопасности транспортного уровня (mTLS), масштабирование для отдельных развертываний с помощью горизонтального автомасштабирования Pod (HPA) и автоматического масштабирования на основе событий Kubernetes (KEDA), а также стратегии развертывания, родные для Kubernetes, такие как последовательные обновления и канарские выпуски.

AKS Automatic — это режим AKS, который предварительно настраивает управление узлами, масштабирование, безопасность и наблюдаемость на основе хорошо спроектированных рекомендаций AKS, поэтому команды получают готовый к работе кластер без настройки возможностей.

Приложения-контейнеры Azure

Приложения контейнеров Azure — это управляемая служба, основанная на Kubernetes, которая абстрагирует управление кластерами.

Контейнерные приложения предоставляют встроенные функции для микрослужб, включая обнаружение служб, интеграцию Dapr для вызова между службами с MTLS, обмен сообщениями подписчика издателя и управление состоянием. Автомасштабирование на основе KEDA позволяет масштабировать на основе событий, включая масштабирование до нуля. Контейнерные приложения также поддерживают разделение трафика среди версий для канарного развертывания и заданий на выполнение по запросу, по расписанию или при возникновении событий.

Приложения-контейнеры не предоставляют API Kubernetes. Если конфигурация средств развертывания или сетки служб зависит от примитивов Kubernetes, используйте AKS.

Функции Azure

Функции Azure — это бессерверная служба вычислений на основе событий, предназначенная для микрослужб, которые отвечают на триггеры, такие как HTTP-запросы, сообщения очереди или таймеры. Функций масштабирует каждое функциональное приложение независимо и может масштабироваться до нулевого уровня. Для микрослужб разверните каждую службу в качестве собственного приложения-функции.

Функции не обеспечивают обнаружение служб на уровне платформы или взаимодействие между службами. Реализуйте эти возможности в коде приложения или через внешние службы, такие как управление API Azure.

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

Служба приложений Azure

Служба приложений Azure подходит для микрослужб на основе HTTP, таких как веб-API. Служба приложений поддерживает развертывание в виде кода или в виде одного контейнера. Он обеспечивает встроенное автомасштабирование, слоты развертывания для blue-green развертывания и процентную маршрутизацию трафика, а также интеграцию с конвейерами непрерывной интеграции и доставки (CI/CD). Служба приложений не предоставляет обнаружение служб, поэтому она подходит для микрослужб, которые взаимодействуют через внешние сообщения или шлюз API, а не используют взаимодействие между службами на уровне платформы.

Azure Red Hat OpenShift

Azure Red Hat OpenShift предоставляет полностью управляемые кластеры OpenShift и расширяет возможности Kubernetes, предоставляя ориентированную на разработчиков среду. Red Hat и Корпорация Майкрософт совместно работают и поддерживают службу. Используйте Azure Red Hat OpenShift, если ваша организация стандартизируется на OpenShift.

Сравнение платформ для микрослужб

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

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

Выберите платформу

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

• Выберите AKS , если вам нужен прямой доступ к API Kubernetes, настройка пользовательской сетки служб или более точное управление инфраструктурой кластера, такими как пулы узлов, сетевые политики или ограничения планирования.

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

• Используйте службу приложений для простых служб на основе HTTP, которые не нуждаются в обнаружении служб на уровне платформы или взаимодействия между службами.

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

Ключевые факторы принятия решений

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

Обмен данными между службами

Микрослужбы зависят от надежного взаимодействия между службами с возможностями, такими как обнаружение служб, повторные попытки и mTLS.

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

Если службы взаимодействуют главным образом с помощью асинхронных сообщений, таких как очереди или потоки событий, встроенные функции связи платформы имеют меньше значения, так как необходимо взаимодействовать с этими службами с помощью пакета SDK или абстракции. Используйте асинхронный паттерн Request-Reply для длительных операций, так как время ожидания платформы может стать проблемой. Например, службы Azure Functions и App Service налагают ограничение на время ожидания ответа HTTP в 230 секунд из-за ограничений Azure Load Balancer.

Независимое масштабирование

Каждая микрослужба в композиции имеет разные характеристики нагрузки.

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

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

Если ваши службы имеют устойчивую и прогнозируемую нагрузку, AKS или служба приложений может снизить затраты, так как вы оплачиваете зарезервированную емкость вместо выставления счетов на основе потребления.

Независимое развертывание

Необходимо развернуть, обновить и вернуть обратно отдельные микрослужбы, не затрагивая остальную часть системы. Все четыре платформы поддерживают независимую возможность развертывания, но отличаются способом проверки изменений. Приложения контейнеров и AKS обеспечивают разделение трафика в собственном коде для постепенного развертывания. Служба приложений поддерживает маршрутизацию трафика с использованием процентного распределения между слотами развертывания. Сервис "Функции" поддерживает слоты развертывания на планах "Премиум" и "Выделенный".

Распределенная наблюдаемость

Один запрос пользователя может пройти через множество служб. Если вам нужны коррелированные трассировки в полной цепочке вызовов, убедитесь, что средства отслеживания платформы интегрируются с стратегией трассировки. Контейнерные приложения обеспечивают встроенные возможности наблюдения с использованием трассировки Dapr. AKS интегрируется с OpenTelemetry и инструментами трассировки с открытым исходным кодом, что позволяет выбрать бэкэнд трассировки (например, Jaeger, Zipkin или Azure Monitor), но требует развертывания и настройки конвейера сбора. Функции и служба приложений интегрируются с Application Insights для сквозной трассировки транзакций с минимальной конфигурацией.

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

Управление состоянием

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

Платформы различаются, если служба нуждается в абстракции состояния, управляемом платформой, например шаблонов на основе субъектов, оркестрации рабочих процессов или выделенного хранилища для каждого экземпляра:

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

• Контейнерные приложения поддерживают подключение томов и управление состоянием Dapr, включая субъектов Dapr.

• Функции поддерживают оркестрацию с отслеживанием состояния и сущности с помощью устойчивых функций.

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

Рекомендации

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

Надежность

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

В архитектуре микрослужб основной риск надежности — каскадный сбой. Одна неработоспособная служба приводит к тому, что вызывающие абоненты накапливают время ожидания, и проблема распространяется наружу через цепочку вызовов. Выбор платформы влияет на то, как вы устраняете этот риск.

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

• Функции повторно выполняют неудачные операции в зависимости от типа триггера.

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

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

Рекомендации по надежности для конкретной платформы см. в разделах о надежности руководств по службе Well-Architected Framework для AKS, приложений контейнеров и функций.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

Микрослужбы увеличивают область атаки, так как каждый вызов между службами пересекает границу сети. Обрабатывать весь трафик между службами как ненадежный и шифровать его с помощью mTLS. AKS поддерживает mTLS через сетки служб, такие как Istio. Контейнерные приложения предоставляют mTLS через Dapr или конфигурацию на уровне среды. Функции и служба приложений не предоставляют MTLS уровня платформы. Если эти платформы размещают службы в вашей структуре, примените безопасность передачи данных через HTTPS на уровне приложений, политики шлюза API или изоляцию виртуальной сети.

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

Инструкции по безопасности для конкретной платформы см. в разделах о безопасности руководств по службе Well-Architected Framework для AKS, приложений контейнеров и функций.

Оптимизация затрат

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

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

Рекомендации по затратам для конкретной платформы см. в разделах оптимизации затрат в руководствах по службе Well-Architected Framework для AKS, приложений контейнеров и функций.

Эталонные архитектуры

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

• Архитектура AKS:Базовая архитектура для кластера AKS
• Контейнерные приложения:микросервисы с контейнерными приложениями и Dapr
• Служба приложений:базовое высокодоступное зонально-резервируемое веб-приложение
• Azure Red Hat OpenShift:Azure Red Hat OpenShift в гибридной среде

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

Связанные ресурсы

• Проектирование архитектуры микрослужб
• Проектирование API для микрослужб
• Использование анализа домена для моделирования микрослужб
• Выберите вычислительную службу Azure
• Выберите службу контейнеров Azure
• Архитектурные рекомендации по выбору службы контейнеров Azure