hystrix-go虽已归档，但因go生态缺乏广泛采用的开箱即用熔断器替代品，仍为事实标准；其轻量、无依赖、接口清晰，存量系统稳定使用，但仅提供熔断功能，不支持指标暴露、prometheus集成或动态配置刷新。
为什么 hystrix-go 已停止维护，但仍是多数项目的事实标准
因为 Go 生态中至今没有被广泛采用的、开箱即用的熔断器替代方案。hystrix-go 虽在 2021 年标记为 archived，但它轻量、无依赖、接口清晰，且大量存量服务（尤其早期基于 Netflix OSS 架构演进的系统）仍在稳定使用。
真正要注意的不是“该不该用”，而是：它只做熔断，不做指标暴露、不集成 Prometheus、不支持动态配置刷新。这意味着你必须自己补全监控链路。
- 熔断状态变更（
Open/HalfOpen/Closed）需通过hystrix.SetLogger或打点到本地 channel 后异步上报 - 默认统计窗口是 10 秒、滑动桶数 10，即每 1 秒一个桶；修改需调用
hystrix.ConfigureCommand，且必须在首次执行前完成 - 它不拦截 panic，若下游函数内部 panic 未被捕获，会直接透出——必须在
run函数内加defer/recover
如何让 hystrix-go 的指标被 Prometheus 抓取
原生不支持，但可通过封装 hystrix.MetricCollector 实现。关键不是重写收集器，而是把它的内存计数映射成 prometheus.GaugeVec 或 prometheus.CounterVec。
最简可行路径：监听 hystrix.DefaultMetricCollector 的 GetCircuitCounters 方法，定时拉取并更新 Prometheus 指标。注意不要高频调用（如每秒一次），避免锁竞争。
func recordHystrixMetrics() {
for range time.Tick(5 * time.Second) {
counters := hystrix.GetCircuitCounters()
for name, c := range counters {
circuitState.WithLabelValues(name).Set(float64(c.State))
failureCount.WithLabelValues(name).Set(float64(c.Failures))
successCount.WithLabelValues(name).Set(float64(c.Successes))
timeoutCount.WithLabelValues(name).Set(float64(c.Timeouts))
}
}
}
-
c.State是 int 值：0=Closed、1=Open、2=HalfOpen，需映射为可读 label - 所有
WithLabelValues中的name必须和hystrix.Do第一个参数一致，否则指标无法对齐 - 别在
http.HandlerFunc里实时调用GetCircuitCounters，高并发下会成为瓶颈
不用 hystrix-go，用 gobreaker 有哪些实际差异
gobreaker 是目前最活跃的替代品，API 更现代，但行为细节有明显区别：它默认使用指数退避重试（HalfOpen 状态下首次请求成功后不会立即关闭熔断器，而是按间隔逐步放量），而 hystrix-go 是“一成功即 Closed”。
更关键的是错误分类逻辑：gobreaker 默认只将 error != nil 视为失败，而 hystrix-go 还会把超时、拒绝（拒绝队列满）单独计数。如果你依赖“拒绝数”判断线程池压力，换库后这部分监控会消失。
- 配置超时：前者靠
context.WithTimeout传入Run函数；后者靠hystrix.CommandConfig.Timeout - 自定义错误判定：两者都支持
ReadyToTrip函数，但gobreaker的回调参数是cb *CircuitBreaker和reqErr error，不提供历史请求统计 - 无全局默认配置，每个
gobreaker.CircuitBreaker实例需独立初始化，无法像hystrix.ConfigureCommand那样批量设置
线上服务突然大量 hystrix: timeout 日志，先查什么
这不是熔断器的问题，是下游响应慢或本端超时设得太紧。优先级顺序：查下游 P99 延迟 → 查本端 hystrix.CommandConfig.Timeout 设置 → 查是否误将同步 HTTP 客户端套在 hystrix.Do 里却没设 http.Client.Timeout。
- 如果下游延迟从 50ms 升到 800ms，而你的
Timeout是 600ms，那必然超时；此时调大Timeout只是掩盖问题 - 常见陷阱：用
resty或go-resty时，只设了hystrix超时，忘了resty.SetTimeout，导致底层连接卡住，最终触发hystrix超时而非业务超时 -
hystrix: timeout和hystrix: rejected不同：后者说明并发请求数超过MaxConcurrentRequests，要查 goroutine 泄漏或突发流量
熔断本身不会导致异常增多，它只是对已有异常的响应。真正在意的永远是第一个失败请求的根因——网络、下游 GC、DB 锁、还是你自己的反序列化 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
