Go RPC需手动实现容错：区分客户端错误（不重试）、临时性服务端错误（指数退避重试2–3次）、确定性服务端错误（不重试）；强制超时、上下文传播、降级策略及可观测性埋点。
Go 的 RPC 框架（如 net/rpc 或 gRPC）本身不自动重试或兜底，错误处理需由开发者主动设计。要保证请求稳定执行，核心是：区分错误类型、合理重试、设置超时、提供降级路径、记录可观测性数据。
明确 RPC 错误分类，针对性处理
不是所有错误都该重试。常见错误可归为三类：
- 客户端错误：参数校验失败、序列化失败、URL/服务地址错误——这类错误不可重试，应立即返回并修正调用逻辑
-
临时性服务端错误：连接拒绝、超时、服务端繁忙（如 HTTP 503、gRPC
UNAVAILABLE）、网络抖动——适合有限重试 -
确定性服务端错误：业务逻辑拒绝（如 HTTP 400/401/404、gRPC
INVALID_ARGUMENT、NOT_FOUND、PERMISSION_DENIED）——不应重试，需透传给上游或做业务适配
实现带策略的重试机制
使用 github.com/cenkalti/backoff/v4 等库封装指数退避重试，避免雪崩。关键点：
- 仅对临时性错误（如
context.DeadlineExceeded、net.OpError、gRPCCode() == codes.Unavailable）触发重试 - 设置最大重试次数（建议 2–3 次）和总超时上限（如 5s），防止长尾累积
- 每次重试前重置 context（新建带新 deadline 的 context），避免继承已超时的上下文
- 示例片段（gRPC 场景）：
func (c *client) CallWithRetry(ctx context.Context, req *pb.Request) (*pb.Response, error) {
var resp *pb.Response
err := backoff.Retry(func() error {
// 每次重试创建新 context，带独立 timeout
retryCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
defer cancel()
r, err := c.client.DoSomething(retryCtx, req)
if err != nil {
st, ok := status.FromError(err)
if ok && (st.Code() == codes.Unavailable || st.Code() == codes.DeadlineExceeded) {
return err // 触发重试
}
return backoff.Permanent(err) // 终止重试
}
resp = r
return nil
}, backoff.WithContext(backoff.NewExponentialBackOff(), ctx))
return resp, err
}
强制超时 + 上下文传播，防阻塞
所有 RPC 调用必须绑定带 deadline 的 context，且服务端也要尊重该 deadline：
立即学习“go语言免费学习笔记（深入）”；
- 客户端：调用前用
context.WithTimeout或context.WithDeadline包裹 - 服务端（gRPC）：在 handler 中检查
ctx.Err()，及时中止耗时操作（如 DB 查询、文件读写） - 避免在 RPC 调用中使用无超时的
time.Sleep、死循环或未设 timeout 的 HTTP client
定义降级逻辑与可观测性埋点
当重试失败或错误不可恢复时，启用降级保障基本可用：
- 返回缓存数据（需注意一致性）、默认值、空响应，或切换备用服务地址
- 记录结构化日志：包含 method、reqID、错误码、重试次数、耗时、是否降级
- 上报 metrics（如
rpc_errors_total{type="unavailable",retried="true"}），便于监控告警 - 关键链路添加 trace span（如使用 OpenTelemetry），定位失败环节
