Вы наверняка много раз слышали о 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, например:
В интернете можно найти немало статей, где сравниваются эти реализации.
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-шлюз, а за взаимодействие между клиентами на границе сети и сервисами (вертикальный трафик) пусть отвечает внешний API-шлюз.
Интенсив по service mesh
В Слёрм стартует трехдневный практический интенсив по service mesh. Во время обучения вы потрогаете технологию руками и сможете подготовиться к ее внедрению без костылей в архитектуре. А еще, знание service mesh – это хороший скилл для карьерного роста.
Автор интенсива – Александр Лукьянченко, руководитель юнита PaaS в Авито.
— Создатель сontributor service mesh решений Netramesh и Navigator на базе Envoy Proxy.
— Занимается построением внутренней платформы Авито для разработчиков на базе Kubernetes.
Помимо голой теории и практики, вы получите рекомендации от эксперта по внедрению. А еще, вы не просто посмотрите на то, какие фичи есть у service mesh, а попробуете с ними поработать в специально разработанном приложении онлайн-кинотеатра, состоящего из нескольких микросервисов.
? Доступна рассрочка и скидки.
Узнать подробности: slurm.club/3VEAIbx
