Go微服务容错需限流、熔断、重试协同：限流前置防拖垮，熔断快速止损，重试补偿临时故障；按接口粒度限流，50%~60%错误率触发熔断，仅重试临时错误并配合指数退避。
在 Go 微服务中，单靠重试、限流或熔断中的某一种机制，很难应对真实生产环境的复杂故障（如网络抖动、下游雪崩、瞬时洪峰）。真正有效的容错，是让三者协同工作：限流前置保护自身，熔断快速失败止损，重试在可控范围内补偿临时故障。下面给出一个轻量、可落地的组合实践方案。
用 go.uber.org/ratelimit 做请求级限流
限流不是为了“挡流量”，而是防止自身被拖垮，给恢复留出时间。推荐使用 token bucket 模型，简单高效，适合服务入口或关键依赖调用前。
- 按接口粒度配置（如
/order/create限制 100 QPS），避免全局一刀切 - 与 context 结合，在超时或拒绝时立即返回错误，不排队等待
- 示例：对下游支付服务调用前加限流器，防止支付异常时大量请求堆积在本地 goroutine 中
用 github.com/sony/gobreaker 实现熔断器
熔断器核心是状态机（Closed → Open → Half-Open），关键在于合理设置阈值和时间窗口，避免误熔或熔太晚。
- 错误率阈值建议设为 50%~60%（连续 20 次调用中失败 ≥10 次），太敏感易误熔，太迟钝失去意义
- Open 状态持续时间设为 30 秒左右，足够观察下游是否恢复；Half-Open 下只放行 1~2 个试探请求
- 务必在熔断开启时记录日志，并触发告警（如 Prometheus + Alertmanager）
重试需配合上下文、退避与熔断判断
盲目重试会放大问题。真正的“智能重试”必须满足三个条件：可重试错误类型、未超时、且熔断器处于 Closed 或 Half-Open 状态。
立即学习“go语言免费学习笔记（深入）”；
- 只重试临时性错误（如
context.DeadlineExceeded、io.EOF、HTTP 502/503/504），跳过 4xx 类业务错误 - 使用带 jitter 的指数退避（如 base=100ms, max=1s），避免重试请求同时打到下游
- 在重试前检查熔断器状态：
if cb.State() == gobreaker.StateClosed || cb.State() == gobreaker.StateHalfOpen
组合编排：用中间件统一串联三者
把限流、熔断、重试封装成 HTTP 或 gRPC 客户端中间件，避免每个业务逻辑重复写胶水代码。
- 顺序建议：限流 → 熔断 → 重试 → 实际调用（即先拦、再判、后补）
- 对同一依赖（如 user-svc）复用同一个熔断器实例和限流器实例，共享状态
- 通过配置中心（如 etcd/Viper）动态调整参数，无需重启服务
基本上就这些。不需要引入庞大框架，用几个成熟小库 + 明确的协作逻辑，就能构建出响应快、不传播故障、还能自我恢复的微服务容错能力。
