最省事直接上生产的熔断方案是用 sony/gobreaker 库，它轻量无依赖、符合规范，需配合超时和重试使用，状态内存驻留为合理设计，不需 redis 共享。
Go 里用 gobreaker 实现熔断最省事
直接上生产可用的方案：用 sony/gobreaker 库，它轻量、无依赖、符合 Circuit Breaker 模式规范。别自己手写状态机——熔断器核心是状态切换（Closed → Open → Half-Open）和超时重试逻辑，错一点就会导致雪崩或误熔断。
典型用法是包装一个可能失败的函数调用：
cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "user-service-call",
MaxRequests: 5,
Timeout: 60 * time.Second,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.ConsecutiveFailures > 3
},
OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
log.Printf("CB %s state changed from %v to %v", name, from, to)
},
})
<p>result, err := cb.Execute(func() (interface{}, error) {
return callUserService(ctx, userID)
})
-
MaxRequests控制半开状态下最多允许几个请求试探，不是并发数 -
ReadyToTrip触发熔断的条件，建议基于连续失败次数而非失败率（后者在低流量下易误判） - 返回的
err是gobreaker.ErrOpenState时，说明已被熔断，可立即 fallback
为什么不用 hystrix-go？
hystrix-go 已归档（archived），作者明确不再维护，且内部用 time.AfterFunc + 全局 map 管理超时，高并发下有锁竞争和 goroutine 泄漏风险。社区实际项目中已普遍迁移到 gobreaker 或更现代的 resilience-go。
如果你还在用 hystrix-go，注意这两个坑：
立即学习“go语言免费学习笔记（深入）”；
-
hystrix.Do的 command name 必须全局唯一，否则不同服务共用 name 会导致指标混杂、熔断互相干扰 -
hystrix.ConfigureCommand设置的Timeout是硬超时，但底层用context.WithTimeout包裹时，若被调用方没响应 context，仍会卡满超时时间
熔断器必须和超时、重试配合才有效
单独加熔断器没意义。下游接口 hang 住 10 秒，熔断器要等满 10 秒才记一次失败；而如果上游设了 2 秒超时，那 10 秒的 hang 就会被截断成 2 秒失败，快速积累熔断计数。
推荐组合策略：
- HTTP 客户端层统一设
context.WithTimeout(ctx, 2*time.Second) - 重试仅对幂等操作开启（如 GET），且最多 1 次重试，避免放大流量
- 熔断器的
Timeout要 ≥ 单次调用超时 ×（重试次数 + 1），否则还没等到重试完成就进 Open 状态
状态持久化和跨进程共享是伪需求
Go 微服务通常是多实例部署，gobreaker 的状态完全内存驻留，每个实例独立判断。这不是缺陷，而是设计选择：分布式熔断需要额外协调（如 Redis 计数），反而引入延迟和单点故障。真实场景中，各实例根据本地错误率自主熔断，反而更灵敏、更容错。
真要共享状态，不是加 Redis，而是换思路——把熔断决策上移到 API 网关（如 Kong、APISIX），用插件统一控制后端服务健康度。Go 服务本身保持无状态，专注业务逻辑。
最容易被忽略的一点：熔断器不会自动恢复慢接口。如果下游恢复了但 RT 仍偏高，gobreaker 默认只看成功/失败，不统计延迟。需要自己扩展 Counters 或接 metrics 上报做二次判断。
