gRPC 微服务不可用 retryablehttp，因其仅支持 HTTP/1.1；应使用 gRPC 原生拦截器实现带 jitter 的指数退避重试，并配合熔断器与服务端幂等校验。

Go 的 retryablehttp 客户端不适用于 gRPC 微服务

gRPC 调用走的是 HTTP/2 协议栈，而 retryablehttp 是为 RESTful HTTP/1.1 设计的，底层依赖 net/http.Client，无法处理 gRPC 的流控、状态码映射（如 codes.Unavailable）、元数据透传等。直接套用会导致重试逻辑失效或 panic。

正确做法是使用 gRPC 原生的 grpc.WithUnaryInterceptor 或 grpc.WithStreamInterceptor 配合重试拦截器。官方推荐方案是基于 google.golang.org/grpc/codes 和 google.golang.org/grpc/status 判断是否可重试：

• codes.Unavailable、codes.ResourceExhausted、codes.Aborted 通常可重试
• codes.InvalidArgument、codes.NotFound、codes.AlreadyExists 绝对不可重试（语义错误）
• 需排除 codes.DeadlineExceeded —— 它本身已是超时结果，再重试会加剧雪崩

自定义重试拦截器必须控制最大重试次数和退避时间

无限制重试等于拒绝服务攻击。gRPC 默认不提供重试策略，必须手动实现拦截器并注入退避逻辑。常见错误是只做固定间隔重试（如每次 sleep 100ms），这在高并发下会引发请求风暴。

推荐使用带 jitter 的指数退避（exponential backoff with jitter）。示例中使用 github.com/cenkalti/backoff/v4 库，配置如下：

bo := backoff.NewExponentialBackOff()
bo.InitialInterval = 100 * time.Millisecond
bo.MaxInterval = 2 * time.Second
bo.MaxElapsedTime = 10 * time.Second // 总耗时上限
bo.Multiplier = 2.0
bo.RandomizationFactor = 0.5 // 加入抖动，避免同步重试

关键点：

• MaxElapsedTime 比单纯设 MaxRetries 更可靠 —— 网络延迟波动大，固定次数易超时或不足
• 每次重试前必须调用 bo.NextBackOff() 获取当前等待时长，不能复用初始值
• 拦截器内要 clone ctx 并设置新 deadline，否则原 ctx 的 deadline 会传染到重试请求

重试时必须跳过幂等性被破坏的操作

不是所有 RPC 都能重试。例如 CreateOrder 接口若重试两次，可能生成两个订单；PayOrder 若重试，可能扣两次款。这类操作必须由业务层标记为「不可重试」，或通过 idempotency key + 服务端幂等校验兜底。

建议在客户端统一加注解式控制（非语言原生，可用结构体字段或 context.Value）：

• 给每个 RPC 方法定义重试策略常量，如 RetryPolicyNone / RetryPolicyIdempotent
• 拦截器读取该策略，仅对 RetryPolicyIdempotent 类型方法启用重试
• 服务端收到含 idempotency-key header 的请求，先查缓存/DB 是否已执行，避免重复落库

没有服务端配合的客户端重试，本质是空中楼阁。

熔断器应独立于重试逻辑部署

重试解决的是临时性故障（如网络抖动），熔断解决的是持续性故障（如下游服务宕机）。两者必须解耦，否则重试失败会快速触发熔断，导致本可恢复的节点被误判隔离。

推荐组合方案：github.com/sony/gobreaker + 独立指标采集：

• 熔断器只监听 codes.Unavailable 和 codes.DeadlineExceeded 的失败率（不包含重试中间态）
• 重试拦截器不感知熔断状态，但应在重试前检查 cb.Ready() == true，跳过已打开的熔断器
• 熔断窗口期（如 60 秒）内失败率 > 50% 且失败数 ≥ 5 次才触发 OPEN 状态

最容易被忽略的是：熔断器的状态变更需要跨 goroutine 同步 —— 如果多个 RPC 共享同一个 gobreaker.CircuitBreaker 实例，必须确保其内部状态更新是线程安全的（该库已实现，但自研时极易出错）。