必须为每个下游服务单独创建gobreaker.CircuitBreaker实例，因其按依赖隔离设计，共用实例会导致故障污染；命名需带服务标识，配置Timeout=15s、Interval=30s～2m、MaxRequests≥10，并配合context超时与Prometheus监控。
sony/gobreaker 是当前 Golang 微服务中实现熔断与降级最稳妥的选择，别自己手写状态机，也别用已停止维护的 hystrix-go（2025 年起社区已明确转向 resilience-go / sony/gobreaker）。
为什么必须为每个下游服务单独创建 gobreaker.CircuitBreaker 实例
熔断器不是全局开关，而是按依赖隔离的“保险丝”。共用一个实例会导致 A 服务故障把 B 服务也拖垮。
- 每个 HTTP 客户端、gRPC stub、数据库连接池都应配独立
cb实例 - 命名必须带服务标识，例如
Name: "payment-service-call"或Name: "redis-cache-read" - 若复用实例，滑动窗口统计会混杂不同延迟特征、错误类型、恢复节奏的服务行为，导致误判（比如缓存超时拉高整体错误率，把健康的 DB 调用也熔断了）
gobreaker.Execute 只能包裹真正发起请求的那一行
常见错误是把整个 http.Client.Do 初始化或 grpc.ClientConn 创建塞进 Execute，这会让熔断器误判资源初始化失败为业务调用失败。
- 正确做法：只包住
client.Do(req)、stub.GetUser(ctx, req)、db.QueryRowContext(ctx, ...)这类实际发包/发 RPC/发 SQL 的调用 - 必须主动将 5xx 响应转为
error，否则gobreaker不会统计为失败（HTTP 200 + body 中含{"code":500}不算失败） -
Execute的 fallback 函数签名必须严格匹配主函数：func() (interface{}, error)，且内部不能 panic、不能阻塞、不能触发新外部调用
超时、滑动窗口、半开探测参数怎么设才不踩坑
Timeout 是“熔断后多久尝试半开”，不是单次调用超时——这个误解导致大量线上服务恢复延迟。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
Timeout：建议 15s，太短（如 2s）会让刚恢复的服务被反复打爆；太长（如 60s）导致用户持续看到降级页 -
Interval：滑动窗口重置周期，30s～2m 之间选；设成 5s 会把一次网络抖动当成持续故障 -
MaxRequests：半开状态下允许通过的最大请求数，必须 ≥10；设为 1 容易因单次随机失败立刻切回 Open - 务必配合
context.WithTimeout控制单次调用超时，否则 fallback 本身也可能卡住（比如 fallback 里去读一个没设 timeout 的 Redis）
没监控的熔断等于黑盒拉闸
gobreaker.Metrics 必须暴露给 Prometheus，否则你根本不知道熔断器在什么时候、因为什么打开了。
立即学习“go语言免费学习笔记（深入）”；
- 重点盯三个指标：
circuit_breaker_state（当前状态）、circuit_breaker_requests_total（各状态请求数）、circuit_breaker_fallback_total（降级触发次数） - 最容易被忽略的是状态变化日志：建议在
OnStateChange回调里打Info级日志，记录从 Closed → Open 的具体时间、前 10 秒错误率、最近失败原因（如 “dial tcp: i/o timeout”） - fallback 返回的数据必须是纯内存计算或本地缓存，不能再去查另一个可能也挂掉的下游
