API Gateway

Базовый System Design
≈ 2 мин чтения

Единая точка входа для набора API

Когда за внешним API стоит несколько внутренних сервисов, клиенту неудобно знать адрес и правила каждого из них. API Gateway предоставляет единую точку входа и направляет запрос в нужную часть системы.

             +-> users service
client -> API Gateway -> orders service
             +-> media service

На этом уровне маршрутизация уже опирается на смысл API: путь, метод, версию или другие данные прикладного протокола. Gateway скрывает внутреннюю структуру и позволяет менять её без обязательного изменения внешнего контракта клиента.

Общие политики можно централизовать

Через gateway часто проходят общие для многих API-задачи. Например, здесь можно проверять токен доступа, ограничивать частоту запросов, вести технический аудит, добавлять correlation id или применять правила маршрутизации по версии API.

  • аутентификация и первичная авторизация;
  • rate limiting и квоты;
  • маршрутизация к внутренним сервисам;
  • наблюдаемость общего входного трафика;
  • иногда — простая агрегация нескольких ответов.

Централизация полезна, когда правило действительно общее. Она уменьшает дублирование и позволяет применять одинаковую политику независимо от реализации конкретного сервиса.

Gateway не должен превращаться в приложение

Чем больше бизнес-логики переносится в gateway, тем сильнее все сервисы начинают зависеть от одного компонента. В результате входной слой становится сложным, тяжёлым для изменений и потенциально узким местом.

Хорошая граница проста: gateway решает задачи входного API и межсервисной маршрутизации, а предметные правила остаются в сервисах, которым они принадлежат.

API Gateway и Reverse Proxy могут быть реализованы одним продуктом, но это разные роли. Reverse proxy — общий инфраструктурный посредник, а API Gateway добавляет политики, специфичные именно для API и структуры сервисов.