Go微服务需要熔断而非仅靠超时和重试，因后者无法应对下游持续不可用导致的雪崩；熔断器通过状态机在失败达阈值时主动断开调用，gobreaker是主流轻量选择，需配置ReadyToTrip、OnStateChange和Timeout三参数，并手动实现fallback。
为什么 Go 微服务需要熔断，而不是只靠超时和重试
超时和重试解决的是单次请求延迟或偶发失败，但当下游服务持续不可用（如数据库卡死、依赖接口雪崩），重试反而加剧压力，形成恶性循环。熔断器本质是一个状态机，在连续失败达到阈值后主动“断开”调用，避免无效请求堆积、线程耗尽或级联故障。Go 本身没有内置熔断器，必须依赖第三方库或自研，而 gobreaker 是目前最轻量、无依赖、符合 circuit breaker 模式规范的主流选择。
用 gobreaker 实现基础熔断：三步配齐状态机
gobreaker 的核心是 cb.NewCircuitBreaker 构造器，它接受一个 cb.Settings 结构体。关键参数不是越多越好，而是三个必须明确：
-
ReadyToTrip：定义“何时熔断”，典型写法是统计最近 10 次调用中失败率 > 60%，用cb.CountError辅助判断 -
OnStateChange：状态切换回调，建议打日志（如"circuit state changed to: %s"），便于排查为何突然不发请求 -
Timeout：熔断开启后，等待多久尝试半开（half-open）状态，默认 60 秒，生产环境常设为 30–120 秒，太短易抖动，太长恢复慢
注意：gobreaker 不自动处理 fallback，需在 cb.Execute 的 error 分支里显式实现降级逻辑，比如返回缓存值或空结构体。
HTTP 客户端集成熔断：别直接包住 http.Do
常见错误是把整个 http.Client.Do 套进 cb.Execute，导致连接池复用失效、TLS 复用中断、超时被熔断器覆盖。正确做法是仅包裹业务逻辑部分——即“发起请求并解析响应”的环节：
立即学习“go语言免费学习笔记（深入）”；
func callUserService() (User, error) {
return cb.Execute(func() (interface{}, error) {
resp, err := httpClient.Do(req)
if err != nil {
return nil, err
}
defer resp.Body.Close()
if resp.StatusCode != 200 {
return nil, fmt.Errorf("unexpected status: %d", resp.StatusCode)
}
var user User
if err := json.NewDecoder(resp.Body).Decode(&user); err != nil {
return nil, err
}
return user, nil
})
}
这样既保留了 http.Client 的连接复用与上下文控制，又让熔断器只对“业务语义失败”（非网络层）敏感。
熔断指标如何观测：不要等出事才看日志
gobreaker 提供 cb.State() 和 cb.Ready()，但它们是瞬时快照，不适合监控。推荐做法是定期（如每 10 秒）调用 cb.GetMetrics()，它返回 cb.Metrics 结构，含 TotalRequests、Failures、Successes 等字段，可推送到 Prometheus 的 counter 或直接写入日志做趋势分析。特别注意 ConsecutiveFailures —— 如果它长期 > 0 且不归零，说明下游根本没恢复，或者你的 ReadyToTrip 条件太宽松。
真正容易被忽略的是熔断器自身的健康：如果服务启动时下游完全不可达，熔断器可能在初始化阶段就进入 StateOpen，但你没监听 OnStateChange 就会误以为“一切正常只是没流量”。上线前务必模拟一次强制失败，确认状态流转和日志输出都符合预期。
