这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
防止雪崩
场景
某个繁忙的周五下午，发生了系统雪崩。
事件经过：
14:30 - 新闻 API 外部数据源响应慢
14:35 - 新闻 API 占用大量连接
14:40 - 数据库连接池耗尽
14:45 - 所有 API 开始超时
14:50 - 整个系统不可用
影响：
- 所有用户都无法访问
- 持续时间：30 分钟
- 用户投诉激增根本原因
雪崩效应：
某个服务变慢
↓
占用资源（连接、线程）
↓
其他服务无资源可用
↓
整体系统崩溃防护措施
1. 熔断器（Circuit Breaker）
设计流程
1. 熔断器（Circuit Breaker）
- 步骤 1：检测异常并执行隔离、熔断、降级或恢复动作
- 步骤 2：更新熔断、降级或健康检查状态
- 步骤 3：失败重试、熔断或降级
关注点：故障隔离、恢复路径、用户影响和告警收敛。
2. 限流（Rate Limiting）
设计流程
2. 限流（Rate Limiting）
- 步骤 1：读取用量并判断是否超过配额
- 步骤 2：读取调用方身份、限流维度和当前窗口计数
- 步骤 3：按配额、窗口和突发流量规则更新限流结果
- 步骤 4：返回 200、排队提示或 429，并记录限流原因
关注点：限流维度、原子计数、误杀风险和告警阈值。
3. 超时控制
设计流程
3. 超时控制
- 步骤 1：检测异常并执行隔离、熔断、降级或恢复动作
- 步骤 2：识别故障信号、受影响服务和降级边界
- 步骤 3：根据失败率、超时和依赖状态选择保护策略
- 步骤 4：返回降级或恢复结果，并记录告警和影响范围
关注点：故障隔离、恢复路径、用户影响和告警收敛。
4. 资源隔离
设计流程
4. 资源隔离
- 步骤 1：触发隔离、熔断、降级或恢复动作
- 步骤 2：识别故障信号、受影响服务和降级边界
- 步骤 3：根据失败率、超时和依赖状态选择保护策略
- 步骤 4：返回降级或恢复结果，并记录告警和影响范围
关注点：故障隔离、恢复路径、用户影响和告警收敛。
5. 降级策略
设计流程
5. 降级策略
- 步骤 1：检测异常并执行隔离、熔断、降级或恢复动作
- 步骤 2：更新熔断、降级或健康检查状态
- 步骤 3：写入队列并异步消费
- 步骤 4：失败重试、熔断或降级
关注点：故障隔离、恢复路径、用户影响和告警收敛。
监控和告警
系统健康监控
设计流程
系统健康监控
- 步骤 1：检查健康状态并触发告警
- 步骤 2：检查健康状态并触发告警
- 步骤 3：更新熔断、降级或健康检查状态
- 步骤 4：失败重试、熔断或降级
关注点：故障隔离、恢复路径、用户影响和告警收敛。
应急预案
自动降级
设计流程
自动降级
- 步骤 1：失败后执行重试、降级或兜底路径
- 步骤 2：更新熔断、降级或健康检查状态
- 步骤 3：失败重试、熔断或降级
- 步骤 4：采集健康状态并触发告警
关注点：故障隔离、恢复路径、用户影响和告警收敛。
上线前多想一步
- 什么时候该熔断？ 不能等所有请求都超时才保护系统，错误率和等待时间要提前设一个边界。
- 降级后给用户什么？ 可以少返回一些数据，但最好不要让用户看到一片空白。
- 怎么恢复？ 外部服务刚恢复时不要立刻放开全部流量，先小步试探。