企业官网建设流程全解析

Spring Cloud Gateway 在微服务架构里几乎是标配了，但很多人用了一年半载，可能都没仔细想过一个问题：为什么它非得基于 WebFlux 构建，而不是大家更熟悉的 Spring MVC？网上聊这个的不少，但大多是“Gateway 需要异步非阻塞，所以用 WebFlux”这种一句话结论，看完还是知其然不知其所以然。

我自己在项目里从 Spring Cloud Gateway 的 2.x 一路用到 3.x，期间也踩过不少响应式编程的坑，慢慢才把这里面的门道摸清楚。这篇文章不打算给你复述官方文档，而是从底层原理、线程模型、选型权衡，再到实际踩坑这几个角度，把这个“独宠”背后的逻辑彻底讲明白。不管你是刚接触微服务网关，还是已经上线了 Gateway 想弄懂内部机制，这篇文章应该都能给你一些启发。

1. 从网关的职责说起，为什么异步非阻塞是刚需

网关这东西，说白了就是所有流量的入口。客户端请求先打到网关，网关再做路由转发，把请求分发到后端的用户服务、订单服务、商品服务等等。这里面有两层含义：第一，网关是所有请求的必经之路；第二，网关本身不能成为瓶颈。一旦网关出了问题或者性能跟不上，整个系统就瘫痪了，这就是所谓的“单点故障”风险。

1.1 同步阻塞模型的“线程噩梦”

在搞清楚 WebFlux 的优势之前，先看看传统的 Spring MVC 基于 Servlet 的同步阻塞模型是什么情况。Servlet 容器（比如 Tomcat）处理请求的模式是“一个请求占用一个线程”。线程处理请求的过程中，如果要去调用后端服务、查询数据库、访问 Redis，这个线程就一直卡在那里等待 IO 返回，期间干不了任何别的事情。

想象一下一个餐厅的场景：每个顾客进来，餐厅就安排一个服务员全程陪同，从点菜、等厨房做菜、到上菜，服务员都得站着等。如果顾客点了道硬菜，厨房要炖两个小时，服务员这两个小时就啥也不干，光是陪着等。餐厅能同时接待的顾客数量，直接取决于服务员的数量。这就是同步阻塞模型的本质：线程（服务员）是极其宝贵的资源，而 IO 等待（等菜）是对资源的巨大浪费。

在微服务架构里，网关转发一个请求可能要调用多个下游服务，这期间的网络往返时间是毫秒级甚至秒级的。如果每个请求都独占一个线程等待，那网关的线程池很快就会被耗尽。Tomcat 默认最大线程数通常是 200，意味着同时只能处理 200 个请求，第 201 个请求就得排队。一旦流量洪峰到来，线程池被打满，后续请求全部排队等待，响应时间急剧上升，甚至直接拒绝服务。这就是为什么传统同步网关在大并发场景下容易成为瓶颈。

1.2 WebFlux 带来的本质改变

WebFlux 是 Spring 5 引入的响应式编程框架，基于 Project Reactor 实现，底层使用 Netty 作为运行容器。它采用的是事件驱动 + 非阻塞 IO 模型，跟同步阻塞模型的思路完全不同。

还是用餐厅打比方：这回餐厅换了个管理模式，门口只有一个接待员（有限的几个线程），顾客来了先登记需求（注册回调），然后就可以去坐着休息了。厨房菜做好了，接待员再把菜端过去（回调触发）。接待员从头到尾没有被任何一个顾客“绑定”，他一直在循环接收新的顾客请求、响应完成的事件，一个人就能同时服务成千上万个顾客。

这个模式在技术上叫 Reactor 模式，Netty 就是这个模式的经典实现。核心特点是：

• IO 操作是非阻塞的，发起读写操作后立即返回，不会傻等数据准备好。
• 用有限的事件循环线程（Event Loop）处理海量连接，线程利用率极高。
• 通过背压机制（Backpressure）控制数据流速率，避免消费者被生产者压垮。

WebFlux 带来的直接结果就是：用极少的线程就能支撑极高的并发连接数。同样一台服务器，同步模型可能几百个并发就把线程池打满了，WebFlux 可以轻松扛住上万连接。

1.3 网关场景与响应式模型的高度契合

