API Gateway: зачем он нужен и когда без него никак
Когда сервисов больше одного, перед ними ставят шлюз — единую точку входа, которая принимает все запросы и решает три вещи: кто пришёл, куда его пустить и сколько ему можно.
Что даёт шлюз на практике:
• Аутентификация в одном месте. JWT проверяется на входе, а не в каждом сервисе. Нет токена — запрос даже не доходит до бэкенда. • Маршрутизация. /api/blog — в блог, /api/cart — в корзину. Фронт знает один адрес, а не десять. • Rate limiting. Защита от флуда и ботов до того, как они съедят ресурсы сервисов. • Один конфиг вместо зоопарка. Один YAML описывает маршруты, лимиты и права (RBAC) для всего.
Частый вопрос — не слишком ли это дорого по производительности. Мы замерили на своём шлюзе (Go, один бинарник): 24k req/s на проксировании, встроенная проверка JWT стоит всего −15% к пропускной способности. Для сравнения: внешняя auth у Nginx через auth_request просаживает на 89%, у Traefik forwardAuth — на 94%. Пик памяти — 121 МБ против 314 у Kong.
Главный вывод из замеров: встроенная аутентификация на порядок дешевле внешней. Если ваш шлюз на каждый запрос ходит в отдельный auth-сервис — вы платите лишним сетевым хопом за каждый запрос.
Шлюз оправдан, когда сервисов два и больше, есть публичное API или нужен единый контроль доступа. Один монолит за nginx — шлюз не нужен, не усложняйте.
