Spring Cloud Gateway WebFlux 模式架构分析
请关注微信公众号:阿呆-bot
1. 入口类及关键类关系
1.1 入口类
Spring Cloud Gateway WebFlux 模式的入口类是 GatewayAutoConfiguration,这是整个 WebFlux 模式的"总指挥"。它负责配置所有 Gateway 需要的组件。
java
@Configuration(proxyBeanMethods = false)
@ConditionalOnProperty(name = "spring.cloud.gateway.server.webflux.enabled", matchIfMissing = true)
@EnableConfigurationProperties
@AutoConfigureBefore({ HttpHandlerAutoConfiguration.class, WebFluxAutoConfiguration.class })
@AutoConfigureAfter({ GatewayReactiveLoadBalancerClientAutoConfiguration.class,
GatewayClassPathWarningAutoConfiguration.class })
@ConditionalOnClass(DispatcherHandler.class)
public class GatewayAutoConfiguration {
// 核心 Bean 定义
}
关键特性说明:
-
@AutoConfigureBefore({ HttpHandlerAutoConfiguration.class, WebFluxAutoConfiguration.class })- 这个很关键!Gateway 必须在 WebFlux 的默认配置之前加载
- 为什么?因为 Gateway 需要注册自己的
HandlerMapping(RoutePredicateHandlerMapping) - 如果 WebFlux 的默认配置先加载,可能会注册其他的 HandlerMapping,导致路由冲突
- Gateway 的 HandlerMapping 优先级更高,会优先处理请求
-
@ConditionalOnClass(DispatcherHandler.class)- 这个注解确保只有在 WebFlux 存在时才加载 Gateway
DispatcherHandler是 WebFlux 的核心组件,类似于 WebMVC 的DispatcherServlet- 如果没有 WebFlux,Gateway WebFlux 模式就无法工作
-
@ConditionalOnPropertyyaml# 可以通过配置控制是否启用 spring: cloud: gateway: server: webflux: enabled: true # 默认启用,可以设置为 false 禁用
配置的核心组件:
RouteLocator:路由定位器,负责提供路由列表FilteringWebHandler:过滤器处理器,负责执行过滤器链RoutePredicateHandlerMapping:路由匹配器,负责匹配请求到路由GatewayProperties:Gateway 配置属性
1.2 关键类关系图
1.3 核心组件说明
RoutePredicateHandlerMapping
这是 Gateway 的路由匹配器,负责找到匹配的路由。它继承自 Spring WebFlux 的 AbstractHandlerMapping。
工作原理:
java
@Override
protected Mono<?> getHandlerInternal(ServerWebExchange exchange) {
// 1. 查找匹配的路由(异步操作)
return lookupRoute(exchange)
.map(route -> {
// 2. 把路由信息存储到 Exchange 的属性中
exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, route);
// 3. 返回 FilteringWebHandler 作为处理器
return webHandler;
});
}
实际例子:
java
// 假设有这些路由配置
routes = [
{ id: "user-service", path: "/api/users/**", uri: "http://user-service" },
{ id: "order-service", path: "/api/orders/**", uri: "http://order-service" }
]
// 请求:GET /api/users/123
// lookupRoute() 会:
// 1. 遍历所有路由
// 2. 使用 AsyncPredicate 异步匹配
// 3. 找到匹配的路由:user-service
// 4. 返回 FilteringWebHandler
关键点:
lookupRoute()返回Mono<Route>,是异步的- 路由匹配使用
AsyncPredicate,支持异步条件判断 - 匹配成功后,路由信息存储在
ServerWebExchange的属性中
FilteringWebHandler
这是 Gateway 的核心请求处理器,负责执行过滤器链。它实现了 Spring WebFlux 的 WebHandler 接口。
工作原理:
java
@Override
public Mono<Void> handle(ServerWebExchange exchange) {
// 1. 从 Exchange 中获取路由信息(路由匹配时设置的)
Route route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR);
// 2. 获取合并后的过滤器列表(全局过滤器 + 路由过滤器)
List<GatewayFilter> combined = getCombinedFilters(route);
// 3. 创建过滤器链并执行
return new DefaultGatewayFilterChain(combined).filter(exchange);
}
实际例子:
java
// 假设路由配置了这些过滤器
route.filters = [
AddRequestHeaderFilter,
RateLimitFilter,
NettyRoutingFilter // 最后一个,负责实际转发请求
]
// FilteringWebHandler 会:
// 1. 合并全局过滤器和路由过滤器
// 2. 按 Order 排序
// 3. 创建过滤器链
// 4. 依次执行过滤器
过滤器链执行:
java
// 过滤器链的实现(责任链模式)
private static class DefaultGatewayFilterChain implements GatewayFilterChain {
@Override
public Mono<Void> filter(ServerWebExchange exchange) {
return Mono.defer(() -> {
if (this.index < filters.size()) {
GatewayFilter filter = filters.get(this.index);
// 创建下一个链节点
DefaultGatewayFilterChain chain = new DefaultGatewayFilterChain(this, this.index + 1);
// 执行当前过滤器,传入下一个链节点
return filter.filter(exchange, chain);
}
return Mono.empty(); // 所有过滤器执行完毕
});
}
}
RouteLocator
路由定位器,负责提供路由列表。Gateway 支持多个 RouteLocator,可以组合使用。
工作原理:
java
@Bean
@Primary
public RouteLocator cachedCompositeRouteLocator(List<RouteLocator> routeLocators) {
// 1. 组合多个 RouteLocator
CompositeRouteLocator composite = new CompositeRouteLocator(
Flux.fromIterable(routeLocators)
);
// 2. 添加缓存(提高性能)
return new CachingRouteLocator(composite);
}
实际例子:
java
// 可以有多个 RouteLocator
RouteLocator[] locators = [
PropertiesRouteDefinitionLocator, // 从配置文件读取路由
DiscoveryClientRouteDefinitionLocator, // 从服务发现读取路由
InMemoryRouteDefinitionRepository // 从内存(API)读取路由
]
// CompositeRouteLocator 会合并所有路由
// 返回 Flux<Route>,包含所有路由
路由来源:
-
配置文件 :
PropertiesRouteDefinitionLocatoryamlspring: cloud: gateway: routes: - id: user-service uri: http://localhost:8081 -
服务发现 :
DiscoveryClientRouteDefinitionLocatorjava// 自动从 Eureka/Consul 等服务注册中心发现服务 // 为每个服务自动创建路由 -
API 动态配置 :
InMemoryRouteDefinitionRepositoryjava// 通过 API 动态添加/删除路由 routeDefinitionRepository.save(routeDefinition);
2. 关键流程描述
2.1 请求处理流程时序图
2.2 路由匹配流程
路由匹配是 Gateway 的核心功能。让我们用一个实际例子来说明整个流程:
场景 :客户端请求 GET /api/users/123
详细流程:
-
DispatcherHandler 接收 HTTP 请求
客户端 → DispatcherHandler → GatewayDispatcherHandler是 WebFlux 的请求分发器,类似于 WebMVC 的DispatcherServlet- 它会把请求交给合适的
HandlerMapping处理 - Gateway 的
RoutePredicateHandlerMapping优先级很高,会优先处理
-
RoutePredicateHandlerMapping 从 RouteLocator 获取所有路由
java// 获取所有路由(返回 Flux<Route>,是响应式的) Flux<Route> routes = routeLocator.getRoutes(); // 实际的路由列表可能是: // [ // { id: "user-service", path: "/api/users/**", uri: "http://user-service" }, // { id: "order-service", path: "/api/orders/**", uri: "http://order-service" } // ]RouteLocator可能从多个来源获取路由(配置文件、服务发现、API)- 返回的是
Flux<Route>,是响应式的流
-
使用 AsyncPredicate 异步匹配路由
java// 异步匹配路由 return routes .filterWhen(route -> { // 使用 AsyncPredicate 异步匹配 return route.getPredicate().test(exchange); }) .next(); // 返回第一个匹配的路由匹配过程:
java// 路由1:user-service AsyncPredicate predicate1 = exchange -> { String path = exchange.getRequest().getPath().value(); return Mono.just(path.startsWith("/api/users/")); // 异步返回 true/false }; // 路径 "/api/users/123" 匹配 "/api/users/**" ✓ // 路由2:order-service AsyncPredicate predicate2 = exchange -> { String path = exchange.getRequest().getPath().value(); return Mono.just(path.startsWith("/api/orders/")); // 异步返回 false }; // 路径 "/api/users/123" 不匹配 "/api/orders/**" ✗- 使用
AsyncPredicate异步匹配,支持异步条件判断 - 可以在这里做异步操作(比如查询 Redis、数据库等)
- 返回
Mono<Boolean>,不会阻塞线程
- 使用
-
找到匹配的路由后,将路由信息存储到 ServerWebExchange 的属性中
java// 匹配成功后 Route matchedRoute = ...; // user-service 路由 // 存储路由信息到 Exchange 的属性中 exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, matchedRoute); exchange.getAttributes().put(GATEWAY_REQUEST_URL_ATTR, matchedRoute.getUri());- 路由信息存储在
ServerWebExchange的属性中 - 后续的过滤器可以从这里获取路由信息
- 比如
NettyRoutingFilter会从这里获取目标 URI
- 路由信息存储在
-
返回 FilteringWebHandler 作为处理器
java// 返回 FilteringWebHandler return Mono.just(webHandler);FilteringWebHandler会负责执行过滤器链- 最终会调用
NettyRoutingFilter转发请求到下游服务
完整示例:
yaml
# 配置文件
spring:
cloud:
gateway:
routes:
- id: user-service
uri: http://user-service:8081
predicates:
- Path=/api/users/**
- Method=GET
匹配过程:
- 请求
GET /api/users/123到达 - 路径
/api/users/123匹配/api/users/**✓ - 方法
GET匹配GET✓ - 找到匹配的路由
user-service - 返回
FilteringWebHandler,目标 URI 是http://user-service:8081
2.3 过滤器链执行流程
过滤器链是 Gateway 的核心机制。让我们用一个实际例子来说明:
场景:请求已经匹配到路由,现在需要执行过滤器链
详细流程:
-
FilteringWebHandler 从路由中获取过滤器列表
javaRoute route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR); List<GatewayFilter> routeFilters = route.getFilters(); // 假设路由配置了这些过滤器: // [AddRequestHeaderFilter, RateLimitFilter]- 从路由中获取路由级别的过滤器
- 这些过滤器只应用于当前路由
-
合并全局过滤器和路由过滤器,按 Order 排序
java// 全局过滤器(应用于所有路由) List<GlobalFilter> globalFilters = [ LoadBalancerClientFilter, // Order: 10100 NettyRoutingFilter, // Order: Ordered.LOWEST_PRECEDENCE NettyWriteResponseFilter // Order: Ordered.LOWEST_PRECEDENCE - 1 ]; // 路由过滤器 List<GatewayFilter> routeFilters = [ AddRequestHeaderFilter, // Order: 1000 RateLimitFilter // Order: -100 ]; // 合并并排序 List<GatewayFilter> combined = [ RateLimitFilter, // -100 (最高优先级) AddRequestHeaderFilter, // 1000 LoadBalancerClientFilter, // 10100 NettyRoutingFilter, // LOWEST_PRECEDENCE NettyWriteResponseFilter // LOWEST_PRECEDENCE - 1 ];- 全局过滤器 + 路由过滤器 = 合并后的过滤器列表
- 按
Order排序,数字越小优先级越高 Ordered.LOWEST_PRECEDENCE是最大整数,优先级最低
-
创建 DefaultGatewayFilterChain,实现责任链模式
java// 创建过滤器链 DefaultGatewayFilterChain chain = new DefaultGatewayFilterChain(combined); // 过滤器链的内部实现 private static class DefaultGatewayFilterChain implements GatewayFilterChain { private final int index; // 当前执行的过滤器索引 private final List<GatewayFilter> filters; @Override public Mono<Void> filter(ServerWebExchange exchange) { return Mono.defer(() -> { if (this.index < filters.size()) { GatewayFilter filter = filters.get(this.index); // 创建下一个链节点 DefaultGatewayFilterChain nextChain = new DefaultGatewayFilterChain(this, this.index + 1); // 执行当前过滤器,传入下一个链节点 return filter.filter(exchange, nextChain); } return Mono.empty(); // 所有过滤器执行完毕 }); } }- 使用责任链模式,每个过滤器都可以决定是否继续执行下一个过滤器
- 通过递归创建链节点来实现
-
递归执行过滤器
java// 执行流程(简化版) RateLimitFilter.filter(exchange, chain1) -> 检查限流 -> chain1.filter(exchange) // 调用下一个过滤器 -> AddRequestHeaderFilter.filter(exchange, chain2) -> 添加请求头 -> chain2.filter(exchange) // 调用下一个过滤器 -> LoadBalancerClientFilter.filter(exchange, chain3) -> 负载均衡选择实例 -> chain3.filter(exchange) -> NettyRoutingFilter.filter(exchange, chain4) -> 转发请求到下游服务 -> chain4.filter(exchange) -> NettyWriteResponseFilter.filter(exchange, chain5) -> 写入响应 -> chain5.filter(exchange) -> Mono.empty() // 所有过滤器执行完毕- 每个过滤器调用
chain.filter(exchange)来执行下一个过滤器 - 如果某个过滤器不想继续执行,可以不调用
chain.filter() - 比如限流过滤器,如果限流了,就直接返回错误,不继续执行
- 每个过滤器调用
-
NettyRoutingFilter 作为最后一个过滤器,执行实际的 HTTP 请求
java// NettyRoutingFilter 的实现(简化版) @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { URI requestUrl = exchange.getRequiredAttribute(GATEWAY_REQUEST_URL_ATTR); // 使用 Reactor Netty HttpClient 发送请求(非阻塞) return httpClient.get() .uri(requestUrl) .send((req, nettyOutbound) -> nettyOutbound.send(request.getBody())) .responseConnection((res, connection) -> { // 设置响应到 Exchange exchange.getAttributes().put(CLIENT_RESPONSE_ATTR, res); return Mono.just(res); }) .then(chain.filter(exchange)); // 继续执行下一个过滤器 }NettyRoutingFilter使用 Reactor Netty 的HttpClient发送请求- 这是非阻塞的,线程不会在这里等待
- 响应到达后,会继续执行下一个过滤器(
NettyWriteResponseFilter)
-
响应通过 Mono 链式返回
java// 响应返回流程 NettyWriteResponseFilter.filter(exchange, chain) -> 写入响应到客户端 -> Mono.empty() // 完成 -> 返回给 NettyRoutingFilter -> 返回给 LoadBalancerClientFilter -> 返回给 AddRequestHeaderFilter -> 返回给 RateLimitFilter -> 返回给 FilteringWebHandler -> 返回给 RoutePredicateHandlerMapping -> 返回给 DispatcherHandler -> 返回给客户端- 响应通过 Mono 链式返回
- 每个过滤器都可以修改响应
- 最终返回给客户端
关键点:
- 过滤器链是响应式的,不会阻塞线程
- 每个过滤器都可以修改请求或响应
- 过滤器可以决定是否继续执行下一个过滤器
NettyRoutingFilter是最后一个过滤器,负责实际转发请求
2.4 响应式 HTTP 请求
java
Flux<HttpClientResponse> responseFlux = httpClient
.headers(headers -> headers.add(httpHeaders))
.request(method)
.uri(url)
.send((req, nettyOutbound) -> nettyOutbound.send(request.getBody()))
.responseConnection((res, connection) -> {
// 处理响应
return Mono.just(res);
});
关键点:
- 使用 Reactor Netty 的非阻塞 HTTP 客户端
- 基于 Reactive Streams 的响应式编程模型
- 支持背压(Backpressure)控制
3. 实现关键点说明
3.1 响应式编程模型
WebFlux 模式完全基于响应式编程,使用 Project Reactor 的 Mono 和 Flux。这是 WebFlux 和 WebMVC 最根本的区别。
基本概念:
java
public interface GlobalFilter {
Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}
Mono 和 Flux 是什么?
-
Mono:表示 0 或 1 个元素的异步序列
javaMono<String> name = Mono.just("Spring"); // 一个值 Mono<String> empty = Mono.empty(); // 0 个值 Mono<String> async = Mono.fromCallable(() -> { // 异步操作 return fetchNameFromDatabase(); }); -
Flux:表示 0 到 N 个元素的异步序列
javaFlux<String> names = Flux.just("Spring", "Cloud", "Gateway"); // 多个值 Flux<String> stream = Flux.interval(Duration.ofSeconds(1)) .map(i -> "Event " + i); // 无限流
实际例子:
java
// WebMVC 方式(阻塞)
public ServerResponse handle(ServerRequest request) {
User user = userService.getUser(userId); // 阻塞等待
return ServerResponse.ok().body(user);
}
// WebFlux 方式(非阻塞)
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
return userService.getUser(userId) // 返回 Mono<User>,不阻塞
.flatMap(user -> {
// 用户数据到达后才执行这里
exchange.getAttributes().put("user", user);
return chain.filter(exchange);
});
}
优势说明:
-
非阻塞 I/O,提高并发性能
java// 非阻塞调用下游服务 return httpClient.get() .uri("http://backend-service/api/data") .retrieve() .bodyToMono(String.class) // 返回 Mono,不阻塞线程 .flatMap(data -> { // 数据到达后才执行这里 return processData(data); }); // 在等待响应的这段时间,线程可以处理其他请求- 线程不会阻塞,可以处理其他请求
- 一个线程可以处理多个请求
- 并发性能大幅提升
-
支持背压,防止内存溢出
java// 背压示例 Flux<String> dataStream = getDataStream(); // 数据流 dataStream .limitRate(100) // 限制速率,防止内存溢出 .subscribe(data -> { // 处理数据 processData(data); });- 如果生产者生产数据太快,消费者可以告诉生产者慢一点
- 防止内存溢出
- 这是 Reactive Streams 规范的核心特性
-
资源利用率高,少量线程处理大量请求
场景:处理 10000 并发请求 WebMVC: 需要 500 线程,内存 ~500MB WebFlux: 只需要 16 线程,内存 ~100MB 资源利用率提升 5 倍!
3.2 过滤器链模式
Gateway 使用责任链模式实现过滤器链。这是 Gateway 的核心设计模式之一。
责任链模式:
java
private static class DefaultGatewayFilterChain implements GatewayFilterChain {
private final int index; // 当前过滤器索引
private final List<GatewayFilter> filters;
@Override
public Mono<Void> filter(ServerWebExchange exchange) {
return Mono.defer(() -> {
if (this.index < filters.size()) {
GatewayFilter filter = filters.get(this.index);
// 创建下一个链节点
DefaultGatewayFilterChain chain =
new DefaultGatewayFilterChain(this, this.index + 1);
// 执行当前过滤器,传入下一个链节点
return filter.filter(exchange, chain);
}
return Mono.empty(); // 所有过滤器执行完毕
});
}
}
实际例子:
java
// 假设有这些过滤器
List<GatewayFilter> filters = [
RateLimitFilter, // index 0
AddRequestHeaderFilter, // index 1
NettyRoutingFilter // index 2
];
// 执行流程
chain0.filter(exchange) // index = 0
-> RateLimitFilter.filter(exchange, chain1) // index = 1
-> 检查限流
-> chain1.filter(exchange)
-> AddRequestHeaderFilter.filter(exchange, chain2) // index = 2
-> 添加请求头
-> chain2.filter(exchange)
-> NettyRoutingFilter.filter(exchange, chain3) // index = 3
-> 转发请求
-> chain3.filter(exchange)
-> index (3) >= filters.size(),返回 Mono.empty()
过滤器类型:
-
GlobalFilter - 全局过滤器
java@Component public class CustomGlobalFilter implements GlobalFilter, Ordered { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { // 这个过滤器会应用于所有路由 return chain.filter(exchange); } @Override public int getOrder() { return -1; // 高优先级 } }- 应用于所有路由
- 比如认证、日志、监控等
-
GatewayFilter - 路由过滤器
java// 通过配置定义的路由过滤器 spring: cloud: gateway: routes: - id: user-service filters: - AddRequestHeader=X-User-Id, 123 # 路由过滤器- 只应用于特定路由
- 通过配置文件或 API 定义
-
Ordered - 控制执行顺序
java// 通过 Order 接口控制执行顺序 public class RateLimitFilter implements GlobalFilter, Ordered { @Override public int getOrder() { return -100; // 数字越小,优先级越高 } } public class LoggingFilter implements GlobalFilter, Ordered { @Override public int getOrder() { return 1000; // 优先级较低 } } // 执行顺序:RateLimitFilter (-100) -> LoggingFilter (1000)
过滤器可以做什么?
-
修改请求
java@Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); ServerHttpRequest modifiedRequest = request.mutate() .header("X-Request-Id", UUID.randomUUID().toString()) .build(); return chain.filter(exchange.mutate().request(modifiedRequest).build()); } -
修改响应
java@Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { return chain.filter(exchange).then(Mono.fromRunnable(() -> { ServerHttpResponse response = exchange.getResponse(); response.getHeaders().add("X-Response-Time", String.valueOf(System.currentTimeMillis())); })); } -
中断执行
java@Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { if (isRateLimited(exchange)) { // 限流了,直接返回错误,不继续执行 exchange.getResponse().setStatusCode(HttpStatus.TOO_MANY_REQUESTS); return exchange.getResponse().setComplete(); } return chain.filter(exchange); // 继续执行 }
3.3 异步谓词(AsyncPredicate)
路由匹配使用异步谓词,支持异步条件判断:
java
public interface AsyncPredicate<T> {
Mono<Boolean> test(T t);
}
支持的谓词:
- Path Route Predicate
- Method Route Predicate
- Header Route Predicate
- Host Route Predicate
- Query Route Predicate
- RemoteAddr Route Predicate
- Weight Route Predicate
3.4 Netty 集成
使用 Reactor Netty 作为底层 HTTP 客户端,提供高性能的非阻塞 I/O:
java
public class NettyRoutingFilter implements GlobalFilter {
private final HttpClient httpClient;
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 使用 Reactor Netty HttpClient 发送请求
Flux<HttpClientResponse> responseFlux = httpClient
.request(method)
.uri(url)
.send(...)
.responseConnection(...);
}
}
特性:
- 基于 Netty 的事件驱动模型
- 支持 HTTP/1.1 和 HTTP/2
- 支持 WebSocket
- 连接池管理
3.5 路由缓存
支持路由过滤器缓存,提高性能:
java
private final ConcurrentHashMap<Route, List<GatewayFilter>> routeFilterMap = new ConcurrentHashMap();
protected List<GatewayFilter> getCombinedFilters(Route route) {
if (this.routeFilterCacheEnabled) {
return routeFilterMap.computeIfAbsent(route, this::getAllFilters);
}
return getAllFilters(route);
}
4. 总结说明
4.1 架构特点
- 响应式编程: 完全基于 Project Reactor 的响应式编程模型
- 非阻塞 I/O: 使用 Reactor Netty 实现非阻塞 HTTP 通信
- 高并发性能: 少量线程处理大量并发请求
- 背压支持: 支持 Reactive Streams 的背压机制
4.2 适用场景
- 高并发、高吞吐量的 API 网关场景
- 需要处理大量长连接(如 WebSocket)
- 微服务架构中的统一入口
- 需要流式处理(Streaming)的场景
4.3 关键优势
- 高性能: 非阻塞 I/O 提供更高的吞吐量
- 资源高效: 少量线程处理大量请求,资源利用率高
- 可扩展性: 响应式模型支持更好的水平扩展
- 功能丰富: 支持 HTTP/2、WebSocket、gRPC 等协议
4.4 局限性
- 学习曲线: 需要理解响应式编程模型
- 调试困难: 异步调用栈较难调试
- 阻塞风险: 如果在响应式链中执行阻塞操作,会降低性能
- 内存管理: 需要理解背压机制,避免内存问题
4.5 最佳实践
- 避免阻塞操作: 不要在响应式链中执行阻塞 I/O
- 合理使用背压: 理解背压机制,合理配置缓冲区
- 监控和指标: 使用 Spring Boot Actuator 监控 Gateway 性能
- 过滤器顺序: 合理设置过滤器顺序,避免不必要的处理