Прямой ответ
API Gateway — единая точка входа для клиентов в микросервисную архитектуру (все внешние запросы → gateway → маршрутизация к сервисам — микросервисы — «клиент не знает о 20 сервисах» — один вход — микросервисы); проблема, которую решает: без gateway клиент знает все сервисы (URL/порты/аутентификация каждого — микросервисы — «20 сервисов — 20 endpoints» — coupled — изменение сервиса — изменение клиента — техдолг), кросс-каттинг дублируется (аутентификация/rate limiting/логирование в каждом сервисе — JWT — «20 реализаций аутентификации» — техдолг); функции gateway: (1) маршрутизация (запрос → правильный сервис — /users/* → user-service, /orders/* → order-service — микросервисы — «клиент шлёт на gateway, gateway — на сервис»); (2) аутентификация/авторизация (проверка JWT/API-ключа на входе — JWT — «gateway проверяет токен, сервисы доверяют» — JWT — OWASP); (3) rate limiting (ограничение запросов на входе — retry — «100 req/min на клиента» — защита от перегрузки — ёмкость); (4) SSL termination (HTTPS на gateway, внутри — HTTP — nginx — «gateway терминирует SSL» — OWASP); (5) агрегация (один запрос → несколько сервисов → агрегированный ответ — микросервисы — «главная страница — данные из 3 сервисов» — gateway агрегирует — CQRS-read); (6) трансформация (формат запроса/ответа — «REST → gRPC» — gRPC — «клиент REST, сервисы gRPC» — gateway транслирует); (7) circuit breaker/retry (защита от сбоев сервисов — retry — «сервис упал — gateway не шлёт» — retry); выбор gateway: (1) Kong (мощный, плагины, enterprise-фичи — Kong — «полнофункциональный gateway» — микросервисы); (2) Envoy (высокопроизводительный, service mesh-база — Envoy — Istio — «Envoy как gateway или sidecar» — service mesh); (3) Traefik (простой, auto-discovery, Docker/K8s — Traefik — «Traefik для Docker/K8s» — Docker); (4) nginx (классика, производительный, но конфигурация вручную — nginx — «nginx как gateway» — nginx); gateway vs service mesh: gateway — внешний трафик (клиент → сервисы — микросервисы), service mesh — внутренний (сервис → сервис — service mesh — Istio — «gateway для внешнего, mesh для внутреннего» — service mesh); когда gateway НЕ нужен: монолит (один сервис — gateway оверхед — микросервисы), мало сервисов (2–3 — без gateway проще — микросервисы), внутренний трафик (service mesh решает — service mesh — Istio); антипаттерны: gateway как бизнес-логика (gateway знает бизнес — coupled — микросервисы — «gateway с бизнес-логикой» — антипаттерн — техдолг), единая точка отказа (gateway упал — всё упало — ёмкость — HA gateway — failover), gateway без мониторинга (метрики — «gateway тормозит» — метрики/алерты — алерты).
Практика: Kong/Nginx как gateway
nginx как gateway (простой старт): reverse proxy (nginx — location /users/ { proxy_pass } — nginx — маршрутизация), SSL termination (nginx — HTTPS на nginx, внутри HTTP — OWASP), rate limiting (nginx — limit_req_zone — retry — «100 req/min» — ёмкость); Kong (полнофункциональный): плагины (auth/rate-limit/transform — Kong — «gateway с плагинами» — JWT), declarative config (Kong — YAML/DB — микросервисы), admin API (Kong — «конфигурация через API» — IaC); Envoy (высокопроизводительный): xDS API (динамическая конфигурация — Envoy — Istio — «Envoy как gateway или sidecar» — service mesh), L7-функции (routing/retry/circuit breaker — retry — Envoy); аутентификация на gateway (JWT — gateway проверяет JWT, передаёт user_id в заголовке — сервисы доверяют — JWT — «gateway аутентифицирует, сервисы авторизуют» — OWASP); rate limiting (retry — на gateway (клиент/IP/API-ключ — retry — «100 req/min на клиента» — ёмкость — защита сервисов — retry).
Практический сценарий: e-commerce — gateway для 15 микросервисов
Контекст: e-commerce на 15 микросервисах (users, orders, products, payments, inventory, ... — микросервисы), боль: клиент знает все сервисы (URL/порты — микросервисы), аутентификация в каждом сервисе (15 реализаций — JWT — техдолг), нет rate limiting (один клиент — все сервисы перегружены — ёмкость); решение — Kong как API Gateway: (1) маршрутизация (Kong — /users/* → user-service, /orders/* → order-service — микросервисы — «клиент шлёт на gateway»); (2) аутентификация (Kong — JWT-плагин — JWT — «gateway проверяет токен» — сервисы доверяют — OWASP); (3) rate limiting (Kong — rate-limit плагин — retry — «100 req/min на клиента» — ёмкость); (4) SSL termination (Kong — HTTPS на gateway, внутри HTTP — OWASP); (5) агрегация (Kong — «главная страница» — данные из 3 сервисов — gateway агрегирует — CQRS-read); (6) circuit breaker (Kong — retry — «сервис упал — gateway не шлёт» — retry); (7) HA (Kong — 2+ ноды за load balancer — failover — «gateway упал — второй подхватил» — ёмкость); (8) мониторинг (метрики — Kong-метрики (latency/errors/rate-limit — метрики — алерты — алерты); результат: клиент не знает о сервисах (один вход — микросервисы), аутентификация в одном месте (Kong — JWT — техдолг — «15 реализаций → 1»), rate limiting защищает сервисы (retry — ёмкость); цена: единая точка входа (HA обязателен — failover), gateway — bottleneck (все запросы через gateway — ёмкость — масштабировать — ёмкость), сложность (Kong эксплуатировать — ёмкость — зависимости); вывод: gateway решили проблему (единый вход + кросс-каттинг — микросервисы — ADR — «gateway с бизнес-логикой» — антипаттерн — техдолг).
FAQ
API Gateway против reverse proxy (nginx) — в чём разница? Reverse proxy (nginx) — маршрутизация + SSL + базовый rate limiting (nginx — «простой gateway»), API Gateway — reverse proxy + аутентификация/трансформация/агрегация/плагины (Kong — «полнофункциональный» — микросервисы); разница: nginx — маршрутизация (простая — nginx), gateway — кросс-каттинг функции (аутентификация/rate limiting/агрегация — Kong — JWT); когда nginx достаточно: простая маршрутизация + SSL (2–3 сервиса — микросервисы — «nginx как gateway» — nginx), когда нужен gateway: кросс-каттинг (аутентификация/rate limiting/агрегация — Kong — микросервисы); «nginx = gateway» — частично (nginx может быть gateway — nginx — но без плагинов — проще — ADR — техдолг).
API Gateway против service mesh — что когда использовать? API Gateway — внешний трафик (клиент → сервисы — микросервисы — Kong), service mesh — внутренний (сервис → сервис — service mesh — Istio — «gateway для внешнего, mesh для внутреннего»); когда gateway: внешний вход нужен (клиент → микросервисы — микросерисы — Kong), когда mesh: внутренний трафик (сервис → сервис — service mesh — mTLS/retry/observability — service mesh); оба: внешний — gateway, внутренний — mesh (Istio — «gateway + mesh» — service mesh — микросервисы); «gateway заменяет mesh» — нет (gateway — внешний, mesh — внутренний — service mesh — разные уровни — ADR — техдолг).
Как избежать единой точки отказа в API Gateway? Единая точка отказа — gateway упал → всё упало (ёмкость — критично); решения: HA (Kong — 2+ ноды за load balancer — failover — «gateway упал — второй подхватил» — ёмкость), health checks (gateway проверяет сервисы — retry — «сервис упал — gateway не шлёт» — retry), circuit breaker (retry — «сервис не отвечает — gateway не шлёт» — retry), мониторинг (метрики — «gateway упал» — алерт — алерты — incident); «gateway без HA» — антипаттерн (единая точка отказа — ёмкость — HA обязателен — failover — ADR — техдолг).
Что такое BFF (Backend for Frontend) и как связан с API Gateway? BFF — специализированный gateway для конкретного клиента (web/mobile/partner — микросервисы — «gateway для web, gateway для mobile» — микросервисы); связь: BFF — разновидность gateway (не универсальный, а под клиента — микросервисы — «универсальный gateway» vs «BFF для web»); когда BFF: разные клиенты (web/mobile — разные нужды — микросервисы — «mobile нужен лёгкий ответ» — BFF агрегирует/упрощает — CQRS-read), когда универсальный gateway: один клиент (web — микросервисы — «один gateway» — Kong); «BFF = gateway» — частично (BFF — gateway под клиента — микросервисы — не универсальный — ADR — техдолг — микросервисы).
Источники: Kong docs, Envoy docs, Traefik docs — ссылки в шапке.