Перейти к содержанию

API Gateway

API Gateway - единая точка входа в систему для внешних клиентов. Клиент знает один адрес, а gateway решает, в какой сервис отправить запрос, и по пути берёт на себя сквозные задачи: роутинг, аутентификацию, rate limiting, circuit breaker. Единая точка входа - логически, а не физически, тк может быть несколько инстансов за load balancer.

Клиент знает только про gateway. Gateway знает про сервисы, но не их IP, а имена: адрес живого инстанса он спрашивает у registry (см. Service Discovery).

Что делает API Gateway

  • клиенту не надо знать про десяток сервисов и их адреса: один endpoint, один auth-контракт
  • одна точка для метрик и WAF
  • сервисы можно делить, переименовывать и переносить, а внешний API остаётся прежним

Задачи:

Роутинг - по пути, хосту, методу или заголовку gateway выбирает сервис по url.

  • адрес сервиса берётся из service discovery
  • запрос по пути можно переписать: срезать префикс /api, добавить заголовок, сменить путь
  • маршрут с весами отправляет часть трафика на новую версию: «5% на v2» для канареечного релиза
  • снаружи REST и JSON, внутри gRPC: роутинг заодно транслирует протокол

Аутентификация на входе - gateway проверяет токен авторизации до того, как запрос дошёл до сервиса. Нет токена - сразу 401, нагрузка внутрь не идёт. JWT проверяется локально

  • токен уходит дальше в заголовке Authorization, или gateway обменивает внешний токен на внутренний, узкий по scope
  • авторизацию gateway не заменяет: он не знает бизнес-контекст, чей это заказ и в каком он статусе
  • сервисы всё равно проверяют токен сами

Rate limiting на входе - не больше N запросов в окно времени на клиента. Превысил - 429 Too Many Requests.

  • ключ лимита на gateway - пользователь из токена, API-ключ или IP
  • инстансов gateway несколько, поэтому счётчик держат в общем хранилище, обычно в Redis

Circuit breaker на маршруте - сервис за gateway начал падать, и gateway перестаёт слать ему запросы, а через паузу пробует снова.

  • клиент не висит до таймаута, а сразу получает 503 или запасной ответ: кэш, заглушку сервис временно недоступен
  • упавший сервис не добивают потоком запросов, пока он поднимается
  • breaker обычно настраивают на маршрут вместе с timeout и retry

Breaker на gateway защищает только вход. Вызовам между сервисами нужны свои breaker: в библиотеке или в service mesh.

Остальное:

  • TLS termination - gateway расшифровывает внешний TLS, внутрь идёт HTTP или mTLS внутри mesh
  • Сборка ответа - вызывает несколько сервисов и склеивает ответ (API Composition)
  • Кэш ответов - отдаёт повторный GET из кэша, не дёргая сервис
  • WAF и проверка схемы - отсекает типовые атаки и запросы, которые не подходят под контракт (см. Политики на gateway)
  • Логи, метрики, трейсы - весь внешний трафик проходит через одну точку, здесь удобно начинать трейс

Готовые API Gateway

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

Вариант Что пишешь сам Примеры Когда брать
Готовый продукт Конфиг и при необходимости плагин Kong, Apache APISIX, Tyk, KrakenD, Envoy Gateway По умолчанию: стандартный роутинг, auth, лимиты
Фреймворк Сервис: маршруты и фильтры в коде Spring Cloud Gateway, YARP и Ocelot в .NET Нестандартная логика на входе, команда на Java или .NET
Облачный (managed) Только настройку в консоли или Terraform AWS API Gateway, Azure API Management, Google Apigee Система живёт в одном облаке
С нуля Весь прокси Почти никогда

Почти все готовые gateway построены на нескольких прокси-движках:

NGINX --- OpenResty (NGINX + Lua) ---+--- Kong
                                     +--- Apache APISIX

Envoy ---+--- Envoy Gateway
         +--- Istio ingress gateway
         +--- Contour
         +--- Emissary-ingress (бывший Ambassador)
         +--- Gloo Gateway

Go ------+--- Tyk
         +--- KrakenD
         +--- Traefik

