Ответ
Да, в проекте использовался API Gateway на основе Spring Cloud Gateway.
Роль в архитектуре: Он выступал как единая точка входа для всех клиентских запросов к микросервисам.
Ключевые функции, которые мы реализовали:
- Динамическая маршрутизация на основе пути запроса.
- Балансировка нагрузки (через интеграцию с Service Discovery, например, Eureka).
- Аутентификация и авторизация (проверка JWT-токенов).
- Rate Limiting для защиты от чрезмерной нагрузки.
- Логирование запросов и ответов (centralized logging).
Пример конфигурации маршрута (application.yml):
spring:
cloud:
gateway:
routes:
- id: product-service
uri: lb://product-service # lb:// указывает на балансировку нагрузки
predicates:
- Path=/api/products/**
filters:
- StripPrefix=1 # Удаляет первый сегмент пути (/api) перед проксированием
- AddRequestHeader=X-User-Id, ${user.id}Вывод: API Gateway помог декомпозировать cross-cutting concerns (сквозную функциональность) из бизнес-сервисов, упростив их код и централизовав управление.
Ответ 18+ 🔞
А, слушай, про этот ваш API Gateway на Spring Cloud! Ну, это ж классика, блядь. Представь себе: куча микросервисов, как тараканы, бегают, а клиент — он же один, и ему похуй, кто там у тебя за кулисами пыхтит. Ему нужна одна дверь, в которую можно постучаться.
Вот эта дверь — он и есть, ёпта, наш Gateway. Единственная точка входа, мать её. Все запросы — сначала к нему, а он уже, хитрая жопа, решает, куда дальше это дело направить.
Чё он умел, этот шлюз? Да вроде всё, что нужно нормальному вышибалe на входе в клуб:
- Куда идти? — Смотрит на путь запроса (
/api/products) и говорит: «Ага, тебе вproduct-service, нахуй». - Не перегрузить ли бар? — Rate Limiting, чтобы какой-нибудь бот не начал ддосить, как последний пидарас.
- А по паспорту можно? — Проверяет JWT-токен, не поддельный ли. Нет пропуска — иди нахуй, в 401-ю ошибку.
- К кому из официантов? — Балансирует нагрузку. Если у тебя пять инстансов
product-serviceбегают, он выберет того, кто меньше всех заебан. - Что там было? — Всё логирует, чтобы потом, если что-то сломалось, не гадать на кофейной гуще, а знать, кто последним этот пиздец в систему запустил.
И самое охуенное — всю эту хуйню (извините, cross-cutting concerns) ты выносишь из самих сервисов. Они теперь только бизнесом занимаются, а не думают, как токен проверить или лог записать. Чистота, блядь!
Вот смотри, как это в конфиге выглядело. Просто, как три копейки:
spring:
cloud:
gateway:
routes:
- id: product-service
uri: lb://product-service # lb:// - это магия, значит "ищи в Service Discovery"
predicates:
- Path=/api/products/** # Если путь такой — это наш клиент
filters:
- StripPrefix=1 # Отрежь первый кусок пути (/api), чтобы сервису не мешал
- AddRequestHeader=X-User-Id, ${user.id} # И передай, мол, от кого пришёлКороче, инструмент — огонь. Не панацея, конечно, ещё одна точка отказа, но без него в микросервисной архитектуре — как без штанов на морозе: вроде и движешься быстро, но всем видно, что ты мудак.