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

  • Статья

Термин вычислительная служба означает модель размещения вычислительных ресурсов, которые используются для выполнения приложения. Для архитектуры микрослужб особенно популярными являются два подхода:

  • Служба оркестратора, которая управляет службами, выполняющимися на выделенных узлах (виртуальных машинах).
  • Бессерверная архитектура, которая использует функции как услугу (FaaS).

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

Оркестраторы служб

Оркестратор выполняет задачи, связанные с развертыванием набора служб и управлением ним. К этим задачам относятся размещение служб на узлах, мониторинг состояния работоспособности служб, перезапуск неработоспособных служб, балансировка нагрузки сетевого трафика между экземплярами службы, обнаружение служб, масштабирование количества экземпляров службы и применение обновления конфигурации. Среди популярных оркестраторов можно назвать Kubernetes, Service Fabric, DC/OS и Docker Swarm.

Для платформы Azure мы рекомендуем рассмотреть следующие варианты:

  • Azure Kubernetes Service (AKS) — это управляемая служба Kubernetes. AKS реализует среду Kubernetes и предоставляет конечные точки API Kubernetes, а также содержит и администрирует плоскость управления Kubernetes, выполняя автоматические обновления, автоматическое исправление, автомасштабирование и другие задачи управления. Вы можете думать об AKS как о "программных интерфейсах API Kubernetes как услуге".

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

  • Service Fabric — это платформа распределенных систем для упаковки и развертывания микрослужб, а также управления ими. Микрослужбы могут быть развернуты в Service Fabric в виде контейнеров, исполняемых двоичных файлов или Reliable Services. Используя модель программирования Reliable Services, службы могут напрямую использовать API программирования Service Fabric, чтобы отправлять запросы к системе, формировать отчеты о состоянии, получать уведомления об изменениях конфигурации и кода, а также обнаруживать другие службы. Ключевое отличие Service Fabric — активная ориентация на создание служб с отслеживанием состояния с использованием Reliable Collections.

  • Другие параметры, такие как Docker выпуск Enterprise, могут выполняться в среде IaaS в Azure. Шаблоны развертывания можно найти на Azure Marketplace.

Контейнеры

Иногда о контейнерах и микрослужбах говорят так, как будто это одно и то же. Хотя это не так— контейнеры не нужны для создания микрослужб, контейнеры имеют некоторые преимущества, особенно относящиеся к микрослужбам, например:

  • Мобильность. Образ контейнера представляет собой изолированный пакет, для запуска которого не нужно устанавливать библиотеки или другие зависимости. Благодаря этому их легче развертывать. Контейнеры можно быстро запустить и остановить, что позволяет развернуть новые экземпляры, чтобы обрабатывать большую нагрузку или восстанавливаться после сбоев узлов.

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

  • Изоляция ресурсов. Вы можете ограничить объем ресурсов памяти и ЦП, которые доступны для контейнера, чтобы неконтролируемый процесс не исчерпал ресурсы узла. См. дополнительные сведения о шаблоне отсеков.

Бессерверная архитектура (функции как услуга)

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

Функции Azure — это независимая от сервера служба вычислений, которая поддерживает различные триггеры функций, в том числе HTTP-запросы, очереди служебной шины и события Центров событий. Полный список см. в статье Основные понятия триггеров и привязок в Функциях Azure. Также рассмотрите возможность использования Сетки событий Azure. Это управляемая служба маршрутизации событий в Azure.

Архитектура с оркестрацией или независимая от сервера

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

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

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

Мобильность. Все перечисленные здесь оркестраторы (Kubernetes, DC/OS, Docker Swarm и Service Fabric) могут работать в локальной среде или в нескольких общедоступных облаках.

Интеграция приложений. Создание сложного приложения с использованием бессерверной архитектуры может быть сложной задачей из-за необходимости координировать, развертывать и управлять множеством небольших независимых функций. Единственным вариантом в Azure является использование Azure Logic Apps для координации набора функций Azure. Пример этого подхода см. в статье Создание функции, которая интегрируется с Azure Logic Apps.

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

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

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

Дальнейшие действия

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