为了防雪崩加了限流，结果入口先挂了

限流，本来是为了保护系统。

但在这次事故中，限流器本身成了第一个被拖垮的组件。

更糟的是：

后端服务没来得及崩
网关先失去了响应能力
所有请求卡在入口

这是一次非常典型的 "限流设计正确，但位置和实现错误" 的事故。

一、事故背景

系统架构简化如下：

text 复制代码

Client
  ↓
Spring Cloud Gateway（统一入口）
  ↓
下游微服务

事故发生前做了这些"看起来很正确"的事情：

在 Gateway 层做统一限流
使用 Redis 作为分布式限流存储
限流算法：令牌桶 / 滑动窗口
限流粒度：按接口 + IP

目标很明确：

入口挡流量，保护下游

二、事故现象

突发流量高峰后，系统表现为：

Gateway RT 飙升（几十 ms → 几秒）
大量请求超时
下游服务 CPU、线程池 仍然正常
Redis QPS 急剧上升
Gateway 实例频繁 Full GC

最终结果：

限流没挡住流量，反而把网关拖死了

三、第一反应：限流规则是不是失效了？

第一时间检查限流规则：

阈值配置正确
Redis key 在增长
限流命中率正常

结论很反直觉：

限流规则是生效的，但系统还是扛不住

问题不在"限没限住"，而在 "限流是怎么做的" 。

四、核心问题一：限流器成了"同步阻塞点"

Gateway 中的限流逻辑：

复制代码

请求进入
  ↓
执行限流判断（Redis）
  ↓
通过 → 转发
拒绝 → 返回 429

在高并发下，每一个请求都会：

同步访问 Redis
等待 Redis 返回结果
才能决定是否放行

📌 限流判断本身就是一次远程调用

当 QPS 上来时：

Redis RTT × 请求数
网关线程被大量阻塞
Reactor 线程开始堆积

五、核心问题二：Redis 成了"全局热点"

限流 key 设计如下（示例）：

javascript 复制代码

gateway:rate_limit:/order/create

问题在于：

热接口 → 热 key
所有 Gateway 实例
所有请求
都在竞争同一个 Redis key

结果：

Redis 单点瓶颈
网络 IO 放大
Gateway 等 Redis，Redis 又被 Gateway 打爆

👉 形成"限流互相伤害"

六、核心问题三：限流位置选错了

这次事故最大的设计问题是：

把"高成本限流"放在了最外层入口

Gateway 层的特点：

请求量最大
并发最高
对 RT 最敏感

但限流实现却是：

分布式
强一致
同步远程依赖

📌 入口层，最怕"慢"

七、为什么下游没挂，Gateway 先挂？

因为：

下游有线程池、熔断、限流
Gateway 是"放大器"
Gateway 一旦慢，所有请求都慢

一句话总结：

网关是系统的喉咙，不是缓冲区

八、正确的限流设计思路

1️⃣ Gateway 层只做"轻量限流"

适合 Gateway 的限流：

本地限流（Guava / Resilience4j）
基于内存
不依赖外部组件
宁可不准，也要快

📌 原则：

入口限流要"快失败"

2️⃣ 分布式限流下沉到服务内部

真正需要精确控制的地方：

核心接口
资源敏感操作
下游依赖重的逻辑

这些限流应该：

放在服务内
靠近资源
粒度更细

3️⃣ 限流本身也要被限流

这是很多系统忽略的一点：

Redis 限流 → Redis 也要保护
Gateway → 也需要自我保护策略

例如：

Redis 超时直接放行 / 拒绝
限流服务降级为本地策略

九、事故总结

这次事故并不是"限流没用"，而是：

限流实现成本过高
限流位置选择错误
忽略了入口层的吞吐特性

最终导致：

系统没被流量打垮，却被"保护机制"先拖垮

十、写在最后

限流不是越统一越好，

入口不是越重越安全。

在分布式系统中：

任何保护机制，如果本身不可控，都会成为新的风险点。

「代码不背锅」系列 · 生产事故复盘

写的不是功能，而是系统为什么会失控