Spring Cloud Gateway: Архитектурный страж микросервисов
В монолитной архитектуре приложение имеет одну точку входа — HTTP-порт, через который проходят все запросы. Клиент взаимодействует с единым целым. При переходе к микросервисам эта модель разрушается: вместо одного приложения появляются десятки или сотни независимых сервисов, каждый со своим API и сетевым адресом. Прямое обращение клиентов ко всем сервисам создаёт фундаментальные проблемы: клиент должен знать топологию сети, обеспечивать отказоустойчивость для каждого вызова, дублировать логику аутентификации и преобразования данных. Именно здесь возникает необходимость в паттерне API Gateway — единой интеллектуальной точке входа, которая инкапсулирует внутреннюю структуру системы и предоставляет клиентам унифицированный интерфейс. Spring Cloud Gateway (SCG) — это реализация этого паттерна в экосистеме Spring, построенная на реактивной парадигме для удовлетворения требований современных высоконагруженных распределённых систем.
Архитектурное позиционирование и место в экосистеме
Spring Cloud Gateway функционирует как шлюз прикладного уровня (Layer 7) в модели OSI.
Его позиция строго определена: между внешними клиентами (мобильные приложения, браузеры, сторонние системы) и внутренним кластером микросросервисов. Он не является заменой балансировщику нагрузки сетевого уровня (например, AWS NLB или hardware-балансировщику), но работает в тесной связке с ним. Типичная многоуровневая архитектура включает внешний балансировщик, который распределяет трафик между несколькими инстансами SCG для обеспечения отказоустойчивости и масштабируемости, а сам SCG уже занимается интеллектуальной маршрутизацией к конкретным сервисам.
В экосистеме Spring Cloud Gateway является эволюционным преемником Zuul 1.x. Zuul 1, построенный на блокирующем сервлетном API, имел архитектурные ограничения, связанные с выделением потока на каждый соединение, что создавало проблемы при большом количестве одновременных соединений, особенно с длительными запросами (например, Server-Sent Events, WebSockets). SCG был создан с нуля на реактивном стеке Spring WebFlux и проекте Reactor, что позволило реализовать полностью неблокирующую, асинхронную архитектуру, способную эффективно работать с тысячами одновременных соединений на скромных аппаратных ресурсах. Это стратегическое выравнивание с реактивной парадигмой, которую Spring продвигает для построения масштабируемых систем.
#Java #middle #Spring_Cloud_Gateway
В монолитной архитектуре приложение имеет одну точку входа — HTTP-порт, через который проходят все запросы. Клиент взаимодействует с единым целым. При переходе к микросервисам эта модель разрушается: вместо одного приложения появляются десятки или сотни независимых сервисов, каждый со своим API и сетевым адресом. Прямое обращение клиентов ко всем сервисам создаёт фундаментальные проблемы: клиент должен знать топологию сети, обеспечивать отказоустойчивость для каждого вызова, дублировать логику аутентификации и преобразования данных. Именно здесь возникает необходимость в паттерне API Gateway — единой интеллектуальной точке входа, которая инкапсулирует внутреннюю структуру системы и предоставляет клиентам унифицированный интерфейс. Spring Cloud Gateway (SCG) — это реализация этого паттерна в экосистеме Spring, построенная на реактивной парадигме для удовлетворения требований современных высоконагруженных распределённых систем.
Архитектурное позиционирование и место в экосистеме
Spring Cloud Gateway функционирует как шлюз прикладного уровня (Layer 7) в модели OSI.
Его позиция строго определена: между внешними клиентами (мобильные приложения, браузеры, сторонние системы) и внутренним кластером микросросервисов. Он не является заменой балансировщику нагрузки сетевого уровня (например, AWS NLB или hardware-балансировщику), но работает в тесной связке с ним. Типичная многоуровневая архитектура включает внешний балансировщик, который распределяет трафик между несколькими инстансами SCG для обеспечения отказоустойчивости и масштабируемости, а сам SCG уже занимается интеллектуальной маршрутизацией к конкретным сервисам.
В экосистеме Spring Cloud Gateway является эволюционным преемником Zuul 1.x. Zuul 1, построенный на блокирующем сервлетном API, имел архитектурные ограничения, связанные с выделением потока на каждый соединение, что создавало проблемы при большом количестве одновременных соединений, особенно с длительными запросами (например, Server-Sent Events, WebSockets). SCG был создан с нуля на реактивном стеке Spring WebFlux и проекте Reactor, что позволило реализовать полностью неблокирующую, асинхронную архитектуру, способную эффективно работать с тысячами одновременных соединений на скромных аппаратных ресурсах. Это стратегическое выравнивание с реактивной парадигмой, которую Spring продвигает для построения масштабируемых систем.
#Java #middle #Spring_Cloud_Gateway
👍3
Детальный разбор решаемых проблем
1. Интеллектуальная маршрутизация и абстракция сервисов
Базовая и критически важная функция — динамическая маршрутизация запроса к соответствующему backend-сервису на основе содержимого запроса. SCG анализирует HTTP-запросы (путь, заголовки, параметры) и, используя механизм предикатов, определяет, какой маршрут должен быть применён. Каждый маршрут связан с определённым URI назначения (например, lb://SERVICE-NAME при использовании Service Discovery через Spring Cloud LoadBalancer). Это позволяет полностью скрыть от клиента реальные сетевые адреса и даже имена хостов сервисов. Клиент обращается к api.company.com/orders, а шлюз решает, что этот запрос должен уйти в сервис order-service-v2, работающий в трёх экземплярах. Механизм балансировки нагрузки на стороне клиента (client-side load balancing) интегрирован непосредственно в процесс проксирования.
2. Централизованная безопасность и контроль доступа
Вместо того чтобы встраивать идентификацию и авторизацию в каждый микросервис, что приводит к дублированию кода и сложности управления политиками, SCG позволяет централизовать эту логику. Типичный сценарий: фильтр шлюза (Gateway Filter) перехватывает входящий запрос, извлекает JWT-токен из заголовка Authorization, валидирует его подпись и срок действия, декодирует claims (утверждения) и либо добавляет обогащённую информацию (например, роли пользователя) в заголовки для передачи в нижестоящий сервис, либо сразу отвергает запрос с кодом 401 или 403. Это реализует паттерн "валидация токена на периметре". Таким образом, внутренние сервисы могут доверять данным из заголовков (которые, впрочем, должны проверяться на целостность в средах с высокими требованиями безопасности), что избавляет их от необходимости иметь доступ к секретам для проверки подписи JWT.
3. Применение кросс-сервисных политик
Многие требования, такие как ограничение частоты запросов (rate limiting), применяются на уровне всего API или конкретного пользователя, а не отдельного сервиса. SCG может интегрироваться с системами вроде Redis для реализации алгоритмов ограничения (например, "token bucket" или "sliding window"). Фильтр шлюза считает количество запросов с определённого ключа (IP, user ID, API key) за временное окно и блокирует превысившие лимит запросы до того, как они создадут нагрузку на бизнес-сервисы. Аналогично реализуется политика Circuit Breaker (размыкатель цепи): SCG отслеживает ошибки или задержки при вызовах к конкретному сервису и при достижении порога временно "разрывает цепь", перенаправляя запросы на заранее определённый fallback-ответ (например, кэшированные данные или заглушку), не нагружая падающий сервис. Это повышает отказоустойчивость всей системы.
4. Наблюдаемость и анализ трафика (Observability)
Как критически важный узел, через который проходит весь трафик, SCG является идеальным местом для сбора телеметрии. Он может автоматически генерировать метрики (например, количество запросов в секунду, задержки, процент ошибок) для каждого маршрута и экспортировать их в системы мониторинга типа Prometheus через Micrometer. Кроме того, он присваивает и распространяет уникальные идентификаторы запросов (trace ID), которые позволяют агрегаторам трассировки, таким как Zipkin или Sleuth, восстановить полный путь запроса по всем микросервисам. Это обеспечивает сквозную видимость, без которой отладка распределённой системы крайне затруднена.
5. Трансформация запросов и ответов
SCG выполняет роль адаптера между внешним и внутренним API. Это может быть простая перезапись путей (rewrite path): клиент отправляет запрос на /api/v1/user, а шлюз перенаправляет его на внутренний сервис по пути /user. Более сложные сценарии включают модификацию заголовков (добавление, удаление), трансформацию тела запроса/ответа (например, из XML в JSON) с помощью встроенных или кастомных фильтров. Это позволяет внутренним сервисам эволюционировать независимо от клиентов, а шлюзу — обеспечивать обратную совместимость.
#Java #middle #Spring_Cloud_Gateway
1. Интеллектуальная маршрутизация и абстракция сервисов
Базовая и критически важная функция — динамическая маршрутизация запроса к соответствующему backend-сервису на основе содержимого запроса. SCG анализирует HTTP-запросы (путь, заголовки, параметры) и, используя механизм предикатов, определяет, какой маршрут должен быть применён. Каждый маршрут связан с определённым URI назначения (например, lb://SERVICE-NAME при использовании Service Discovery через Spring Cloud LoadBalancer). Это позволяет полностью скрыть от клиента реальные сетевые адреса и даже имена хостов сервисов. Клиент обращается к api.company.com/orders, а шлюз решает, что этот запрос должен уйти в сервис order-service-v2, работающий в трёх экземплярах. Механизм балансировки нагрузки на стороне клиента (client-side load balancing) интегрирован непосредственно в процесс проксирования.
2. Централизованная безопасность и контроль доступа
Вместо того чтобы встраивать идентификацию и авторизацию в каждый микросервис, что приводит к дублированию кода и сложности управления политиками, SCG позволяет централизовать эту логику. Типичный сценарий: фильтр шлюза (Gateway Filter) перехватывает входящий запрос, извлекает JWT-токен из заголовка Authorization, валидирует его подпись и срок действия, декодирует claims (утверждения) и либо добавляет обогащённую информацию (например, роли пользователя) в заголовки для передачи в нижестоящий сервис, либо сразу отвергает запрос с кодом 401 или 403. Это реализует паттерн "валидация токена на периметре". Таким образом, внутренние сервисы могут доверять данным из заголовков (которые, впрочем, должны проверяться на целостность в средах с высокими требованиями безопасности), что избавляет их от необходимости иметь доступ к секретам для проверки подписи JWT.
3. Применение кросс-сервисных политик
Многие требования, такие как ограничение частоты запросов (rate limiting), применяются на уровне всего API или конкретного пользователя, а не отдельного сервиса. SCG может интегрироваться с системами вроде Redis для реализации алгоритмов ограничения (например, "token bucket" или "sliding window"). Фильтр шлюза считает количество запросов с определённого ключа (IP, user ID, API key) за временное окно и блокирует превысившие лимит запросы до того, как они создадут нагрузку на бизнес-сервисы. Аналогично реализуется политика Circuit Breaker (размыкатель цепи): SCG отслеживает ошибки или задержки при вызовах к конкретному сервису и при достижении порога временно "разрывает цепь", перенаправляя запросы на заранее определённый fallback-ответ (например, кэшированные данные или заглушку), не нагружая падающий сервис. Это повышает отказоустойчивость всей системы.
4. Наблюдаемость и анализ трафика (Observability)
Как критически важный узел, через который проходит весь трафик, SCG является идеальным местом для сбора телеметрии. Он может автоматически генерировать метрики (например, количество запросов в секунду, задержки, процент ошибок) для каждого маршрута и экспортировать их в системы мониторинга типа Prometheus через Micrometer. Кроме того, он присваивает и распространяет уникальные идентификаторы запросов (trace ID), которые позволяют агрегаторам трассировки, таким как Zipkin или Sleuth, восстановить полный путь запроса по всем микросервисам. Это обеспечивает сквозную видимость, без которой отладка распределённой системы крайне затруднена.
5. Трансформация запросов и ответов
SCG выполняет роль адаптера между внешним и внутренним API. Это может быть простая перезапись путей (rewrite path): клиент отправляет запрос на /api/v1/user, а шлюз перенаправляет его на внутренний сервис по пути /user. Более сложные сценарии включают модификацию заголовков (добавление, удаление), трансформацию тела запроса/ответа (например, из XML в JSON) с помощью встроенных или кастомных фильтров. Это позволяет внутренним сервисам эволюционировать независимо от клиентов, а шлюзу — обеспечивать обратную совместимость.
#Java #middle #Spring_Cloud_Gateway
👍2🤯1
Конкурентный ландшафт и выбор технологии
Рынок gateway-решений насыщен. SCG не единственный и не универсальный вариант.
Kong
Сильный, промышленный, плагинно-ориентированный API-gateway на базе NGINX и LuaJIT. Скорее всего превосходит SCG по пропускной способности на уровне низкоуровневой сети. Но менее гибок для JVM-экосистемы и глубокой интеграции с Spring.
NGINX
Высокопроизводительный L7-proxy, но без богатой программируемости. SCG выигрывает там, где нужны сложные фильтры и логика на Java/Kotlin.
Envoy
Современный proxy, облачная стандартизация, основа для Istio. Максимально производительный, нативный, ориентирован на service mesh. SCG выигрывает на уровне интеграции с приложением и кастомизируемости внутри JVM.
Traefik
Простой, легкий, динамический, ориентирован на Docker/Kubernetes. SCG более мощен при построении сложных политик, при наличии Spring-экосистемы.
Spring Cloud Gateway vs. Spring MVC (и Zuul 1)
Здесь различие фундаментально и лежит в плоскости архитектурной парадигмы.
Spring MVC и Zuul 1 построены на сервлетной модели, которая привязывает каждый HTTP-запрос к потоку (thread) на всё время его обработки. Потоки — дорогой ресурс, их количество в пуле ограничено (часто 200-500). Когда все потоки заняты ожиданием ответа от медленного backend-сервиса, шлюз перестаёт принимать новые запросы, даже если CPU простаивает. SCG, построенный на WebFlux и Reactor Netty, использует событийно-ориентированную, неблокирующую модель. Небольшое количество потоков (часто равное количеству ядер CPU) обрабатывает множество соединений. Когда запрос проксируется к backend-сервису, поток не блокируется в ожидании ответа, а освобождается для обработки других событий (новых запросов или пришедших ответов). Колбэк вызывается, когда ответ готов. Это позволяет одному экземпляру SCG эффективно обслуживать десятки тысяч одновременных long-lived соединений (например, для streaming API) с предскатуемым потреблением памяти. С точки зрения JVM, это означает отказ от пула потоков Tomcat/Jetty и работу на основе NIO-селекторов в Netty, где события диспетчеризуются ядром Reactor.
Архитектура: Reactor Netty и WebFlux
Работа Spring Cloud Gateway начинается с автоконфигурации Spring Boot. Ядром является ReactorNettyHttpPredicateHandlerMapping. Весь входящий трафик принимается сервером Netty, который работает на реактивном канале HttpServer.
Когда Netty принимает новый HTTP-запрос, он преобразует его в реактивный тип ServerHttpRequest и запускает цепочку обработки.
Основной цикл выглядит так:
Сопоставление маршрута (Route Predicate Handler Mapping): Для входящего ServerHttpRequest проверяются все определённые в контексте маршруты (Route). Каждый маршрут содержит коллекцию Predicate. Предикаты — это условия на основе запроса (например, Path=/api/**, Header=X-Request-Id, Method=GET). Проверка выполняется последовательно до первого совпадения. Этот процесс не блокирующий, все предикаты оцениваются в том же реактивном потоке.
Сборка цепочки фильтров (Filtering Web Handler): Найденный маршрут содержит упорядоченный список фильтров (GatewayFilter) и URI назначения. Формируется цепочка обработки DefaultGatewayFilterChain. Фильтры делятся на два типа: "pre-filters" (выполняются до вызова проксируемого сервиса) и "post-filters" (выполняются после получения ответа). Сам вызов проксируемого сервиса также реализован как специальный фильтр — NettyRoutingFilter.
Выполнение цепочки фильтров (Reactive Pipeline): Цепочка выполняется как реактивный пайплайн. Например, пре-фильтр аутентификации проверяет токен, используя реактивный ReactiveJwtDecoder, который не блокирует поток. Если вызов к сервису ключей необходим, он выполняется асинхронно. Затем фильтр преобразования путей модифицирует ServerHttpRequest. Ключевой фильтр LoadBalancerClientFilter взаимодействует с реактивным ReactorLoadBalancer для преобразования логического имени сервиса (из lb://SERVICE) в реальный физический адрес, выбранный с учётом балансировки.
#Java #middle #Spring_Cloud_Gateway
Рынок gateway-решений насыщен. SCG не единственный и не универсальный вариант.
Kong
Сильный, промышленный, плагинно-ориентированный API-gateway на базе NGINX и LuaJIT. Скорее всего превосходит SCG по пропускной способности на уровне низкоуровневой сети. Но менее гибок для JVM-экосистемы и глубокой интеграции с Spring.
NGINX
Высокопроизводительный L7-proxy, но без богатой программируемости. SCG выигрывает там, где нужны сложные фильтры и логика на Java/Kotlin.
Envoy
Современный proxy, облачная стандартизация, основа для Istio. Максимально производительный, нативный, ориентирован на service mesh. SCG выигрывает на уровне интеграции с приложением и кастомизируемости внутри JVM.
Traefik
Простой, легкий, динамический, ориентирован на Docker/Kubernetes. SCG более мощен при построении сложных политик, при наличии Spring-экосистемы.
Spring Cloud Gateway vs. Spring MVC (и Zuul 1)
Здесь различие фундаментально и лежит в плоскости архитектурной парадигмы.
Spring MVC и Zuul 1 построены на сервлетной модели, которая привязывает каждый HTTP-запрос к потоку (thread) на всё время его обработки. Потоки — дорогой ресурс, их количество в пуле ограничено (часто 200-500). Когда все потоки заняты ожиданием ответа от медленного backend-сервиса, шлюз перестаёт принимать новые запросы, даже если CPU простаивает. SCG, построенный на WebFlux и Reactor Netty, использует событийно-ориентированную, неблокирующую модель. Небольшое количество потоков (часто равное количеству ядер CPU) обрабатывает множество соединений. Когда запрос проксируется к backend-сервису, поток не блокируется в ожидании ответа, а освобождается для обработки других событий (новых запросов или пришедших ответов). Колбэк вызывается, когда ответ готов. Это позволяет одному экземпляру SCG эффективно обслуживать десятки тысяч одновременных long-lived соединений (например, для streaming API) с предскатуемым потреблением памяти. С точки зрения JVM, это означает отказ от пула потоков Tomcat/Jetty и работу на основе NIO-селекторов в Netty, где события диспетчеризуются ядром Reactor.
Архитектура: Reactor Netty и WebFlux
Работа Spring Cloud Gateway начинается с автоконфигурации Spring Boot. Ядром является ReactorNettyHttpPredicateHandlerMapping. Весь входящий трафик принимается сервером Netty, который работает на реактивном канале HttpServer.
Когда Netty принимает новый HTTP-запрос, он преобразует его в реактивный тип ServerHttpRequest и запускает цепочку обработки.
Основной цикл выглядит так:
Сопоставление маршрута (Route Predicate Handler Mapping): Для входящего ServerHttpRequest проверяются все определённые в контексте маршруты (Route). Каждый маршрут содержит коллекцию Predicate. Предикаты — это условия на основе запроса (например, Path=/api/**, Header=X-Request-Id, Method=GET). Проверка выполняется последовательно до первого совпадения. Этот процесс не блокирующий, все предикаты оцениваются в том же реактивном потоке.
Сборка цепочки фильтров (Filtering Web Handler): Найденный маршрут содержит упорядоченный список фильтров (GatewayFilter) и URI назначения. Формируется цепочка обработки DefaultGatewayFilterChain. Фильтры делятся на два типа: "pre-filters" (выполняются до вызова проксируемого сервиса) и "post-filters" (выполняются после получения ответа). Сам вызов проксируемого сервиса также реализован как специальный фильтр — NettyRoutingFilter.
Выполнение цепочки фильтров (Reactive Pipeline): Цепочка выполняется как реактивный пайплайн. Например, пре-фильтр аутентификации проверяет токен, используя реактивный ReactiveJwtDecoder, который не блокирует поток. Если вызов к сервису ключей необходим, он выполняется асинхронно. Затем фильтр преобразования путей модифицирует ServerHttpRequest. Ключевой фильтр LoadBalancerClientFilter взаимодействует с реактивным ReactorLoadBalancer для преобразования логического имени сервиса (из lb://SERVICE) в реальный физический адрес, выбранный с учётом балансировки.
#Java #middle #Spring_Cloud_Gateway
👍1🤯1
Проксирование запроса (NettyRoutingFilter): Это кульминация. Фильтр берет обогащённый ServerHttpRequest, конвертирует его в запрос Netty (HttpClientRequest) и отправляет через неблокирующий HTTP-клиент Netty (HttpClient) к целевому сервису. Клиент Netty использует ту же событийно-ориентированную модель. Запрос ставится в очередь на отправку, и текущий поток немедленно освобождается. Когда от backend-сервиса приходит ответ (HttpClientResponse), Netty генерирует событие, которое подхватывается реактивным пайплайном, преобразуя ответ в ServerHttpResponse.
Обработка ответа (Post-Filters): Запускается "post-filter" часть цепочки. Здесь могут работать фильтры добавления стандартных заголовков, логирования, преобразования тела ответа. Итоговый ServerHttpResponse записывается в исходный канал Netty к клиенту.
В памяти JVM это проявляется как доминирование объектов реактивных стримов (Mono, Flux), цепочек операторов и лямбда-выражений в heap. Стек вызовов глубокий, но асинхронный: в дампе потока вы не увидите блокирующего вызова HttpClient. Вместо этого увидите фреймы типа onNext, onComplete из реализации Reactor. Пул потоков Netty (обычно reactor-http-nio-) активен, но количество потоков мало. Основное потребление памяти связано с буферами Netty для HTTP-сообщений (которые используют пул ByteBuf для эффективного управления), и объектами, представляющими запросы/ответы.
Типичные сценарии реализации
Rate Limiting с использованием Redis: Фильтр, реализующий алгоритм "скользящего окна". Для каждого запроса вычисляется ключ (например, user:123:path:/api/orders). С помощью реактивного клиента Redis (ReactiveRedisTemplate) выполняются команды ZREMRANGEBYSCORE (удаление старых записей) и ZADD + ZCOUNT (добавление текущего запроса и подсчёт количества запросов в окне). Вся эта последовательность выполняется как атомарный Lua-скрипт на стороне Redis для обеспечения консистентности. Если лимит превышен, цепочка прерывается с возвратом 429 Too Many Requests.
Аутентификация и передача контекста: Кастомный GatewayFilter в порядке pre извлекает JWT из заголовка. Используя ReactiveJwtDecoder (который может кэшировать JWK для проверки подписи), токен декодируется. Из claims извлекается идентификатор пользователя и его роли, которые затем добавляются в заголовки запроса, например, X-User-Id и X-User-Roles. Важный нюанс: для предотвращения подмены заголовков внутренними сервисами, эти заголовки должны либо очищаться шлюзом от входящих значений, либо внутренние сервисы должны доверять только конкретным заголовкам, установленным шлюзом (что может быть обеспечено настройками сетевой безопасности).
API Composition (Агрегация): Хотя SCG не является специализированным агрегатором (как GraphQL BFF), он может выполнять простую агрегацию с помощью фильтра ModifyResponseBodyGatewayFilterFactory. Например, клиенту нужны данные пользователя вместе с его последним заказом. Шлюз может последовательно вызвать user-service и, используя данные из ответа, вызвать order-service, а затем объединить результаты в единый JSON. Эта операция выполняется неблокирующе с помощью операторов Reactor flatMap или zip. Однако для сложных агрегаций с множественными зависимостями предпочтительнее выделенный BFF-сервис.
Circuit Breaker с Resilience4J: SCG интегрируется с Resilience4J через конфигурацию. Для маршрута определяется конфигурация Circuit Breaker с параметрами порога ошибок, временем ожидания в полуоткрытом состоянии и т.д. Когда фильтр активирован, все вызовы через него оборачиваются в защитный контур. В случае открытия контура запросы не идут к падающему сервису, а перенаправляются на заданный fallbackUri, который может указывать на статический ответ или простой сервис-заглушку, возвращающий данные из кэша.
#Java #middle #Spring_Cloud_Gateway
Обработка ответа (Post-Filters): Запускается "post-filter" часть цепочки. Здесь могут работать фильтры добавления стандартных заголовков, логирования, преобразования тела ответа. Итоговый ServerHttpResponse записывается в исходный канал Netty к клиенту.
В памяти JVM это проявляется как доминирование объектов реактивных стримов (Mono, Flux), цепочек операторов и лямбда-выражений в heap. Стек вызовов глубокий, но асинхронный: в дампе потока вы не увидите блокирующего вызова HttpClient. Вместо этого увидите фреймы типа onNext, onComplete из реализации Reactor. Пул потоков Netty (обычно reactor-http-nio-) активен, но количество потоков мало. Основное потребление памяти связано с буферами Netty для HTTP-сообщений (которые используют пул ByteBuf для эффективного управления), и объектами, представляющими запросы/ответы.
Типичные сценарии реализации
Rate Limiting с использованием Redis: Фильтр, реализующий алгоритм "скользящего окна". Для каждого запроса вычисляется ключ (например, user:123:path:/api/orders). С помощью реактивного клиента Redis (ReactiveRedisTemplate) выполняются команды ZREMRANGEBYSCORE (удаление старых записей) и ZADD + ZCOUNT (добавление текущего запроса и подсчёт количества запросов в окне). Вся эта последовательность выполняется как атомарный Lua-скрипт на стороне Redis для обеспечения консистентности. Если лимит превышен, цепочка прерывается с возвратом 429 Too Many Requests.
Аутентификация и передача контекста: Кастомный GatewayFilter в порядке pre извлекает JWT из заголовка. Используя ReactiveJwtDecoder (который может кэшировать JWK для проверки подписи), токен декодируется. Из claims извлекается идентификатор пользователя и его роли, которые затем добавляются в заголовки запроса, например, X-User-Id и X-User-Roles. Важный нюанс: для предотвращения подмены заголовков внутренними сервисами, эти заголовки должны либо очищаться шлюзом от входящих значений, либо внутренние сервисы должны доверять только конкретным заголовкам, установленным шлюзом (что может быть обеспечено настройками сетевой безопасности).
API Composition (Агрегация): Хотя SCG не является специализированным агрегатором (как GraphQL BFF), он может выполнять простую агрегацию с помощью фильтра ModifyResponseBodyGatewayFilterFactory. Например, клиенту нужны данные пользователя вместе с его последним заказом. Шлюз может последовательно вызвать user-service и, используя данные из ответа, вызвать order-service, а затем объединить результаты в единый JSON. Эта операция выполняется неблокирующе с помощью операторов Reactor flatMap или zip. Однако для сложных агрегаций с множественными зависимостями предпочтительнее выделенный BFF-сервис.
Circuit Breaker с Resilience4J: SCG интегрируется с Resilience4J через конфигурацию. Для маршрута определяется конфигурация Circuit Breaker с параметрами порога ошибок, временем ожидания в полуоткрытом состоянии и т.д. Когда фильтр активирован, все вызовы через него оборачиваются в защитный контур. В случае открытия контура запросы не идут к падающему сервису, а перенаправляются на заданный fallbackUri, который может указывать на статический ответ или простой сервис-заглушку, возвращающий данные из кэша.
#Java #middle #Spring_Cloud_Gateway
👍1🤯1