Spring Cloud Gateway WebFlux 模式架构分析
Spring Cloud Gateway WebFlux 模式架构分析请关注微信公众号：阿呆-bot
1. 入口类及关键类关系
1.1 入口类
Spring Cloud Gateway WebFlux 模式的入口类是 GatewayAutoConfiguration，这是整个 WebFlux 模式的"总指挥"。它负责配置所有 Gateway 需要的组件。
@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 模式就无法工作
[*]@ConditionalOnProperty
# 可以通过配置控制是否启用
spring:
cloud:
gateway:
server:
webflux:
enabled: true# 默认启用，可以设置为 false 禁用
配置的核心组件：
[*]RouteLocator：路由定位器，负责提供路由列表
[*]FilteringWebHandler：过滤器处理器，负责执行过滤器链
[*]RoutePredicateHandlerMapping：路由匹配器，负责匹配请求到路由
[*]GatewayProperties：Gateway 配置属性
1.2 关键类关系图
1.3 核心组件说明
RoutePredicateHandlerMapping
这是 Gateway 的路由匹配器，负责找到匹配的路由。它继承自 Spring WebFlux 的 AbstractHandlerMapping。
工作原理：
@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;
});
}实际例子：
// 假设有这些路由配置
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，是异步的
[*]路由匹配使用 AsyncPredicate，支持异步条件判断
[*]匹配成功后，路由信息存储在 ServerWebExchange 的属性中
FilteringWebHandler
这是 Gateway 的核心请求处理器，负责执行过滤器链。它实现了 Spring WebFlux 的 WebHandler 接口。
工作原理：
@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);
}实际例子：
// 假设路由配置了这些过滤器
route.filters = [
AddRequestHeaderFilter,
RateLimitFilter,
NettyRoutingFilter// 最后一个，负责实际转发请求
]
// FilteringWebHandler 会：
// 1. 合并全局过滤器和路由过滤器
// 2. 按 Order 排序
// 3. 创建过滤器链
// 4. 依次执行过滤器过滤器链执行：
// 过滤器链的实现（责任链模式）
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，可以组合使用。
工作原理：
@Bean
@Primary
public RouteLocator cachedCompositeRouteLocator(List<RouteLocator> routeLocators) {
// 1. 组合多个 RouteLocator
CompositeRouteLocator composite = new CompositeRouteLocator(
Flux.fromIterable(routeLocators)
);
// 2. 添加缓存（提高性能）
return new CachingRouteLocator(composite);
}实际例子：
// 可以有多个 RouteLocator
RouteLocator[] locators = [
PropertiesRouteDefinitionLocator, // 从配置文件读取路由
DiscoveryClientRouteDefinitionLocator, // 从服务发现读取路由
InMemoryRouteDefinitionRepository // 从内存（API）读取路由
]
// CompositeRouteLocator 会合并所有路由
// 返回 Flux<Route>，包含所有路由路由来源：
[*]配置文件：PropertiesRouteDefinitionLocator
spring:
cloud:
gateway:
routes:
- id: user-service
uri: http://localhost:8081
[*]服务发现：DiscoveryClientRouteDefinitionLocator
// 自动从 Eureka/Consul 等服务注册中心发现服务
// 为每个服务自动创建路由
[*]API 动态配置：InMemoryRouteDefinitionRepository
// 通过 API 动态添加/删除路由
routeDefinitionRepository.save(routeDefinition);
2. 关键流程描述
2.1 请求处理流程时序图
2.2 路由匹配流程
路由匹配是 Gateway 的核心功能。让我们用一个实际例子来说明整个流程：
场景：客户端请求 GET /api/users/123
详细流程：
[*]DispatcherHandler 接收 HTTP 请求
客户端 → DispatcherHandler → Gateway
[*]DispatcherHandler 是 WebFlux 的请求分发器，类似于 WebMVC 的 DispatcherServlet
[*]它会把请求交给合适的 HandlerMapping 处理
[*]Gateway 的 RoutePredicateHandlerMapping 优先级很高，会优先处理
[*]RoutePredicateHandlerMapping 从 RouteLocator 获取所有路由
// 获取所有路由（返回 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，是响应式的流
[*]使用 AsyncPredicate 异步匹配路由
// 异步匹配路由
return routes
.filterWhen(route -> {
// 使用 AsyncPredicate 异步匹配
return route.getPredicate().test(exchange);
})
.next();// 返回第一个匹配的路由匹配过程：
// 路由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，不会阻塞线程
[*]找到匹配的路由后，将路由信息存储到 ServerWebExchange 的属性中
// 匹配成功后
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 作为处理器
// 返回 FilteringWebHandler
return Mono.just(webHandler);
[*]FilteringWebHandler 会负责执行过滤器链
[*]最终会调用 NettyRoutingFilter 转发请求到下游服务
完整示例：
# 配置文件
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 从路由中获取过滤器列表
Route route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR);
List<GatewayFilter> routeFilters = route.getFilters();
// 假设路由配置了这些过滤器：
//
[*]从路由中获取路由级别的过滤器
[*]这些过滤器只应用于当前路由
[*]合并全局过滤器和路由过滤器，按 Order 排序
// 全局过滤器（应用于所有路由）
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，实现责任链模式
// 创建过滤器链
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();// 所有过滤器执行完毕
});
}
}
[*]使用责任链模式，每个过滤器都可以决定是否继续执行下一个过滤器
[*]通过递归创建链节点来实现
[*]递归执行过滤器
// 执行流程（简化版）
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 请求
// 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 链式返回
// 响应返回流程
NettyWriteResponseFilter.filter(exchange, chain)
-> 写入响应到客户端
-> Mono.empty()// 完成
-> 返回给 NettyRoutingFilter
-> 返回给 LoadBalancerClientFilter
-> 返回给 AddRequestHeaderFilter
-> 返回给 RateLimitFilter
-> 返回给 FilteringWebHandler
-> 返回给 RoutePredicateHandlerMapping
-> 返回给 DispatcherHandler
-> 返回给客户端
[*]响应通过 Mono 链式返回
[*]每个过滤器都可以修改响应
[*]最终返回给客户端
关键点：
[*]过滤器链是响应式的，不会阻塞线程
[*]每个过滤器都可以修改请求或响应
[*]过滤器可以决定是否继续执行下一个过滤器
[*]NettyRoutingFilter 是最后一个过滤器，负责实际转发请求
2.4 响应式 HTTP 请求
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 最根本的区别。
基本概念：
public interface GlobalFilter {
Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}Mono 和 Flux 是什么？
[*]Mono：表示 0 或 1 个元素的异步序列
Mono<String> name = Mono.just("Spring");// 一个值
Mono<String> empty = Mono.empty(); // 0 个值
Mono<String> async = Mono.fromCallable(() -> {
// 异步操作
return fetchNameFromDatabase();
});
[*]Flux：表示 0 到 N 个元素的异步序列
Flux<String> names = Flux.just("Spring", "Cloud", "Gateway");// 多个值
Flux<String> stream = Flux.interval(Duration.ofSeconds(1))
.map(i -> "Event " + i);// 无限流
实际例子：
// 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，提高并发性能
// 非阻塞调用下游服务
return httpClient.get()
.uri("http://backend-service/api/data")
.retrieve()
.bodyToMono(String.class)// 返回 Mono，不阻塞线程
.flatMap(data -> {
// 数据到达后才执行这里
return processData(data);
});
// 在等待响应的这段时间，线程可以处理其他请求
[*]线程不会阻塞，可以处理其他请求
[*]一个线程可以处理多个请求
[*]并发性能大幅提升
[*]支持背压，防止内存溢出
// 背压示例
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 的核心设计模式之一。
责任链模式：
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();// 所有过滤器执行完毕
});
}
}实际例子：
// 假设有这些过滤器
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 - 全局过滤器
@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 - 路由过滤器
// 通过配置定义的路由过滤器
spring:
cloud:
gateway:
routes:
- id: user-service
filters:
- AddRequestHeader=X-User-Id, 123# 路由过滤器
[*]只应用于特定路由
[*]通过配置文件或 API 定义
[*]Ordered - 控制执行顺序
// 通过 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)
过滤器可以做什么？
[*]修改请求
@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());
}
[*]修改响应
@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()));
}));
}
[*]中断执行
@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）
路由匹配使用异步谓词，支持异步条件判断：
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：
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 路由缓存
支持路由过滤器缓存，提高性能：
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 性能
[*]过滤器顺序: 合理设置过滤器顺序，避免不必要的处理
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 不错，里面软件多更新就更好了
页:
[1]