Spring Cloud Gateway 和 Zuul 有什么区别？
简化版
核心区别在底层线程模型：Zuul 1.x 基于 Servlet + 阻塞 IO，是同步阻塞的——每个请求占用一个线程，高并发时线程数暴涨、性能受限。Spring Cloud Gateway 基于 Spring WebFlux + Netty + Reactor，是**异步非阻塞（响应式）**的——少量线程用事件驱动处理海量请求，高并发下性能和资源利用率更好。此外 Gateway 是 Spring 官方主推的网关（Zuul 1.x 已进入维护、Netflix 停止主要更新），与 Spring 生态集成更好、功能（断言、过滤器）更强。所以新项目一般用 Spring Cloud Gateway。
详细版
对比：
| 维度 | Zuul 1.x | Spring Cloud Gateway |
|---|---|---|
| 底层 | Servlet + 阻塞 IO | WebFlux + Netty + Reactor |
| 线程模型 | 同步阻塞（一请求一线程） | 异步非阻塞（响应式，少线程） |
| 高并发性能 | 受线程数限制 | 更高，资源利用率好 |
| 长连接/WebSocket | 支持弱 | 原生支持 |
| 官方态度 | Netflix 停更、进入维护 | Spring 官方主推 |
| 功能 | 基础（Filter） | 丰富（Predicate + Filter，更强） |
| 编程模型 | 简单（命令式） | 响应式（学习成本高） |
注意：Zuul 2.x 也改成了 Netty 异步非阻塞，但 Spring Cloud 官方选择了自研的 Gateway 而非集成 Zuul 2.x，所以 Spring 生态里主流是 Gateway。
完整版教学
一、两者都是 API 网关
Zuul 和 Spring Cloud Gateway 都是微服务里的 API 网关，功能定位相同（路由、过滤、鉴权、限流等）。它们的关键差异不在「能做什么」，而在**「底层怎么实现的」——尤其是线程模型**，这直接决定了性能表现，也是面试的核心考点。
二、Zuul 1.x：同步阻塞（Servlet + BIO）
Zuul 1.x（Netflix 出品，Spring Cloud 早期集成）基于 Servlet 和阻塞 IO（BIO），是同步阻塞模型：
- 一个请求占用一个线程，从接收请求到转发给后端、等待后端响应、再返回，整个过程这个线程都被占着。
- 如果后端服务响应慢，这个线程就一直阻塞等待，什么也干不了。
- 高并发时，大量请求 = 大量线程被占用/阻塞，线程数暴涨，线程上下文切换开销大、内存占用高，性能受线程池大小限制。
这就是同步阻塞模型在高并发、尤其有慢后端时的瓶颈——和传统「一连接一线程」的 Web 服务器同样的问题。
三、Spring Cloud Gateway：异步非阻塞（WebFlux + Netty）
Spring Cloud Gateway 基于 Spring WebFlux + Netty + Reactor，是**异步非阻塞（响应式）**模型：
- 底层用 Netty（事件驱动、I/O 多路复用），少量线程（通常等于 CPU 核数）就能处理海量并发请求。
- 请求转发到后端后，不阻塞等待——线程可以去处理其他请求，等后端响应就绪时再通过回调/事件继续处理。
- 基于 Reactor 响应式编程（Mono/Flux），整个处理链路是异步的、流式的。
好处：高并发下性能和资源利用率显著更好——用很少的线程扛住大量请求，没有「线程被慢后端阻塞」的浪费。这和 Nginx 的 epoll 异步非阻塞是同样的思路（见「Nginx 高性能」专题）。代价是响应式编程模型学习成本较高（要理解 Mono/Flux、异步链路），调试也比同步的难一些。
四、官方态度与生态
除了技术模型，官方支持也是选型的重要因素：
- Zuul 1.x：Netflix 已经停止主要更新（Netflix 的很多 OSS 组件进入维护模式），Spring Cloud 也不再主推。
- Spring Cloud Gateway：是 Spring 官方自研并主推的网关，持续更新，与 Spring 生态（Spring Boot、Spring Cloud、注册中心、配置中心）集成最好，社区活跃。
所以从「长期维护和生态」角度，Spring 体系下的新项目应该选 Gateway。
五、关于 Zuul 2.x 的澄清
需要澄清一个常见混淆：Zuul 2.x 其实也改成了基于 Netty 的异步非阻塞模型（解决了 1.x 的阻塞问题）。所以「Zuul = 阻塞、Gateway = 非阻塞」严格说只对 Zuul 1.x 成立。
但是：Spring Cloud 官方并没有集成 Zuul 2.x，而是选择了自研的 Spring Cloud Gateway。所以在 Spring Cloud 生态里，主流、官方推荐的是 Gateway，Zuul 2.x 用得很少。面试回答时可以点出这个细节，显示理解深入：「Zuul 1.x 是阻塞的，Zuul 2.x 改成了 Netty 非阻塞，但 Spring Cloud 官方选了自研的 Gateway，所以 Spring 生态主流用 Gateway」。
六、常见误区与追问
这道题面试时最容易丢分的地方，是把「Spring Cloud Gateway 与 Zuul 对比」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着 统一流量入口链路 拆清楚流程，最后补上异常场景、数字边界和选型取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心定义 | Zuul 1 基于 Servlet 阻塞模型，Spring Cloud Gateway 基于 WebFlux/Reactor Netty 非阻塞模型 | 不要停在名词解释 |
| 流程机制 | 请求进入网关 -> Zuul 1 使用 Servlet 线程处理 -> Gateway 使用事件循环处理 I/O -> 执行过滤器 -> 转发后端并返回 | 说明谁触发、谁存储、谁通知、谁兜底 |
| 工程取舍 | I/O 密集转发场景下，非阻塞模型能用较少线程承载更多并发连接，但业务阻塞操作仍会拖垮事件循环 | 网关适合收口横切能力，但不能把业务逻辑堆到网关，否则会形成新的复杂单体 |
Spring Cloud Gateway 与 Zuul 对比 面试拆解：
1. 请求进入网关
2. Zuul 1 使用 Servlet 线程处理
3. Gateway 使用事件循环处理 I/O
4. 执行过滤器
5. 转发后端并返回记忆钩子：先拆路由、过滤器、鉴权、限流、熔断、灰度，再说明网关和业务服务的边界；回答时一定要落到题目中的「Spring Cloud Gateway 与 Zuul 对比」，不要把相邻中间件的能力混着讲。
- 误区：Gateway 一定在所有场景都比 Zuul 快。 它的模型更适合 I/O 密集，但如果过滤器里写阻塞逻辑，同样会变慢。
- 误区：Zuul 完全不能用。 老系统仍可能稳定运行 Zuul，迁移要看生态、维护状态和改造成本。
- 误区：非阻塞模型不需要线程池。 CPU 密集或阻塞操作仍要隔离到专用线程池，不能堵事件循环。
- 追问：Gateway 为什么不能和 Spring MVC 混用？ 它基于 WebFlux 响应式栈，和传统 Servlet MVC 栈模型不同。
- 追问：Zuul 2 为什么少见？ Spring Cloud 生态主推 Gateway，Zuul 2 在国内 Spring 微服务体系中使用较少。
- 追问：迁移时重点看什么？ 路由规则、过滤器逻辑、限流鉴权、监控指标和压测结果。
七、加强记忆
Spring Cloud Gateway vs Zuul 核心区别是线程模型：Zuul 1.x 基于 Servlet + 阻塞 IO，同步阻塞（一请求一线程），高并发线程暴涨、慢后端会阻塞线程、性能受限；Spring Cloud Gateway 基于 WebFlux + Netty + Reactor，异步非阻塞（响应式），少量线程事件驱动扛海量并发、转发不阻塞、高并发性能和资源利用率更好（同 Nginx epoll 思路），但响应式编程学习成本高。此外 Gateway 是 Spring 官方主推（Zuul 1.x 已停更）、生态集成更好、功能（Predicate+Filter）更强，原生支持 WebSocket。澄清：Zuul 2.x 也改成了 Netty 非阻塞，但 Spring Cloud 官方选了自研 Gateway、未集成 Zuul 2.x。结论：Spring 生态新项目用 Gateway。口诀：Zuul 1.x 阻塞、Gateway 响应式非阻塞、官方主推 Gateway。