Вы наверняка много раз слышали о service mesh и  API-шлюзе применительно к микросервисам. Их часто путают. В этой статье мы подробно поговорим о двух этих инструментах, а также разберемся, когда их лучше использовать и что будет, если их объединить.

Уровни сетевой модели OSI

Для начала давайте вспомним уровни сетевой модели OSI:

Они понадобятся нам дальше.

Service mesh

Service mesh — это технология, которая управляет взаимодействием между сервисами в распределённой системе. Service mesh отвечает за горизонтальный трафик (east-west) внутри дата-центра, кластера Kubernetes или распределённой системы.

Service mesh состоит из двух основных компонентов: control plane и data plane. 

Прокси рядом с приложением считаются data plane, а административные компоненты, регулирующие поведение этих прокси, называются control plane.

С помощью service mesh мы отделяем бизнес-логику приложения от задач по обеспечению взаимодействия, надёжности, безопасности и наблюдаемости.

Сетевое взаимодействие и управление трафиком

Service mesh поддерживает динамическое обнаружение сервисов. Sidecar-прокси берет на себя балансировку нагрузки и ограничение скорости. Он поможет разделить трафик для A/B-тестирования при канареечных развёртываниях.

Наблюдаемость и надёжность

Service mesh поддерживает распределённую трассировку для отладки и расширенного мониторинга (число запросов, процент успешных запросов и задержки). Она даже может изучать взаимодействие между сервисами.

Service mesh предоставляет проверки работоспособности, повторные запросы, таймауты и размыкание цепи (curcuit breaking), а значит повышает надёжность приложения.

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

Service mesh поддерживает mTLS между сервисами, чтобы повысить безопасность взаимодействия на этом уровне. Мы также можем реализовать списки контроля доступа (access control list, ACL) в качестве политик безопасности.

Полноценная service mesh с sidecar-прокси поддерживает широкий ряд сервисов и реализует политики трафика на уровнях L4/L7.

На рынке доступно несколько реализаций service mesh, например:

• Istio

• Linkerd

• Kuma

• Consul

В интернете можно найти немало статей, где сравниваются эти реализации.

API-шлюз

API-шлюз выступает как единая точка входа в кластер, ЦОД или группу распределённых сервисов. В топологии сети это называется вертикальным (north-south) трафиком. Обычно в эту категорию входит трафик мобильных клиентов.

Также с помощью API-шлюзов можно наладить коммуникации между двумя продуктами, развёрнутыми в одном ЦОДе. В этом случае трафик будет горизонтальным.

API-шлюз принимает вызовы от клиентов и перенаправляет их к соответствующим сервисам. При этом он может преобразовывать протоколы.

API-шлюз даёт разные преимущества:

• Абстракция. API-шлюз абстрагирует сложности микросервисов и предлагает клиентам единообразный интерфейс для взаимодействия.

• Аутентификация. API-шлюз обрабатывает аутентификацию и передаёт сервисам информацию о токенах.

• Контроль трафика. API-шлюз регулирует входящий и исходящий трафик API.

• Мониторинг и монетизация API. Если вы планируете монетизировать свои API, API-шлюз предоставляет возможности мониторинга запросов и ответов API.

• Преобразования. API-шлюз помогает преобразовывать запросы и ответы API, а также протоколы.

API-шлюзы обычно работают только с политиками на L7.

Типы API-шлюзов

С точки зрения развёртывания, API-шлюзы можно использовать двумя способами:

• Внутренний API-шлюз выступает как шлюз для группы сервисов или внутри продукта.

• Внешний API-шлюз работает с внешними потребителями или мобильными клиентами организации.

На рынке существует множество API-шлюзов, например:

• Apigee

• Kong Gateway

• API-шлюз от NGINX

• API-шлюз от Software AG

Когда использовать service mesh, а когда API-шлюз

Понимая, как работают эти две технологии, давайте подумаем, как выбирать между ними

Когда использовать service mesh

• Когда нам нужна безопасность и мониторинг коммуникаций на уровнях L4/L7 внутри одного продукта.

• Когда можно развернуть sidecar-прокси для каждого экземпляра сервиса и его реплик.

• Когда сервисы могут использовать один сертификат из центра сертификации (CA), чтобы установить безопасное соединение (для нескольких продуктов это может быть невозможно).

Когда использовать API-шлюз

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

• Когда мы хотим предлагать API как продукт (бесплатно или за деньги).

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

• Когда нужно преобразовывать протоколы при взаимодействии между сервисами.

Service mesh и API-шлюз вместе

Эти две технологии вполне могут сосуществовать. На следующей схеме мы видим, как service mesh и API-шлюз работают вместе:

Как видите, на уровне продукта мы можем реализовать service mesh для управления горизонтальным трафиком. Для общения между продуктами можно использовать внутренний API-шлюз, а за взаимодействие между клиентами на границе сети и сервисами (вертикальный трафик) пусть отвечает внешний API-шлюз.