Микросервисы перестали быть экзотикой. Команды режут монолиты на десятки независимых сервисов, и каждый получает свой адрес, свой протокол, свою модель аутентификации. Клиент – мобильное приложение, фронтенд или внешняя система партнёра – внезапно должен знать топологию всего бэкенда. Это не работает. API Gateway решает проблему: ставит одну точку входа перед всем зоопарком сервисов и берёт на себя то, что иначе пришлось бы дублировать в каждом из них. Мы в прошлогоднем прогнозе на 2015 год отмечали рост интереса к сервисной декомпозиции – gateway становится её обязательным спутником.

Что снимает с плеч сервисов

Без шлюза каждый микросервис вынужден сам проверять токены, писать логи запросов, ограничивать частоту вызовов и разбираться с CORS. Двадцать сервисов – двадцать копий одной и той же логики, причём с расхождениями. Gateway выносит это на периферию:

  • Маршрутизация. Один публичный URL, за ним – десятки внутренних endpoint'ов. Клиент не знает и не должен знать, где физически живёт сервис заказов.
  • Аутентификация и авторизация. Шлюз проверяет токен один раз, на входе. Дальше внутрь идёт уже доверенный трафик с прокинутым контекстом пользователя.
  • Контроль трафика. Rate limiting, throttling, защита от всплесков. Один клиент не положит всю систему запросами.
  • Агрегация. Мобильному приложению нужны данные из трёх сервисов – gateway собирает их в один ответ, экономя дорогие сетевые раунды на медленных каналах.

Сервисы при этом остаются маленькими и занимаются только бизнес-логикой. Это и есть смысл декомпозиции.

Точка контроля для безопасности и локализации

Единая точка входа – это ещё и единая точка наблюдения. Весь трафик проходит через шлюз, значит здесь удобно строить аудит, мониторинг и периметр защиты. Для госсектора и компаний с персональными данными это прямая выгода: централизованный контроль легче описать в регламентах и проще проверить.

Тема стала острой с принятием закона 242-ФЗ – требования по локализации персональных данных вступают в силу, и gateway помогает разграничить потоки: запросы с ПДн направляются строго на сервисы внутри российского контура, а шлюз фиксирует это маршрутизацией и логами. Сам шлюз – критичный компонент периметра, поэтому хост под ним готовьте по тем же принципам, что мы описывали в чек-листе hardening для Linux: минимум открытых портов, TLS на входе, отдельная сеть для внутренних вызовов.

Чего не делать

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

Второй риск – единая точка отказа. Раз весь трафик идёт через шлюз, его падение роняет всё. Закладывайте резервирование и горизонтальное масштабирование с первого дня, а не после первого инцидента.

Вывод

API Gateway не усложняет архитектуру – он делает её управляемой. Один вход, одна точка контроля, тонкая прослойка без бизнес-логики. Для распределённых систем в B2B и госсекторе это базовый кирпич, а не опция. Когда микросервисы собираются из существующих систем, шлюз становится узлом интеграции разнородных систем в единый ландшафт, и проектировать его стоит с этим прицелом.