API Gateway

Что такое API Gateway

API Gateway (API-шлюз) — сервис, стоящий перед вашими бэкендами и принимающий весь внешний трафик. Клиент знает один адрес — шлюз, а тот разбирается, в какой сервис отправить запрос, и попутно делает то, что иначе пришлось бы писать в каждом сервисе: проверку токена, лимиты, логирование, TLS.

Проблема, которую он решает, появляется вместе с микросервисами. Без шлюза мобильному приложению нужно знать адреса десятка сервисов, а каждая команда пишет свою проверку авторизации — по-своему и с собственными багами. Шлюз выносит общее в одно место.

                       ┌──────────────┐
клиенты ──HTTPS──▶ │ API Gateway  │──▶ /v1/orders   → orders-svc
                       │ authn, лимиты │──▶ /v1/users    → users-svc
                       │ TLS, логи     │──▶ /v1/generate → gpu-inference
                       └──────────────┘

Что он делает

• Маршрутизация. По пути, хосту или заголовку выбирает нужный сервис.
• Аутентификация. Проверяет JWT, API-ключ или OAuth-токен и не пропускает дальше чужих. Бэкенд получает уже проверенный запрос с id пользователя в заголовке.
• Rate limiting. Режет частоту запросов на клиента и возвращает 429 — защита и от перебора, и от случайного цикла в чужом коде.
• Терминация TLS. Сертификат лежит на шлюзе, внутрь трафик идёт по HTTP в закрытом контуре.
• Трансформация. Меняет заголовки, склеивает ответы нескольких сервисов, отдаёт наружу REST, а внутрь ходит gRPC.
• Наблюдаемость. Единая точка, где видно все запросы: логи, метрики, трейсинг.
• Версионирование. /v1/ и /v2/ разводятся на разные бэкенды без изменений в клиентах.

Gateway, балансировщик и reverse proxy

Границы размыты — один и тот же Nginx может быть всеми тремя. Разница в уровне задач:

Практически: балансировщик отвечает на вопрос «на какую из одинаковых реплик отправить», шлюз — «что это за запрос, можно ли его вообще пропускать и в какой сервис он идёт». В реальной схеме они стоят рядом: балансировщик перед несколькими экземплярами шлюза, а шлюз — перед сервисами.

Чем поднимают

• Traefik — автоматически подхватывает маршруты из меток Docker и выпускает сертификаты Let's Encrypt.
• Kong, APISIX, Envoy — полноценные шлюзы с плагинами: аутентификация, лимиты, трансформации.
• Nginx — если нужны только маршрутизация, TLS и простые лимиты, отдельный шлюз часто избыточен.
• Kubernetes — роль шлюза играют Ingress-контроллер или Gateway API.
• Облачные шлюзы — управляемый сервис, типичная связка для serverless-функций.

Маршрутизация лимитов в Nginx для тяжёлого GPU-эндпоинта:

limit_req_zone $http_authorization zone=api:10m rate=10r/s;

location /v1/generate {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://gpu_inference;
    proxy_read_timeout 300;    # инференс отвечает не мгновенно
}

Чего опасаться

Шлюз — единая точка отказа: лёг он — недоступно всё. Отсюда минимум две реплики и health check на бэкендах. Второй риск — превращение шлюза в свалку бизнес-логики: правила трансформации накапливаются, и однажды выкатка фичи требует правки конфигурации шлюза. Логика — в сервисах, на шлюзе — только сквозные задачи.

Для одного монолита или пары сервисов шлюз не нужен: Nginx с проксированием закрывает те же потребности без лишнего компонента.

Связанные термины

• API — то, чем управляет шлюз
• load balancer — соседний компонент, решающий другую задачу
• Микросервисы и монолит — архитектура, порождающая потребность в шлюзе
• Nginx — самый доступный способ начать
• Traefik — шлюз для контейнерных окружений
• JWT и токены — что шлюз проверяет на входе