Когда мы работаем с монолитом, всё просто — одна точка входа, один деплой, и клиент знает, куда стучаться. Но в микросервисах всё меняется: у нас десятки сервисов — order-service, stock-service, payment-service и тд
Проблема в том, что клиенту, по-хорошему, надо знать адреса каждого сервиса, версию API, правила авторизации, протоколы и тд.
❌ Какие проблемы возникают:
• Каждый сервис живёт своей жизнью, и любые изменения ломают клиента.
• Авторизация и безопасность реализованы кусками в каждом сервисе.
• Протоколы не совпадают (один работает по REST, другой по gRPC, третий по WebSocket).
• Невозможно централизованно сделать rate limit, ретраи, логирование или трассировку.
В итоге это превращается в зоопарк, в котором тяжело что-либо контролировать
✔️ API Gateway — единая точка входа в систему 🚪
Описанная выше проблема - стандартная в микросервисах. Она была, есть и будет у всех, кто работает с распределёнными системами. И для этой стандартной проблемы есть стандартное решение (паттерн) — API Gateway.
Его суть в том, что мы делаем единую точку входа в систему, и все клиенты начинают взаимодействовать именно с ней.
— Все фронтенды, мобильные приложения, веб-версии, десктопные клиенты — работают через один шлюз.
— Иногда делают несколько точек входа: одна для фронта, одна для мобилки, одна для веба — если API отличаются (Это уже больше про BFF паттерн). Но в общем случае это одна единая точка.
— Эта точка входа берёт на себя кучу инфраструктурных функций, которые мы выносим из сервисов:
• Routing — перенаправление запросов на нужный сервис (/orders/api → order-service).
• Аутентификация/авторизация — единая точка проверки прав.
• TLS/mTLS termination — снимает нагрузку с сервисов.
• Трансформация протоколов — REST ↔ gRPC, HTTP ↔ WebSocket.
• Retry / Circuit Breaker / Rate Limiting — паттерны отказоустойчивости в одном месте, без копипасты.
• Агрегация данных — объединение ответа от нескольких сервисов.
• Трассировка и логирование — вшито в точку входа.
Spring Cloud API Gateway
У нас с вами в мире Java на Spring Boot есть готовая реализация — Spring Cloud API Gateway. В нём всё это уже есть из коробки. Использовать очень просто и удобно. Буквально за несколько настроек в application.yml получаем готовый сервис, но при этом легко можем его модернизировать по своим нуждам.
Одна из отличительных черт — реактивная модель на базе Netty (не thread per request как у Tomcat). Отлично подходит для I/O bound задач, а работа API Gateway как раз в основном из таких задач и состоит.
Еще повышается отказоустойчивость (по сравнению с Tomcat) благодаря reactive stack. Если какой-то проксируемый сервис начинает сбоить и отвечает долго — у нас пулы потоков не забиваются и сам API Gateway не тормозит, другие запросы в другие сервисы не аффектятся из-за забитого пула потоков.
Какие еще есть преимущества и возможности (комментах скину пример настройки как это выглядит):
— глобальные фильтры (логирование, аутентификация, CORS, rate limit).
— Локальные фильтры для конкретных маршрутов.
— Маршрутизация по URI, заголовкам, query-параметрам, даже по времени суток.
— Трансформация заголовков, тела запроса и ответа.
— Интеграция со Spring Security, Config Server и экосистемой Spring
Всё, что нам нужно — прописать в конфиге routes, фильтры и условия, а дальше Spring Cloud Gateway делает все под капотом. Может интегрироваться также с Eureka Service Discovery или K8S service discovery (если нам нужно делать load balancing на уровне приложения).
Про этот паттерн, как минимум, часто спрашивают на собесах, поэтому его важно знать и уметь ответить зачем он используется.
Итого из основных преимуществ: Позволяет централизовать инфраструктурную логику (не всю, но много), контроль безопасности, маршрутизацию и тд. Легко добавлять и удалять сервисы, связность системы уменьшается — повышается масштабируемость и отказоустойчивость. Контроль безопасности в одном месте сразу на входе.
👍 — использую/использовал API Gateway
🔥 — не использую
#хардовая_польза