Spring Cloud Gateway 的工作原理和请求处理流程是怎样的？

简化版

Spring Cloud Gateway 基于 WebFlux（Netty，响应式非阻塞）。请求处理流程：① 请求到达网关（Netty 接收）→ ② DispatcherHandler 分发 → ③ RoutePredicateHandlerMapping 用各路由的 Predicate（断言）匹配，找到符合条件的 Route → ④ FilteringWebHandler 把这条路由的 Filter 和全局 Filter 组装成过滤器链 → ⑤ 请求依次经过各 Filter 的 pre（前置）逻辑（鉴权、限流、改写等）→ ⑥ 到达 NettyRoutingFilter 把请求转发给目标服务 → ⑦ 后端响应后，请求逆序经过各 Filter 的 post（后置）逻辑（改响应、记日志）→ ⑧ 返回给客户端。核心是「断言匹配路由 + 过滤器链加工 + 转发」。

详细版

请求处理流程（组件视角）：

Client → Netty(接收)
      → DispatcherHandler(总分发)
      → RoutePredicateHandlerMapping(用 Predicate 匹配路由)
      → FilteringWebHandler(组装过滤器链: 路由Filter + 全局Filter)
      → Filter链 pre 阶段(依次执行: 鉴权/限流/改写路径/加请求头...)
      → NettyRoutingFilter(转发请求到后端目标服务)
      → 后端服务处理并响应
      → Filter链 post 阶段(逆序执行: 改响应头/记录日志/统计耗时...)
      → 返回响应给 Client

关键组件：

DispatcherHandler：WebFlux 的请求总入口分发器。
RoutePredicateHandlerMapping：根据 Predicate 找到匹配的 Route。
FilteringWebHandler：组装并执行过滤器链。
NettyRoutingFilter：实际把请求转发给后端的过滤器。

完整版教学

一、基石：WebFlux 响应式非阻塞

理解 Gateway 的工作原理，先记住它的底座是 Spring WebFlux（基于 Netty + Reactor），是异步非阻塞的响应式模型（对比 Zuul 1.x 的同步阻塞，见「Gateway vs Zuul」专题）。这意味着：

请求的接收、处理、转发、响应，整条链路都是异步、事件驱动的。
用少量线程（Netty 的 EventLoop）就能处理大量并发请求，转发到后端后不阻塞等待，性能高。
代码里大量用 Mono / Flux（Reactor 的响应式类型）。

后面的请求流程都是在这个响应式框架里流转的。

二、请求入口：Netty → DispatcherHandler

Netty 接收请求：Gateway 底层是 Netty 服务器，客户端请求首先由 Netty 接收。
DispatcherHandler 分发：WebFlux 的核心分发器 DispatcherHandler 是请求的总入口，它负责把请求分发给合适的处理器——类似 Spring MVC 里 DispatcherServlet 的角色，但是响应式版本。

三、路由匹配：RoutePredicateHandlerMapping