网关这个位置，本质上是流量的“摆渡人”。它不承载具体的业务逻辑，主要工作就是接收请求、根据规则找到目标服务、转发请求、接收响应、返回给客户端。这个过程中绝大部分时间都花在网络 IO 上，也就是等待下游服务响应。这种 IO 密集型的场景，恰好是异步非阻塞模型最擅长的地方。

如果网关用同步模型，每个请求空占一个线程等待下游响应，线程利用率极低。而用 WebFlux，一个线程可以同时管理成千上万个等待中的请求，等到哪个响应回来了就处理哪个，线程始终在干活。所以从网关的职责定位来看，选择 WebFlux 是一种必然，而不是偶然。

2. WebFlux 核心原理解读，Gateway 的地基

要理解 Spring Cloud Gateway 为什么用 WebFlux，必须先弄懂 WebFlux 的核心原理。我尽量把这块讲得透一点，因为这直接关系到后续排查问题、调优性能的能力。

2.1 响应式编程与 Reactor 的核心概念

WebFlux 的底层是 Project Reactor，它提供两个核心的响应式类型：Mono 和 Flux。Mono 表示 0 到 1 个元素的异步序列，Flux 表示 0 到 N 个元素的异步序列。在 Gateway 里，你到处能看到 Mono 的身影，比如路由断言的结果是 Mono，过滤器链的调用也是 Mono。

响应式编程的本质可以概括为一句话：数据流 + 声明式操作 + 订阅触发。在传统编程里，你主动去调用一个方法，然后等待结果返回，这是“拉”模式。在响应式编程里，你定义一条数据处理的链路，但是数据不会流动，直到你调用 subscribe 方法去“订阅”它，这是“推”模式。

用一个生活化的类比来解释：传统编程像你去餐厅点菜，你喊服务员（调用方法），然后等着厨房做好端上来（阻塞等待）。响应式编程像你在外卖 App 上下单（构建数据流），你该干嘛干嘛去（非阻塞），外卖小哥送到的时候打电话通知你（回调触发），你拿到外卖（响应结果）。

这套机制里最关键的是回调。Netty 会为每个 IO 事件注册回调，数据到了之后自动触发相应的处理逻辑。而 Reactor 在这之上做了一层抽象，让你可以用操作符（Operator）来声明式地处理数据，比如 map、filter、flatMap 等。

2.2 事件循环（Event Loop）线程模型解析

WebFlux 的线程模型跟传统的线程池模型有本质区别。Netty 的 EventLoopGroup 是核心，它在启动时就创建固定数量的线程（通常是 CPU 核数的两倍），这些线程在整个生命周期内不断循环，处理 IO 事件。

EventLoop 的生命周期是这样的：线程在一个死循环里，调用 selector 的 select 方法阻塞等待 IO 事件的到来。一旦有事件发生（比如有数据可读了），selector 就会返回发生事件的 Channel 集合，然后线程逐个处理这些 Channel 上的事件，触发相应的回调方法。

在 WebFlux 默认的线程模型里，主要有两组 EventLoop 线程：

这里有个很重要的知识点：EventLoop 线程是非常“珍贵”的。因为每个线程都在死循环里处理各个 Channel 的事件，一旦某个事件回调里不小心用了同步阻塞操作（比如调了 Thread.sleep、或者阻塞式的 JDBC 调用），整个线程就会被卡住，这个线程负责的所有 Channel 的 IO 事件都会延迟处理。这就是为什么在 WebFlux 里绝对不能有阻塞操作的根本原因——不是“最好别用”，而是“用了就会出问题”。

2.3 背压（Backpressure）机制是怎么一回事

背压是响应式编程里非常重要的一个概念，也是 WebFlux 区别于传统异步回调方案的关键优势。简单说，背压就是下游消费者告诉上游生产者：“我现在只能处理这么多数据，你先别一次性全推给我。”

举个例子，假设网关从某个上游拉取大量数据，然后处理完转发给下游。如果下游处理速度比较慢，而上游疯狂推送数据，就可能导致下游缓冲区溢出、内存暴涨。有了背压机制，下游可以通过 request(n) 的方式向上游声明自己当前能处理的数量，上游就会按这个数量来控制推送节奏。

在 Gateway 的实践中，背压机制的应用是透明的，框架已经帮你处理好了。但理解这个概念很重要，因为当你自定义一些 WebFlux 相关的逻辑时，如果不注意背压，就可能导致内存中的对象堆积。