JVM -----+--- Spring Cloud Gateway
         +--- Gravitee
Прокси, из которых собирают gateway Что это Когда брать
NGINX Reverse proxy на C, gateway собирают из конфига Простой вход: TLS, маршруты, rate limit
HAProxy Балансировщик L4 и L7 на C Высокая нагрузка, балансировка без API-логики
Envoy L7-прокси на C++, конфиг меняется на лету через API Kubernetes, основа для gateway и mesh
Traefik Reverse proxy на Go, маршруты берёт из меток Docker и Kubernetes Docker Compose, небольшой Kubernetes
Готовые API gateway Что это Когда брать
Kong NGINX и Lua, плагины, конфиг в Postgres или декларативном файле Нужны готовые плагины: auth, лимиты, логи
Apache APISIX NGINX и Lua, конфиг в etcd Маршруты и плагины меняются на лету
Tyk Go, open source gateway и платный дашборд Gateway вместе с API management
KrakenD Go, stateless, весь конфиг в одном файле Сборка ответа из нескольких сервисов без кода
Gravitee Java, gateway и API management с порталом Нужен портал для внешних разработчиков
Фреймворки для своего gateway Что это Когда брать
Spring Cloud Gateway Spring WebFlux и Netty. С версии 4.1 есть вариант на Spring MVC Java и Spring стек
Netflix Zuul Первый массовый gateway из Netflix OSS Легаси. В Spring Cloud его сменил Spring Cloud Gateway
YARP Библиотека reverse proxy от Microsoft .NET-стек
Ocelot API gateway на ASP.NET Core Небольшой gateway в .NET
Облачные Что это Когда брать
AWS API Gateway REST, HTTP и WebSocket API, интеграция с Lambda Бэкенд в AWS, serverless
Azure API Management Gateway и API management Бэкенд в Azure
Google Apigee, Google Cloud API Gateway Apigee - API management для enterprise, API Gateway - лёгкий вход Бэкенд в GCP
Yandex Cloud API Gateway Маршруты описывают спецификацией OpenAPI с расширениями Бэкенд в Yandex Cloud

Грабли

  • God gateway. В gateway заползает бизнес-логика: «если заказ дороже X - добавь скидку». Через год это монолит, через который ходит всё, и менять его страшно. Gateway держит инфраструктурные задачи (auth, routing, rate limit), бизнес-правила остаются в сервисах (см. God gateway).
  • Single point of failure. Упал gateway - упало всё. Нужны несколько инстансов, health checks и отдельный деплой.
  • Узкое место по релизам. Каждый новый маршрут требует правки общего gateway, и он становится очередью между командами. Помогает BFF: у каждого клиента свой вход, которым владеет его команда.

С чем путают API Gateway

Паттерн Что делает Чем отличается от gateway
Reverse proxy Принимает запросы вместо серверов и пересылает дальше Не понимает API. Gateway - reverse proxy, который знает клиентов, токены, лимиты
Load balancer Распределяет запросы по инстансам одного сервиса, L4 или L7 Не роутит по API. Обычно стоит перед gateway и балансирует его инстансы
Ingress controller Пускает HTTP-трафик в кластер Kubernetes по хосту и пути Политики на клиента (auth, лимиты) только через расширения
Service mesh Ведёт трафик между сервисами через прокси рядом с каждым Трафик east-west (сервис -> сервис), а gateway - north-south (клиент -> система)
API management Портал для разработчиков, API-ключи, тарифы, аналитика Платформа вокруг gateway. Gateway - её часть, через которую идёт трафик
ESB Шина SOA: трансформации, оркестрация, бизнес-роутинг Умная труба. Gateway с бизнес-логикой и есть ESB на входе
Facade (GoF) Простой интерфейс поверх сложной подсистемы в одном процессе Та же идея, но gateway сетевой и для внешних клиентов
BFF Вход под один тип клиента Свой вход на каждый тип клиента вместо общего
API Composition Собирает ответ из нескольких сервисов Отдельный паттерн. Gateway умеет его, но composer бывает отдельным сервисом

В других срезах