找到匹配的路由：DispatcherHandler 把请求交给 RoutePredicateHandlerMapping。它遍历所有配置的 Route，用每条路由的 Predicate（断言） 去匹配当前请求：
- 断言检查请求是否满足条件（路径 /api/order/**、方法、请求头等）。
- 找到第一条所有断言都满足的路由，确定「这个请求要走这条路由、转发到这个目标」。
- 如果没有任何路由匹配，返回 404。

这一步的产物是：确定了这个请求对应的 Route（包含目标 uri 和这条路由的 Filter 列表）。

四、组装过滤器链：FilteringWebHandler

组装 Filter 链：确定路由后，请求交给 FilteringWebHandler。它把两类过滤器组装成一条完整的过滤器链：
- 这条路由自己的 GatewayFilter（在 route 配置的 filters，如 StripPrefix、RequestRateLimiter）。
- 所有的 GlobalFilter（全局过滤器，如鉴权、转发）。
- 按 order（优先级） 排序，组成有序的过滤器链。

五、执行过滤器链：pre → 转发 → post

pre 阶段（前置处理）：请求依次经过链上各 Filter 的前置逻辑——比如：
- 鉴权 Filter 校验 JWT；
- 限流 Filter 检查令牌桶；
- 路径改写 Filter（StripPrefix/RewritePath）修改请求路径；
- 加请求头 Filter 添加信息。
任何一个 pre 逻辑可以中断请求（如鉴权失败直接返回 401，不再往下）。
转发到后端：请求走到链的末端，由 NettyRoutingFilter（一个特殊的全局过滤器，order 最大、在最后）实际把请求转发给路由指定的目标服务（uri，经负载均衡选实例），并异步等待后端响应。
post 阶段（后置处理）：后端返回响应后，请求逆序经过各 Filter 的后置逻辑——比如修改响应头、记录日志、统计调用耗时。（Gateway 里 post 逻辑通常写在 Filter 的 chain.filter(exchange).then(...) 里，体现响应式的「转发完成后再执行」。）
返回响应：最终把处理后的响应通过 Netty 返回给客户端。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「网关工作原理」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着统一流量入口链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	网关本质是请求进入后经过路由匹配和过滤器链，再转发到后端服务并处理响应	不要停在名词解释
流程机制	接收请求 -> 匹配路由 -> 执行前置过滤器 -> 服务发现和负载均衡 -> 转发后端 -> 执行后置过滤器 -> 返回客户端	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	一次请求可能先经过鉴权、限流、日志 3 个前置过滤器，再转发到 order-service，响应回来后再记录耗时	网关适合收口横切能力，但不能把业务逻辑堆到网关，否则会形成新的复杂单体

网关工作原理 面试拆解：
1. 接收请求
2. 匹配路由
3. 执行前置过滤器
4. 服务发现和负载均衡
5. 转发后端
6. 执行后置过滤器
7. 返回客户端

记忆钩子：先拆路由、过滤器、鉴权、限流、熔断、灰度，再说明网关和业务服务的边界；回答时一定要落到题目中的「网关工作原理」，不要把相邻中间件的能力混着讲。

误区：网关只做路径转发。 它还会执行过滤器链，处理鉴权、限流、灰度、监控等横切逻辑。
误区：路由匹配后一定能成功调用。 还要经过鉴权、限流、熔断、服务发现和负载均衡等步骤。
误区：网关应该保存用户会话状态。 高可用网关通常保持无状态，会话信息放 Token、缓存或认证服务。
追问：过滤器链顺序为什么重要？ 鉴权通常要在业务转发前，日志和指标需要覆盖完整耗时。
追问：网关如何拿到后端实例？ 可通过静态 URI，也可从注册中心按服务名发现实例。
追问：后端超时时网关做什么？ 返回超时或降级响应，并记录指标、触发熔断策略。

七、加强记忆

Spring Cloud Gateway 基于 WebFlux（Netty + Reactor，响应式非阻塞）。请求处理流程（组件 + 阶段）：① Netty 接收 → ② DispatcherHandler 总分发 → ③ RoutePredicateHandlerMapping 用各路由的 Predicate 匹配，找到符合的 Route（定目标 uri 和 Filter）→ ④ FilteringWebHandler 组装过滤器链（路由 Filter + 全局 Filter，按 order 排序）→ ⑤ Filter 链 pre 阶段依次执行（鉴权/限流/改写路径，可中断）→ ⑥ NettyRoutingFilter 转发到后端目标服务 → ⑦ 响应回来后 Filter 链 post 阶段逆序执行（改响应/记日志）→ ⑧ 返回客户端。核心三件事：Predicate 匹配路由、Filter 链加工（pre/post）、转发到目标。口诀：分发→断言匹配路由→组装过滤链→pre 加工→转发→post 加工→返回。

简化版

详细版