3. Gateway 与 WebFlux 的二三事，从路由到过滤器的响应式实现

前面讲了 WebFlux 的原理，这部分来具体看看 Gateway 是怎么基于 WebFlux 实现路由和过滤器的。理解了这部分，你就能明白为什么很多在 Spring MVC 里很自然的写法，到了 Gateway 里就行不通。

3.1 路由断言与过滤器链的响应式设计

Gateway 的核心处理流程可以简化为：接收请求 → 找匹配的路由 → 执行过滤器链 → 转发请求 → 返回响应。这里面的每一步都是响应式风格的。

路由断言（Predicate）的作用是判断一个请求是否匹配某个路由。比如你可能配置了Path=/api/order/**的断言，当请求路径以/api/order/开头时，就命中这个路由。Predicate 本身是个函数式接口，在 WebFlux 里它是异步的，返回的是Mono<Boolean>，意味着断言逻辑也可以做异步操作。

过滤器链（Filter Chain）是 Gateway 的核心组件。一个请求经过网关时，会依次经过 GlobalFilter 和 GatewayFilter。Filter 的内部实现是典型的响应式调用链：每个过滤器执行完自己的逻辑后，调用chain.filter(exchange)把请求传给下一个过滤器，最终到达 Netty 的转发器。

这里有一个重要的执行模型：过滤器链的执行不是从上到下依次执行完就结束了，它是一个嵌套调用。请求打着转进入过滤器链，到达最底层后，响应打着转从最底层逐个过滤器穿出来。这就好比剥洋葱，请求从外往里剥，响应从里往外穿。

我用一个实际的代码片段来说明自定义过滤器的写法。比如我想在请求头里加一个时间戳，传统 MVC 里的写法可能是在拦截器里直接改 request：

// Spring MVC 的写法（同步阻塞） public class TimestampInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { request.setAttribute("startTime", System.currentTimeMillis()); return true; } }

到了 Gateway 的响应式世界里，写法完全不一样：

// Spring Cloud Gateway 的响应式写法 @Component public class TimestampGatewayFilter implements GlobalFilter, Ordered { @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { long start = System.currentTimeMillis(); // 请求前逻辑在这里执行 return chain.filter(exchange).then(Mono.fromRunnable(() -> { // 响应后逻辑在这里执行 long cost = System.currentTimeMillis() - start; exchange.getResponse().getHeaders().add("X-Cost-Time", String.valueOf(cost)); })); } @Override public int getOrder() { return -100; // 值越小优先级越高 } }

注意看这段代码的写法：chain.filter(exchange)返回一个Mono<Void>，这个 Mono 表示整个过滤器链后续处理的结果。如果你需要在响应返回后做一些操作，就用.then()或者.doFinally()来追加逻辑。这是典型的响应式编程风格——把依赖关系通过操作符进行声明式组合，而不是靠调用栈的嵌套。

3.2 TcpClient、Reactor Netty 与连接池管理

Gateway 的转发动作最终是通过 Reactor Netty 发出去的。Spring Cloud Gateway 会为每个下游服务维护一个 HttpClient 实例，这些实例由 Reactor Netty 管理连接池。

这里面有个很有用的配置项是连接池的大小和等待策略。默认情况下，Gateway 的 HttpClient 连接池最大值是 500，等待队列长度不设限。如果你在压测中发现某些下游服务的响应比较慢，而 Gateway 侧的线程状态异常，可以重点关注连接池相关的指标。

这里给出一个常用的连接池调优配置示例：

spring: cloud: gateway: httpclient: connect-timeout: 5000 response-timeout: 5s pool: type: elastic max-connections: 1000 max-idle-time: 30s

注意type: elastic表示弹性伸缩的连接池，还有一种fixed类型，表示固定大小的连接池。如果你选择fixed类型，可以配置max-connections和acquire-timeout，其中acquire-timeout是当连接池耗尽时，等待获取连接的超时时间。

这些都是响应式编程模型的直接体现：连接池本身也是异步的，获取连接的请求被放进队列里，一旦有连接释放就分配给它，而不是像同步模型那样抛异常或者阻塞线程。

3.3 WebFlux 下 Gateway 的并发模型分析

很多人在做并发测试时，直观感受是 Gateway 的线程栈看起来很奇怪：没有像 Tomcat 那样明显的请求处理线程池。这是因为 Netty 的 EventLoop 线程既负责接收 IO 事件，又负责执行业务回调逻辑。

看一份典型的 Netty 线程信息：

reactor-http-nio-1 reactor-http-nio-2 reactor-http-nio-3 ... reactor-http-nio-8

这就是 EventLoop 线程，数量通常是 CPU 核数的两倍。所有的连接都被分布到这些线程上。一个连接的所有操作（读取请求、执行过滤器链、转发请求、处理响应）都会在这同一个线程上执行，这是 Netty 的一个关键设计原则——避免并发竞争。

这个设计的好处是：同一个连接的请求不会出现并发问题，你不需要加锁。但这个规则也意味着，如果你在过滤器链中做了阻塞操作，那这个线程上处理的所有连接都会受到影响。这就是前面强调“不要在 Gateway 里做阻塞操作”的原因，不只是性能问题，可能会造成全局性的线程卡顿。

这里分享一个调优经验：如果你发现 Gateway 的 CPU 利用率不高、但响应延迟却很高，大概率是在过滤器链里出现了阻塞调用。排查方法很简单，用jstack抓线程堆栈，看reactor-http-nio-*线程是不是有很多处于WAITING或BLOCKED状态。

4. 为什么非 WebFlux 不可，关于技术选型的深层逻辑

前面讲了很多原理，这部分聊点选型层面的考量。毕竟技术切到响应式编程的代价不小，学习曲线陡峭、调试困难、生态也有限。为什么 Spring Cloud Gateway 宁可顶着这些不便，也要坚持用 WebFlux？

4.1 性能上限差异带来的必然选择

网关这个位置，性能的每一个百分点都至关重要。同步模型在低并发时的表现还可以，但一旦并发高了，线程切换和内存开销会急剧上升。异步模型恰恰相反，它在高并发时表现非常稳定。

这不是嘴上说说。我做过的对比测试里，同样一台 4C8G 的服务器，基于 Netty 的网关在一万并发连接下 CPU 利用率还能控制在 60% 左右，而基于 Tomcat 的同步方案在并发达到两三千时 CPU 就已经爆了，而且线程上下文切换极其频繁，大部分 CPU 时间浪费在切换上而不是实际处理请求。

从本质上说，同步模型是“用线程换并发”，每增加一个并发就要增加一个线程。而线程是有成本的，一个线程默认栈大小是 1MB，1000 个线程就要近 1GB 的虚拟内存。即使不考虑内存，线程调度也是有开销的。异步模型是“用事件循环换并发”，线程数量固定，靠事件驱动来处理海量请求，内存开销和调度开销都极小。

对于微服务网关这种流量入口，性能天花板必须足够高。这个需求决定了它八成会走向异步非阻塞路线，而 Spring 家族里支持异步非阻塞的、又能跟其他 Spring 组件无缝集成的，只有 WebFlux。

4.2 端到端响应式链路的完整闭环

如果你只用 Gateway 这一个组件，感受不到 WebFlux 的全部价值。但当你把目光放大到整个微服务体系，你会发现数据链路可能是这样的：客户端发起请求 → 网关 → 下游服务（如果这个服务也用 WebFlux）→ 数据库驱动（如果是 R2DBC）→ 甚至消息队列（Reactive RabbitMQ/Kafka）。整条链路都是非阻塞的，没有任何一段会卡住线程。

这种端到端的响应式链路价值在于：系统的整体吞吐量不再受限于最慢的那个环节的线程数。任何一个环节的 IO 等待都不会独占线程，整个系统的资源利用效率会高很多。

如果 Gateway 用 Spring MVC，而下游服务用 WebFlux，那网关本身就成了整个链路的瓶颈，因为它把异步的请求同步化了——下游返回之前，网关的线程必须等着。那响应式下游服务的优势就被网关抵消掉了，这是架构上的裂缝。

所以 Spring 官方让 Gateway 基于 WebFlux，本质上是为了确保整个微服务体系可以构建完整的响应式闭环。如果你愿意，可以从最上游的网关到最底层的数据库访问全部走响应式，整个系统不会有一处阻塞的短板。

4.3 为什么不能直接复用 Spring MVC 添加异步支持

有人可能会想：既然 Spring MVC 从 3.2 开始也支持 Servlet 3.0 的异步请求处理了，那为什么不直接在 Spring MVC 基础上做异步网关，省得折腾新的编程模型？

这个问题问得挺好的，实际原因比较复杂。Servlet 3.0 的异步支持是在 Servlet 容器框架内打补丁，关键的操作（比如读取请求体、写响应）还是受限于 Servlet API 的设计。Servlet API 是基于阻塞 IO 设计的，异步支持只是让你把费时的业务逻辑放到别的线程池去执行，底层的 IO 读写依然是阻塞的。

对于网关这种要频繁代理转发、频繁做 IO 读写的组件来说，如果每次转发都要通过阻塞式的 ServletInputStream/ServletOutputStream 读写数据，那异步就失去了意义。真正要做高性能网关，必须从 IO 层面就全部非阻塞，这就需要 Netty 这样的框架。

而且，从代码的编程模型来说，Spring MVC 加异步支持只是给你提供了异步的能力，但你还是用同步的方式思考问题——接收请求、处理、返回。WebFlux 则是从根上改变了编程范式，整个处理链路都是响应式、声明式的。对于网关这种需要高度流式处理的场景，WebFlux 的表达能力和灵活性远远超过 Spring MVC 的“异步补丁”。

4.4 响应式网关的劣势与适用边界，这些坑你要知道

技术选型不是选一个“最好的”，而是选一个“最适合的”。WebFlux 优势明显，但代价也同样明显，这里得坦诚地讲一讲。

第一个坑是编程范式的转变。习惯了编写同步代码的人，刚接触响应式编程时非常容易写错。比如在 filter 里调了一个返回Mono<String>的方法，但没调用 subscribe；或者以为map里的逻辑会立即执行，实际上是订阅后才会执行；再比如用block()方法强行把一个 Mono 变成同步等待的，直接把整个响应式链路卡死。这些都是新手最容易踩的坑。

第二个坑是调试和排障比较困难。响应式编程的调用栈和传统编程完全不同。传统代码的调用栈是一层层的顺序方法调用，出错时通过堆栈能很清楚地看到调用链。响应式代码的调用是在订阅时触发的异步调用链，出错时的堆栈是各个操作符内部的处理过程，跟你的业务逻辑关联不直观。很多时候一个 NPE 的堆栈看着完全不知道是在哪一步触发的。

第三个坑是生态适配性。WebFlux 虽然已经发展了很多年，但生态仍然不如 Servlet 生态丰富。比如 Spring Data JPA 目前主流还是同步阻塞的，WebFlux 要访问数据库一般得用 R2DBC，而这个选择在很多业务场景里还不一定合适。如果你要对接一些老旧的中间件，比如某个只支持同步客户端的消息队列，那在 WebFlux 里调用它就会阻塞线程，效果反而更差。

所以我的建议是：如果你们的微服务体系已经是 Cloud Gateway + 下游 Spring MVC 的传统结构，那网关用 WebFlux 没问题，但下游服务继续用 Spring MVC 也完全合理。毕竟网关自身的异步收益就已经很大了，没必要强制要求整个链路全响应式。但你要清楚，这个场景下网关的异步优势在下游同步服务面前会被削弱一部分——下游同步服务处理请求时依然占用线程等待 IO，不过网关自身的并发瓶颈消除了，整个系统的入口容量提升了，收益还是很明显的。

5. 集群部署的可行性解读，高并发网关的落地实践

关于 Spring Cloud Gateway 能不能做集群，网上讨论还蛮多的。直接给结论：完全支持，而且 Spring Cloud 生态天然就是为集群设计的。这个问题会存在，可能是因为某些资料把 Gateway 描述成了“无状态”组件，让人怀疑它是否适合集群。其实无状态恰好是集群部署的最佳前提。

5.1 无状态设计和集群扩展的基本原理

Spring Cloud Gateway 本身不存储任何会话状态，它只是一个智能的路由转发器。所有请求进来，它根据路由配置和断言条件转发到对应服务，不记录“用户张三之前来过、上次路由到了哪个服务”这类信息。这个特点使得 Gateway 可以随意横向扩展——只要后端服务是一样的，流量打到任何一个 Gateway 实例，转发逻辑完全一致。

集群部署的架构非常简单粗暴：部署多个 Gateway 实例，前端用负载均衡器（比如 Nginx）把流量分发到各个实例上。Nginx 做四层或七层负载均衡，配置上游服务器组，轮询或按权重分发。所有 Gateway 实例共用同一份配置（从配置中心拉取），对下游服务的路由是一致的，自然形成集群。

有个需要注意的点是：Gateway 的集群扩展不像某些业务组件那样有复杂的分布式协调需求。它不需要同步会话数据、不需要共享缓存，唯一的“状态”可能就是内部的路由表和过滤器配置，而这些都是启动时从注册中心或配置中心拉取的，每个实例自己维护一份即可。

5.2 集群健康检查与动态上下线

生产环境的集群部署一定要配合健康检查机制。Nginx 对 Gateway 实例的健康检查分为主动和被动两种。主动健康检查是 Nginx 定时向 Gateway 的某个接口发起探测请求，确认实例是否存活。被动健康检查是 Nginx 监控后端返回的错误码，如果连续多次 5xx 就把这个实例摘除。

Gateway 本身也可以配合 Spring Boot Actuator 暴露健康检查端点：

management: endpoints: web: exposure: include: health,info,gateway

配合注册中心使用时，Gateway 注册到 Nacos 或 Eureka，负载均衡器可以从注册中心发现所有 Gateway 实例。当某个实例启动完成，它会自动注册到注册中心，负载均衡器感知到新节点后把流量打过去。实例下线时同理，优雅退出后从注册中心摘除，负载均衡器就不会再把流量分给它。这套机制让集群的扩缩容变得非常丝滑。

5.3 集群部署场景下的限流与全局配置

集群部署后，一个老生常谈的问题就出现了——限流怎么做。如果直接在 Gateway 单机出发限流规则，那集群模式下每台机器各自限流，总体的请求量可能是限流阈值的 N 倍（N 为实例数）。要解决这个问题，通常用 Redis 做分布式限流。

Gateway 内置的RequestRateLimiter过滤器就是基于 Redis + Lua 脚本实现的分布式限流。它会以某个 Key（比如用户 ID 或 IP）为维度，在 Redis 里维护一个滑动窗口计数器，每次请求进来都会执行一段 Lua 脚本，原子性地判断当前窗口内请求数是否超过阈值。这种方案天然支持集群——因为计数器在 Redis 里，所有 Gateway 实例共享同一个计数器，整体限流效果是一致的。

另外一个集群部署要注意的点是路由规则的统一。建议把路由规则全部收敛到配置中心（Nacos Config 或 Spring Cloud Config），不要在每台实例的本地配置文件里各写一套。否则改一条路由要登录几十台机器，连改都懒得改，直接埋雷。

5.4 集群防护策略与高可用建议

网关集群是系统入口的最后一道防线，对于异常流量的防护要提前设计好。

刚提到限流，但是限流只是第一层防护。熔断、降级和隔离也要按层构建。Gateway 是可以集成 Sentinel 的，用 Sentinel 的网关适配器来配置资源维度的流控规则。比如某个接口超时严重，你可以配置熔断策略，让它在阈值范围内快速失败，而不是把请求都打到下游把下游拖垮。

在集群模式下，我更建议把防护策略划分层次：Nginx 层做粗暴的 IP 黑白名单和简单的 QPS 限流，Gateway 层做精细化的路由限流、熔断降级，下游服务自己再做一层保护。三层防护配合，集群的稳定性才有保障。只靠一层的单点防护，在突发流量下很容易被打穿。

6. 常见问题与排障思路，实际踩坑的经验总结

用 Gateway 这几年，期间遇到不少响应式编程相关的坑，这里挑几个典型的，给大家做个参考。这些问题很多是知其然不知其所以然，遇到了很容易卡住。

6.1 过滤器内调用阻塞方法导致线程卡死

这是最常见的问题，也最隐蔽。我在一个早期项目里，有人在 GlobalFilter 里调用了Thread.sleep(100)做限速控制，结果压测时发现一旦有流量进来，整个网关的响应都变得极慢。抓线程栈发现reactor-http-nio-*线程大量停在Thread.sleep上。

原因就是前面说的：EventLoop 线程既要处理 IO 事件，又要执行业务逻辑。Thread.sleep一睡，整条线程就瘫痪了，凡是这个线程负责的连接全部受影响。而且因为 EventLoop 线程数量有限，通常就 8 个左右，一个线程卡住就影响八分之一的连接。

解决方案也简单：把阻塞操作从响应式调用链里移除。如果确实需要做耗时操作，可以把它切换到专门的线程池去执行，避免占用 EventLoop 线程。参考写法：

Mono.fromCallable(() -> { // 这段代码放线程池执行 Thread.sleep(100); return "done"; }).subscribeOn(Schedulers.boundedElastic()) // 切到专属线程池 .subscribe();

6.2 热重启时连接池耗尽的问题

这个问题是在一次灰度发布时遇到的。当时我们对一批 Gateway 实例做了滚动更新，旧实例还在服务流量，新实例已经启动开始接收流量。结果新实例上线后，大量请求报连接超时，老实例却一切正常。

排查后发现是新实例的连接池太小，默认最大 500 个连接。因为新实例上线时瞬间接收了大量请求，连接池被打满，后续请求都在排队等待获取连接，等待超过response-timeout就报错了。

解决方法是增大连接池最大连接数，并且给连接池的增加做一个过渡期，不要一次性把所有流量切到新实例。可以把 Nginx 的权重调低一些，等新实例运行稳定了再逐步提高权重。

6.3 路由断言生效顺序的问题

Gateway 支持多个路由，但路由匹配的顺序是按优先级从高到低排列的。默认情况下，路由是按配置声明的顺序匹配的，一旦某个路由的断言通过，就立即使用该路由，不再继续匹配后面的路由。

这里有个容易踩的坑：如果你把/api/order/**这种具体的路径写在/api/**之前，那没问题；但如果你把/api/**放在前面，那所有/api/*开头的请求都会先匹配到这个泛化路由，后面的/api/order/**路由永远不会生效。

解决方案有两个：一是把具体路径的路由放在前面，二是给路由配置order属性，数值越小优先级越高。

6.4 WebFlux 中执行 RPC 调用的正确姿势

在 Gateway 的过滤器中，免不了要调用下游的 RPC 服务，比如做权限校验时调用用户服务。这里有两个选择：

一是用 WebClient（WebFlux 的响应式 HTTP 客户端）发起异步调用。WebClient 本身支持响应式，调用返回 Mono/Flux，可以直接跟过滤器链自然集成，不会阻塞 EventLoop 线程。

二是用传统同步的 RPC 客户端，比如 Feign、Dubbo。这些框架的客户端大多是同步阻塞的，在 WebFlux 过滤器里直接使用会阻塞线程，影响网关性能。

我在实际项目中建议的使用方式是：如果这个 RPC 调用是校验类、且必须在转发前完成，可以把它放到Schedulers.boundedElastic()线程池，或者提前把这个 RPC 调用的结果缓存起来，避免每次进过滤器都同步调用。

6.5 常见问题速查表

7. 写在最后的实践心得

说实话，Spring Cloud Gateway 选择 WebFlux 这件事，一开始对很多习惯了 Spring MVC 的人来说是不太友好的。响应式编程的学习曲线确实陡峭，刚接触时各种不习惯。但用了几年之后回头看，这个选择对网关这个场景来说确实是合理的。网关的本质决定了它必须轻快、高性能、能扛高并发，而 WebFlux 恰好提供了这一切。

我的建议是：如果你要深入学习 Gateway，与其死记硬背 API，不如先把 Netty 的事件循环模型和 Reactor 的核心概念搞懂。这两个是 WebFlux 的地基，地基稳了，上面的建筑怎么搭都很扎实。

另外，团队在使用 Gateway 前一定要统一约定几条铁律：过滤器内禁止阻塞操作、禁止直接使用同步 RPC 客户端、路由配置统一走配置中心、每个过滤器必须有明确的责任边界。这些约定看着简单，但能在关键时刻避免线上事故。在我的项目里，因为过滤器阻塞导致网关假死的情况出现过一次，后来把这些约定落实到代码审查规范和 Checkstyle 规则里，再没出过类似问题。

响应式编程这条路，走进去之后你会发现它的思维方式和传统编程很不一样，但一旦适应了，写出来的代码在性能和资源占用上确实有质的变化。把这篇文章里讲的内容吃透了，你对 Spring Cloud Gateway 的掌控力会上一个档次。