Как только у вас появляется не один монолит, а кучка микросервисов, жизнь резко становится веселее. Один сервис отвечает за пользователей, другой за заказы, третий за оплату, четвёртый вообще вспомогательный — а клиенты и фронтенды начинают дёргать всех подряд. Концов всё больше, точек входа тоже, где-то повторяется логика авторизации, где-то торчат лишние порты наружу. В этот момент обычно приходит понимание, что нужен какой-то единый «вход». И вот тут в игру вступает API Gateway.
По сути, это центральная прокладка между клиентами (браузерами, мобильными приложениями, партнёрскими системами) и всеми вашими backend-сервисами. Клиенты больше не общаются с каждым микросервисом напрямую — они знают ровно одну конечную точку, а дальше гейтвей сам решает, куда что отправить и какие правила при этом применить.
Что он делает на практике:
- Маршрутизирует запросы. Путь
/users— в один сервис,/orders— в другой,/payments— в третий. Клиенту всё равно, сколько там микросервисов за кулисами. - Ограничивает и фильтрует. Можно выставить лимиты по количеству запросов, запретить что-то подозрительное, строить правила rate limiting типа «не более N запросов в минуту с одного ключа или IP».
- Занимается аутентификацией и проверкой токенов. Большая часть логики безопасности живёт в гейтвее, а не размазывается по всем сервисам.
- Шифрует и кэширует. SSL/HTTPS терминируется на входе, ответы можно кэшировать, вести централизованное логирование — и всё это без того, чтобы каждый микросервис заново изобретал велосипед.
- Изолирует внутреннюю кухню. Внешнему миру виден только сам gateway, а сервисы за ним могут жить в приватных сетях, без прямого доступа извне.
Можно думать о нём как о швейцаре у входа в отель. Он первый встречает гостей, спрашивает, кто они, сверяет документы (токены, ключи), решает, в какой номер их проводить, и разворачивает тех, кому внутрь вообще нельзя.
По примерам: есть AWS API Gateway — мощный и очень интегрированный в экосистему AWS, но к нему нужно немного привыкнуть. Есть Tyk — опенсорсный и хорошо кастомизируемый. Kong — с богатой системой плагинов и гибкой настройкой. Даже обычный NGINX часто используют как простой API gateway, если не хочется поднимать что-то тяжёлое.
С точки зрения DevOps это, по сути, способ не тащить одни и те же куски инфраструктурного кода в каждый микросервис. Лимиты, логирование, авторизация, версии API, иногда — трансформация запросов и ответов — всё это можно держать в одном месте. Когда сервисов становится десятки, без такой центральной точки входа начинается хаос: разные эндпоинты, разные правила, разный уровень защиты.
Так что как только у вас сервисов больше одного-двух, API Gateway перестаёт быть «когда-нибудь потом» и превращается в основу архитектуры. Особенно в облаке и особенно в микросервисной истории, где без него очень легко скатиться в зоопарк, который потом никому не хочется поддерживать.
