🚪 一、Spring Cloud Gateway 是什么?
Spring Cloud Gateway 是基于 Spring WebFlux(反应式编程模型) 实现的 API 网关,
它是 Spring Cloud 官方推荐替代 Zuul 1.x 的网关组件。
在整个微服务架构中,它是:
🧩 所有外部请求的入口
🛡️ 统一鉴权、限流、路由、监控、日志、灰度、熔断等核心位置
🧱 二、整体架构与请求流程
👇 请求从客户端到服务的整个处理过程如下:
核心组件:
组件 | 作用 |
---|---|
Route(路由) | 定义请求要转发到哪个微服务 |
Predicate(断言) | 判断请求是否匹配路由(如path、header、method等) |
Filter(过滤器) | 对请求或响应做前置或后置处理 |
GlobalFilter(全局过滤器) | 对所有请求生效,用于统一日志、认证、限流等 |
LoadBalancerClient | 实现请求的负载均衡转发(Ribbon/LoadBalancer) |
WebFlux + Reactor | 支撑异步非阻塞的高性能响应模型 |
⚙️ 三、底层原理详解
1️⃣ Reactor + Netty 驱动
Spring Cloud Gateway 基于 Spring WebFlux 实现,底层是 Reactor Netty。
-
采用 异步非阻塞 I/O 模型,事件驱动。
-
每个请求不会占用线程池,可承载大量并发连接。
-
天然适合高吞吐、高并发场景。
2️⃣ 路由匹配机制
网关会从配置中加载所有 RouteDefinition,
每个路由包括:
-
id
-
predicates(匹配条件)
-
filters(过滤器链)
-
uri(目标服务地址)
请求到来时,网关会依次判断每个 Route 的 predicate 是否匹配。
3️⃣ Filter 链机制
Spring Cloud Gateway 的过滤器分为两类:
-
Pre Filter(前置过滤器):在转发前处理,如鉴权、日志、限流。
-
Post Filter(后置过滤器):在响应返回后处理,如统计、Header 修改。
所有过滤器构成一个有序链,通过 Reactor 的 Mono
异步流调用。
📘 四、常用配置与示例
✅ 1. 基础配置示例
lb:// 表示使用 LoadBalancerClient 进行负载均衡。
✅ 2. Predicate(断言)配置详解
断言类型 | 示例 | 说明 |
---|---|---|
Path | Path=/api/** | 路径匹配 |
Method | Method=GET,POST | 请求方法 |
Header | Header=X-Token, .+ | 头匹配正则 |
Host | Host=**.example.com | 域名匹配 |
Query | Query=version, v1 | 参数匹配 |
Between | Between=2025-10-01T00:00:00Z, 2025-10-30T00:00:00Z | 时间区间 |
✅ 3. Filter(过滤器)配置详解
Filter 名称 | 示例 | 说明 |
---|---|---|
AddRequestHeader | AddRequestHeader=X-Auth, abc | 添加请求头 |
RemoveRequestHeader | RemoveRequestHeader=Cookie | 删除请求头 |
RewritePath | RewritePath=/api/(?<path>.*), /${path} | 重写路径 |
SetStatus | SetStatus=401 | 设置响应码 |
StripPrefix | StripPrefix=1 | 去掉路径前缀 |
RequestRateLimiter | key-resolver,redis-rate-limiter | 限流 |
Retry | Retry=5 | 重试机制 |
CircuitBreaker | CircuitBreaker=name=cb1 | 熔断机制 |
🔄 五、负载均衡与容灾机制
Spring Cloud Gateway 内置支持:
-
Ribbon(老版本)
-
Spring Cloud LoadBalancer(推荐)
当路由定义为:
时,会自动从注册中心(Eureka/Nacos/Consul)中拿到 user-service
实例列表,
并通过负载均衡策略(如轮询、随机、权重)转发请求。
容灾机制
-
超时重试:通过
Retry
Filter 配置重试次数。 -
熔断降级:通过
CircuitBreaker
(基于 Resilience4j)。 -
限流保护:
RequestRateLimiter
(基于 Redis + Lua 脚本)。 -
健康检查与服务发现结合:当实例不可用时自动摘除。
💡 六、典型使用场景
场景 | 说明 |
---|---|
✅ 统一入口 | 所有外部请求统一进出 |
🛡️ 统一鉴权 | Token 鉴权、签名校验、黑白名单 |
⚙️ 统一路由 | 按业务模块、版本、灰度发布 |
🚦 限流与熔断 | 防止流量突发导致下游崩溃 |
🧾 日志与监控 | 记录API调用链路,结合ELK或Zipkin |
🧬 动态路由 | 配合 Nacos/Apollo 动态更新路由规则 |
⚙️ 七、性能优化建议
优化点 | 方法 |
---|---|
🔹 Reactor Netty 参数 | 调整线程池与连接池大小(reactor.netty) |
🔹 过滤器数量控制 | 减少无意义的Filter,避免链过长 |
🔹 限流与缓存 | Redis限流时使用Lettuce连接池 |
🔹 日志异步化 | 不同步写日志,使用异步队列 |
🔹 压测与监控 | 集成 Micrometer + Prometheus 监控响应时间 |
🧩 八、核心技术栈
模块 | 技术 |
---|---|
编程模型 | Spring WebFlux + Reactor |
底层网络 | Netty |
注册中心 | Nacos / Eureka / Consul |
负载均衡 | Spring Cloud LoadBalancer |
熔断降级 | Resilience4j |
限流 | Redis RateLimiter |
动态配置 | Nacos / Apollo |
📊 九、与 Zuul 的区别
对比项 | Spring Cloud Gateway | Zuul 1.x |
---|---|---|
底层模型 | Reactor + Netty(异步) | Servlet + IO(阻塞) |
性能 | 高(支持背压) | 低(线程阻塞) |
Filter 类型 | Pre + Post(异步) | 同步 |
动态路由 | 支持 Nacos、配置中心 | 需自定义 |
限流与熔断 | 内置支持 | 需结合 Hystrix |
🧠 十、总结一句话
Spring Cloud Gateway = Spring Cloud 体系下的高性能、反应式 API 网关。
它是微服务的第一道防线,也是服务治理、流量控制、监控埋点的核心中枢。