这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
限流中间件
实现限流中间件
设计流程
实现限流中间件
- 步骤 1：读取用量并判断是否超过配额
- 步骤 2：读取用量并判断是否超过配额
- 步骤 3：把放行、拒绝和等待时间写入监控指标
- 步骤 4：执行限流判断并决定放行、等待或拒绝
关注点：限流维度、原子计数、误杀风险和告警阈值。
效果验证
上线后，我观察了一周：
User 123 的调用变化
限流前：
- 每小时：15000 次
- 每秒：4.2 次
限流后（免费版 1 次/秒）：
- 每小时：3600 次
- 每秒：1 次
- 被限流次数：11400 次/小时整体性能提升
限流前：
- QPS：10
- 响应时间：150ms
- CPU 使用率：70%
限流后：
- QPS：5
- 响应时间：50ms
- CPU 使用率：30%用户反馈
正常用户：
- "API 速度快了很多" ✅
User 123（被限流的用户）：
- 收到通知，告知需要升级套餐
- 部分用户升级到付费版 ✅
- 部分用户减少调用频率 ✅监控和告警
设计流程
监控和告警
- 步骤 1：读取用量并判断是否超过配额
- 步骤 2：在 Redis 中原子更新限流计数并设置窗口过期时间
- 步骤 3：计算用量、账单或套餐状态
- 步骤 4：采集健康状态并触发告警
关注点：限流维度、原子计数、误杀风险和告警阈值。
上线前多想一步
- 误伤正常用户怎么办？ 先观察被拒绝的请求里有没有正常使用场景，再调阈值。
- 拒绝时怎么提示？ 返回“太频繁了，多久后再试”，比只返回错误码更容易被理解。
- 阈值怎么改？ 免费版、付费版和内部用户最好能分开配置，不要写死在代码里。