超时、重试、限流、熔断与降级：构建可观察的可靠服务

可靠性设计不是堆组件，而是让故障有边界：请求不能无限等待，重试不能放大流量，过载时要尽早拒绝，依赖故障时要停止无效调用，并保留核心能力。

五种手段的职责

通常先有超时，再谈重试；重试必须有次数、指数退避、随机抖动和总时间预算。非幂等写操作不能盲目重试。

一次故障如何被放大

1
2
3
4
5
6
7

支付依赖变慢
  -> 请求线程或 Goroutine 堆积
  -> 连接池被占满
  -> 上游开始超时
  -> 客户端和服务自动重试
  -> 流量进一步放大
  -> 内存、CPU 和队列一起恶化

可行保护：为支付调用设置短于总请求的超时，只重试明确的瞬时错误，限制并发，达到失败阈值后熔断，并把非核心展示降级为稍旧缓存。

三组观测方法

Golden Signals：

• Latency：延迟。
• Traffic：流量。
• Errors：错误。
• Saturation：饱和度。

RED 适合请求型服务：Rate、Errors、Duration。USE 适合资源：Utilization、Saturation、Errors。

1
2
3

告警 -> 指标确认影响范围 -> Trace 找慢链路
     -> 日志查看具体错误 -> 变更记录找时间关联
     -> 缓解影响 -> 定位根因 -> 修复并验证

告警应该可行动

“CPU 超过 80%”不应成为固定真理。阈值要结合服务基线、持续时间、用户影响和 SLO。更有用的告警通常是“错误率持续升高且影响关键请求”或“队列按当前消费速率将在 20 分钟后超过容量”。

最小可观测闭环

• 指标回答系统是否出问题、影响多大。
• 日志回答某次请求发生了什么。
• Trace 回答时间花在哪个跨服务步骤。
• 请求 ID、用户或设备 ID、版本号和节点信息让三者可以关联。

敏感数据不能直接进入日志，尤其是 Token、密码、完整身份证件和支付信息。

延伸阅读

• Google SRE：Monitoring Distributed Systems
• OpenTelemetry Documentation