从咖啡机看服务熔断设计
构建一个有自愈能力的系统，就像调教一台不会炸锅的咖啡机。
☕ 故障，从一杯咖啡说起
想象你是一家咖啡店店主，有三台咖啡机：
- A：Espresso 机，冲煮速度快
- B：美式咖啡机，产能稳定
- C：奶泡机，偶尔卡顿
某天 B 机因管道堵塞，冲一杯咖啡要 60 秒，但系统仍持续调度请求到它，结果队伍越排越长，用户愤怒离开。
🤯 “明知有问题，还继续请求”是灾难的根源
在分布式系统中，服务 B 可能是某个微服务（如用户画像服务），当它响应极慢或返回错误时：
- 主调服务继续转发请求，线程被卡死
- 整个请求链拖慢甚至雪崩
- 日志刷屏，CPU 爆表，业务无法恢复
这就是缺乏熔断机制导致的级联故障。
🧠 引入熔断器（Circuit Breaker）机制
熔断器是一种在调用失败到达阈值时临时阻断请求的保护机制，源自电路保护系统。
┌─────────────┐
│ 调用下游服务 │
└─────────────┘
│
┌──────▼──────┐
│ 熔断器 (CB) │ ← 检查失败率/RT
└──────┬──────┘
│
┌──────▼──────┐
│ 服务是否健康 │
└─────────────┘
🔁 三态模型：熔断器的生命周期
| 状态 | 含义 | 请求行为 |
|---|---|---|
| Closed | 正常工作，记录失败率 | 所有请求通过 |
| Open | 失败率高，立即拒绝请求 | 所有请求失败，快速失败 |
| Half-Open | 试探恢复，允许部分请求通过 | 少量请求试探 |
🎬 状态转换流程
Closed ──[失败率高]──▶ Open ──[定时检测]──▶ Half-Open
▲ │
└──────────[试探成功]◀───────────┘
🔎 熔断器 vs 重试 vs 限流
| 机制 | 场景适用 | 常用工具 |
|---|---|---|
| 熔断器 | 下游服务长时间不稳定 | Resilience4j / Hystrix / Sentinel |
| 重试 | 偶发失败（网络抖动） | retry-go / backoff |
| 限流 | 限制突发请求量，保护自身 | token bucket / leaky bucket |
⚠️ 重试没有熔断等于反复撞墙，应搭配使用！
🧪 如何设计熔断参数？
| 参数 | 建议配置 |
|---|---|
| 最小请求数 | ≥ 20（避免样本太小误熔断） |
| 失败率阈值 | 50%~70%（根据 SLA 要求调整） |
| 熔断时长 | 5~60 秒（根据业务容忍度） |
| 半开探测比例 | 1~5% 请求 |
☠️ 熔断带来的副作用？
熔断是一种防御性策略，但也可能造成“拒绝服务”：
- 熔断时所有请求失败，用户体验下降
- 如果熔断器误判，可能拒绝健康服务
📌 所以你应该提供：
- 备用降级逻辑（Fallback）
- 熔断指标监控 + 异常报警
- 面向关键路径进行灰度熔断或服务隔离
🛠 熔断器实现推荐（Go）
| 框架 | 特性 |
|---|---|
| goresilience | 熔断、限流、重试一体 |
| sony/gobreaker | 简洁实用，Netflix 风格 |
| afex/hystrix-go | Hystrix Go 实现 |
示例：sony/gobreaker
st := gobreaker.Settings{
Name: "UserService",
MaxRequests: 5,
Interval: 60 * time.Second,
Timeout: 10 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 3
},
}
cb := gobreaker.NewCircuitBreaker(st)
result, err := cb.Execute(func() (any, error) {
return CallUserService()
})
🧩 类比总结表：从咖啡机到熔断器
| 咖啡店场景 | 服务场景 |
|---|---|
| 咖啡机出故障 | 服务响应变慢或失败 |
| 关闭该咖啡机维修 | 熔断请求避免连锁反应 |
| 定期试机是否修好 | Half-Open 试探 |
| 提供速溶咖啡降级 | 提供 fallback 响应 |
| 排队控制每人限购 | 限流（Rate Limiting） |
✅ Checklist：微服务容错设计
- ✅ 是否配置熔断器，防止级联故障？
- ✅ 是否设置合理熔断策略（失败率、窗口、恢复）？
- ✅ 是否提供降级 fallback，避免裸返回错误？
- ✅ 是否具备熔断状态监控和告警能力？
- ✅ 是否在调用链中对关键依赖服务单独隔离熔断？
🧠 收官感言：让系统像“聪明的咖啡机”
一个优秀系统不该在所有异常都手忙脚乱。
它应该像一台自知能力有限的咖啡机：
- 知道何时该暂停
- 懂得如何自我检测
- 提供可接受的备选方案
- 并在合适的时机恢复服务
熔断器不是“怕出错”，而是让系统出错也能可控、有尊严地失败。