Go 微服务超时、重试与熔断观测：避免故障放大的实践

下游服务变慢时，盲目重试会把故障放大。没有超时预算和熔断观测，上游线程、连接和 goroutine 都可能被慢依赖拖住。

解决方案思路

入口请求先确定总超时预算，每个下游调用分配子预算；重试只用于幂等操作，并使用指数退避和最大次数；熔断打开、半开、关闭状态都要记录指标和 trace event。

核心代码示例

ctx, cancel := context.WithTimeout(parent, 800*time.Millisecond)
defer cancel()
for attempt := 0; attempt 

运行逻辑

一次请求会带着时间预算向下游传播。若下游超时，先判断是否可重试；连续失败后熔断打开，后续请求快速失败或走降级，避免占满资源。

重点观察指标

• timeout、retry、circuit_open、fallback 命中次数
• 下游 P99、错误率和调用量
• 重试放大倍率与入口 QPS 对比

常见误区

• 没有幂等性就重试写请求
• 子调用超时大于入口总超时
• 只配置熔断，不监控熔断状态

参考方案

• context 官方文档
• OpenTelemetry Go 文档

落地检查

• 字段、指标和 Span 名称要稳定，便于长期聚合。
• 上线前先在灰度环境验证采集成本和数据量。
• 告警必须能指向 owner、排查入口和回滚方案。