Вы наверняка много раз слышали о 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. Иллюстрация автора

С помощью 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, например:

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

API-шлюз

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

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

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

Иллюстрация автора
Иллюстрация автора

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Service mesh и API-шлюзы. Иллюстрация автора
Service mesh и API-шлюзы. Иллюстрация автора

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

Интенсив по service mesh

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

Автор интенсива – Александр Лукьянченко, руководитель юнита PaaS в Авито.

— Создатель сontributor service mesh решений Netramesh и Navigator на базе Envoy Proxy.
— Занимается построением внутренней платформы Авито для разработчиков на базе Kubernetes.

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

???? Доступна рассрочка и скидки.
Узнать подробности: slurm.club/3VEAIbx

Комментарии (2)


  1. mirwide
    08.12.2022 21:04
    +3

    Странная статья, зачем такое переводить.
    Единственное отличие service mesh от классического api-gateway, это распределённый data plane. За счет sidecar расположенного рядом с сервисом, мы уменьшаем сетевые задержки до балансера, можем вынести tls из сервиса(в api-gateway тоже можем, но выше возможность перехвата незащищённого трафика), для больших систем уменьшаем нагрузку на балансер, благодаря публикации на sidecar только необходимой части правил для исходящего роутинга.

    А в статье какие-то выдуманные отличия. Service discovery, rate limiter, cb, мониторинг, трейсинг, авторизация и аутентификация, зеркалирование трафика - это всё можно использовать в обоих парадигмах.


    1. eaa
      09.12.2022 01:30
      +1

      Они штампуют очень странные статьи, не читайте их. Это не первый их неоднозначный опус.