怎样在Golang模块中优雅引入熔断和自适应重试-Golang-PHP中文网

gobreaker.execute 必须包裹完整调用链，涵盖网络请求、body读取、反序列化及轻量校验等所有可能出错环节；fallback需绕过熔断器且无副作用；重试与熔断应正交配置，避免混淆超时与探测间隔。

怎样在golang模块中优雅引入熔断和自适应重试

gobreaker.Execute 必须包裹完整调用链，不能只包 HTTP client

熔断器不是“开关”，而是对整个业务操作失败信号的统计与响应。常见错误是只把 http.Get 包进 cb.Execute，但忽略后续的 io.ReadAll、JSON 解析或数据库写入——这些环节出错不会触发熔断计数，导致“熔断形同虚设”。

正确做法是把从发起请求到获取可用结果的全过程封装为一个函数：

包含网络调用、body 读取、反序列化、甚至轻量校验逻辑
所有可能返回 error 的步骤都应在该函数内完成，且 error 必须显式返回（panic 不会被 gobreaker 捕获）
若需 fallback，必须在 cb.Execute 外部处理，例如：if err != nil { return fallbackData(), nil }

重试要和熔断正交配置，别混用超时和失败阈值

http.Client.Timeout 控制单次请求挂起上限，gobreaker.Settings.Timeout 控制熔断开启后多久进入半开状态，两者语义完全不同。混淆会导致：

设 Timeout: 1 * time.Second —— 熔断器 1 秒后就试探，但下游服务实际恢复需 10 秒，反复失败
设 MaxRequests: 1 —— 半开状态下只允许 1 次试探，失败即退回 open，永远无法恢复
重试次数 > 熔断失败阈值（如连续失败 3 次触发熔断，但重试 5 次）—— 熔断根本不会生效

推荐组合：

重试最多 3 次，指数退避 + jitter（如 100ms/200ms/400ms + 随机偏移）
熔断 ReadyToTrip 判定基于窗口内失败率，例如 counts.Failures / counts.TotalRequests > 0.5
Interval: 60 * time.Second，Timeout: 30 * time.Second，留出足够探测窗口

go-zero breaker 可直接复用，但要注意它不自动 retry

如果你项目已用 go-zero，它的 core/breaker 模块可直接 import 使用，无需额外依赖。但它只做状态管理，不内置重试逻辑：

调用方式是 brk.Do(func() error { ... })，返回 error 后需自行决定是否重试
它的 breaker.NewBreaker() 默认使用 Google 自适应算法（基于失败率动态调整阈值），比固定阈值更抗抖动
注意：它不提供 Execute 那样的 (interface{}, error) 返回形式，只返回 error，适合纯副作用操作

示例：

brk := breaker.NewBreaker()
err := brk.Do(func() error {
    _, err := http.DefaultClient.Do(req)
    return err
})
if err != nil {
    // 此处可加 retry，但必须自己实现，brk 不参与
}