Что такое API Gateway и как он работает в микросервисной архитектуре
Что проверяют
Понимаете ли вы, какие задачи стоит решать на входе в систему, а какие должны остаться в сервисах. Следом спрашивают про недостатки: единая точка отказа, лишний сетевой переход, риск превратить шлюз в свалку логики.
Как отвечать
API Gateway это единая точка входа для внешних клиентов. Клиент знает один адрес, а шлюз решает, в какой сервис отправить запрос, и берёт на себя сквозные задачи:
- маршрутизация: по пути, хосту, заголовку или версии API;
- аутентификация: проверка JWT один раз на входе, дальше в сервисы уходит проверенный токен или идентификатор пользователя;
- ограничение частоты: rate limiting по клиенту или ключу, счётчики обычно в Redis;
- устойчивость: таймауты, повторы, circuit breaker, чтобы упавший сервис не тянул за собой остальные;
- сквозное: TLS, CORS, логирование, проброс trace id.
В Java-мире основной вариант Spring Cloud Gateway. Маршруты в нём описываются предикатами и фильтрами, есть готовые RequestRateLimiter с RedisRateLimiter, CircuitBreaker на Resilience4j и TokenRelay для OAuth2. Базовая версия реактивная, на WebFlux и Netty, с конца 2023 года есть вариант Server MVC на сервлетах. Адрес вида lb://orders отдаёт выбор экземпляра Spring Cloud LoadBalancer. Netflix Zuul из Spring Cloud давно убран. Вне Java шлюзом часто служат Kong, Envoy, NGINX или облачный managed-сервис.
Отдельно стоит упомянуть BFF: свой шлюз под каждый тип клиента, когда мобильному приложению и вебу нужны разные агрегированные ответы.
Где спотыкаются
Переносят в шлюз бизнес-логику. Проверка остатков на складе в фильтре шлюза связывает его релизы с релизами сервиса.
Пишут блокирующий код в фильтрах реактивного Spring Cloud Gateway. Вызов JDBC или RestTemplate занимает поток event loop, и под нагрузкой шлюз встаёт целиком.
Забывают, что шлюз один на всех. Без нескольких экземпляров за балансировщиком его падение отключает всю систему, какой бы надёжной ни была остальная часть.