hystrix-go 已弃用，应换用 sony/gobreaker 等现代库；其基于全局状态、阻塞设计，与 Go 的 context/chan 并发模型不兼容，导致测试难、超时不可控、panic 难捕获。
为什么 hystrix-go 已基本弃用，该换什么
因为官方 hystrix-go 早在 2019 年就标记为 DEPRECATED，不再维护，且其基于全局状态、同步阻塞式设计与现代 Go 的并发模型（如 context、chan）不兼容。继续用它会导致测试难、超时不可控、panic 难捕获等问题。
当前主流替代是：
-
sony/gobreaker：轻量、无依赖、纯函数式配置，熔断状态完全封装在gobreaker.Breaker实例中 -
resilience-go（原go-resilience）：支持熔断 + 重试 + 限流组合策略，API 更现代，但稍重 - 自建基于
sync/atomic+time.Timer的极简实现（仅需 50 行，适合嵌入 SDK）
用 gobreaker 实现 HTTP 调用熔断的最小可行代码
核心是把外部 HTTP 调用包裹进 breaker.Execute，它会自动统计失败率、触发熔断、执行 fallback，并在休眠期后试探性放行。
package main <p>import ( "context" "fmt" "net/http" "time"</p><pre class='brush:php;toolbar:false;'>"github.com/sony/gobreaker"
)
立即学习“go语言免费学习笔记（深入）”；
var cb *gobreaker.CircuitBreaker
func init() { cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{ Name: "payment-service", MaxRequests: 3, Timeout: 5 * time.Second, ReadyToTrip: func(counts gobreaker.Counts) bool { return counts.TotalFailures > 2 && float64(counts.Failures)/float64(counts.TotalRequests) > 0.6 }, OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) { fmt.Printf("CB %s: %s → %s\n", name, from, to) }, }) }
func callPayment(ctx context.Context, url string) (string, error) { // 注意：Execute 接收的是 func() (interface{}, error)，必须自己处理类型转换 result, err := cb.Execute(func() (interface{}, error) { req, _ := http.NewRequestWithContext(ctx, "GET", url, nil) resp, err := http.DefaultClient.Do(req) if err != nil { return nil, err } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { return nil, fmt.Errorf("HTTP %d", resp.StatusCode) } return "ok", nil }) if err != nil { return "", err } return result.(string), nil }
熔断器参数调优的关键陷阱
多数线上故障不是没加熔断，而是参数设得太“理想”：
-
MaxRequests不是并发数，而是“熔断开启后，半开状态下允许通过的最大请求数”，设太小（如 1）会导致恢复过于激进；设太大（如 100）则半开期过长 -
Timeout必须 > 后端 P95 延迟，但 proxy_read_timeout），否则熔断器还没判断完，调用方已超时，失去意义 -
ReadyToTrip条件里用counts.TotalRequests而非counts.Requests——后者只统计采样窗口内请求，前者是全生命周期计数，避免冷启动误判 - 不要共享同一个
Breaker实例去保护多个下游服务；每个依赖应有独立实例，否则一个服务抖动拖垮全部
如何让熔断器和 Gin / gRPC 透明集成
关键不是“包装 handler”，而是包装 client 调用点。例如在 gRPC 客户端拦截器中注入：
func breakerUnaryClientInterceptor(cb *gobreaker.CircuitBreaker) grpc.UnaryClientInterceptor {
return func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
_, err := cb.Execute(func() (interface{}, error) {
return nil, invoker(ctx, method, req, reply, cc, opts...)
})
return err
}
}对 Gin，则应在 service 层（而非 controller 层）调用封装好的带熔断的 client 方法；controller 只负责 HTTP 状态码映射和 context.WithTimeout。
真正容易被忽略的是：熔断器无法解决慢依赖引发的连接池耗尽问题。必须配合 http.Transport.MaxIdleConnsPerHost 和 context.Deadline 使用，否则熔断打开后，堆积的 goroutine 仍会吃光内存。
