Go微服务中熔断与降级必须用专门库（如sony/gobreaker）配合状态机，因标准库无失败率统计、半开探测等能力；重试不等于熔断，需显式定义失败判定、降级响应及可观测埋点。

Go 微服务中，熔断与降级不能靠 if err != nil 硬扛，必须用专门的库配合明确的状态机控制；否则服务雪崩时你连日志都来不及打。

为什么标准 net/http 或 grpc-go 自带重试不等于熔断

HTTP 客户端重试只解决瞬时网络抖动，但无法识别“下游持续超时/大量 500”这类系统性故障。熔断核心是状态感知 + 自动隔离，而 Go 标准库完全不维护调用历史、失败率、半开探测等状态。

• http.Client 的 Timeout 和 Transport 设置只能控制单次请求，不会阻止后续请求继续压向已崩溃的服务
• grpc-go 的 WithBlock 或 FailFast 是连接级策略，不是业务调用级熔断
• 自己手写计数器 + time.AfterFunc 模拟熔断极易出竞态，且难支持滑动窗口、自动恢复等关键行为

用 sony/gobreaker 实现生产级熔断（推荐）

这是目前 Go 生态最轻量、无依赖、被 go-micro 和 kratos 等框架默认集成的熔断器。它基于状态机（Closed → Open → Half-Open），支持自定义失败判定、超时、滑动窗口计数。

• 初始化时指定 Settings：比如 Interval: 60 * time.Second（滑动窗口长度）、Timeout: 10 * time.Second（熔断后保持 Open 的最短时间）
• 失败判定靠 ReadyFunc 返回 error，建议包装 HTTP status code 或 gRPC status.Code()，不要只判 err != nil
• 每次调用前必须用 cb.Execute 包裹，它会自动路由到 fallback 或直接 panic（取决于配置）
• 示例片段：

  cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
      Name:        "user-service",
      MaxRequests: 5,
      Interval:    30 * time.Second,
      Timeout:     5 * time.Second,
      ReadyToTrip: func(counts gobreaker.Counts) bool {
          return counts.TotalFailures > 3 && float64(counts.TotalFailures)/float64(counts.Requests) > 0.6
      },
  })
  _, err := cb.Execute(func() (interface{}, error) {
      return callUserService(ctx, req)
  })

降级逻辑必须显式声明，不能藏在 recover 里

熔断器触发后，Execute 会返回预设错误（如 gobreaker.ErrOpenState），此时你要主动提供兜底数据或空响应——这不是异常处理，而是业务契约的一部分。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

立即学习“go语言免费学习笔记（深入）”；

• HTTP 场景下，降级可返回缓存值、静态 JSON 或默认对象，但要确保 Content-Type 和结构体字段兼容原接口
• gRPC 场景下，降级必须返回合法的 *pb.Response，不能返回 nil 或类型错配的 struct
• 避免在降级函数里再发起外部调用（比如查 Redis 失败又去查本地文件），这会让降级本身成为新瓶颈
• 关键路径上，建议把降级逻辑提前注册为闭包，而非运行时 if-else 判断，减少分支开销

别忽略熔断器的可观测性埋点

线上出问题时，你没法靠 fmt.Println 查熔断器状态。gobreaker 提供 cb.State() 和 cb.Counts()，但必须主动上报，否则等于没开。

• 每分钟采集一次 State()（gobreaker.StateClosed/Open/HalfOpen）推送到 Prometheus gobreaker_state{service="xxx"}
• 用 Counts() 中的 TotalRequests、TotalFailures 计算失败率，设置告警阈值（如 5 分钟内失败率 >80%）
• 注意：gobreaker 默认不记录具体失败原因，如需定位是超时还是 503，得在 Execute 的闭包里手动打日志

真正难的不是接入熔断器，而是定义清楚“什么算失败”“降级返回什么才不影响前端渲染”“熔断多久后试探性放行”。这些决策必须和产品、前端、SRE 对齐，代码只是执行载体。