备案站点的 gRPC 与内部 RPC 通信运维

一条请求超时，五个服务却各自以为还有时间

服务间调用从 HTTP 短连接迁移到 gRPC 这类基于长连接、支持多路复用的 RPC 协议后，性能和吞吐通常有明显提升，但也带来了一批新的运维细节——这些细节在传统短连接模型下根本不存在，是长连接、流式接口、以及协议本身的语义带来的新问题。最典型的一个：一条请求链路上经过五个服务，如果每个服务都各自独立设置超时时间而不是把"还剩多少时间"传递下去，前面的服务已经判定超时放弃了，后面的服务却毫不知情，继续傻乎乎地跑到自己的超时时间才结束，白白浪费资源。

关键要点

• 连接复用带来吞吐提升的同时，也让传统"一个连接一个请求"的负载均衡假设失效，需要专门处理。
• 截止时间（deadline）要沿着调用链逐跳传递并递减，而不是每一跳各自独立设置。
• 流式接口天然存在背压问题：生产者和消费者速度不匹配时，处理不当会导致内存暴涨或数据丢失。
• 协议演进要遵守清晰的兼容规则，接口定义变更的破坏性和普通 REST 接口是同一类问题，但表现形式不同。

连接复用打破了传统负载均衡的假设

基于 HTTP/2 的 RPC 协议在一条 TCP 连接上并发处理多个请求（多路复用），这带来的好处是省去了反复建连的开销，但也带来一个反直觉的后果：传统"每个请求各自建连、负载均衡器按请求维度分发"的模型不再适用——因为客户端一旦和某个服务实例建立了连接，后续请求会持续走这条连接，负载均衡实际上发生在连接建立的那一刻，而不是每个请求。

这个特性在客户端数量少、服务端实例数量多的场景下容易暴露问题：少数几个客户端各自固定连接到少数几个服务端实例，即使服务端整体健康，流量也可能严重不均衡——一部分实例被压满，另一部分几乎空闲。常见的缓解方式：

• 客户端侧做连接级别的负载均衡，主动维护到多个后端实例的连接池并轮询使用，而不是依赖一条长期存活的单一连接。
• 服务端定期主动断开空闲过久的连接，强制客户端重新建连触发一次新的负载均衡决策。
• 配合服务发现动态感知实例变化，见 服务发现与注册中心运维，避免负载均衡决策基于过期的实例列表。

截止时间：要传递，不要各自设置

这是 RPC 调用链路里最容易被忽视、也是最值得投入的一项治理。如果调用链上每一跳都独立设置自己的超时，会出现前面已经放弃、后面还在傻等的资源浪费，最坏情况下，一条早已没有意义的请求会一路消耗到链路末端才被真正终止，期间占用的连接、线程、CPU 全部是无用功。

正确做法是让截止时间随着调用逐跳传递并递减：入口服务设定一个总体截止时间（比如"这次调用最多允许 3 秒"），这个截止时间要作为上下文的一部分传给下游，下游服务据此计算自己实际还剩多少可用时间，再据此设置对更下游的调用超时，而不是各跳凭空设置一个固定值。这样一旦调用链的某一环已经超出预算，后续所有环节都能立刻感知并放弃，而不是继续空转。这个思路和普通服务的超时预算规划是同一个原则，只是在 RPC 场景下协议原生支持截止时间的传递，具体的超时预算拆分方法见 超时设置与重试策略。

流式接口的背压：生产者和消费者的速度差

RPC 协议通常原生支持流式接口——一次调用可以持续发送或接收多条消息，而不是传统的一问一答。流式接口带来了效率优势，但也引入了背压问题：如果生产者发送消息的速度持续快于消费者处理的速度，未处理的消息会在某处持续堆积。

处理方式	行为	代价
无限缓冲	消息全部先存起来	内存持续增长，极端情况下 OOM，见 内存泄漏与 OOM 排查
直接丢弃	处理不过来就丢新消息	数据丢失，适合能容忍丢失的场景（如高频指标采样）
主动降速	通知生产者放慢发送速率	需要协议双方配合，实现复杂度更高但最稳妥

流式接口的背压处理必须在设计阶段就明确选择，而不是等生产环境出现内存暴涨才意识到消费者一直在被压垮。主流 RPC 协议通常提供基于窗口的流控机制，合理利用这类机制比自己在应用层维护一个无限增长的缓冲队列要稳妥得多。

错误处理：状态码语义要统一

RPC 框架通常定义了一套标准状态码（类似"资源不存在""参数不合法""服务不可用"这类语义化分类），但实际使用中经常出现滥用少数几个通用状态码表达所有错误的情况——所有业务异常都返回"内部错误"，调用方完全无法区分是应该重试还是应该放弃。

治理要点：

• 区分"可重试"和"不可重试"的错误，让调用方能据此决定重试策略，重试的具体做法见 超时设置与重试策略。
• 业务语义错误用业务错误码或错误详情字段承载，不要把"用户余额不足"这类业务信息硬塞进协议层的通用错误里。
• 错误处理逻辑要在团队内部统一约定，避免不同服务对同一类状态码有不同解读，这类不一致会在跨服务排查故障时制造大量困惑。

协议演进：接口定义变更的兼容边界

RPC 接口通常通过独立的接口定义文件描述，多个服务共享同一份定义。这类接口的兼容性规则和普通 REST 接口的原则相通，但因为接口定义是结构化的（字段带编号、带类型），具体的破坏性变更判定更明确：

• 新增字段：只要使用新的字段编号，通常是安全的，旧客户端会忽略未知字段。
• 删除或重用字段编号：非常危险，旧数据里编号对应的语义会被新字段错误解读，这类变更必须永久保留编号占位，不能复用。
• 修改字段类型：即使两种类型在某些语言里能兼容表示，序列化格式的变化也可能导致跨版本解析出错。

这套加法优先、编号只增不删的原则，和普通 API 的兼容演进思路完全一致，只是落地机制不同，通用的兼容演进策略见 接口版本管理与兼容性治理。接口定义文件本身要纳入版本控制和评审流程，因为它同时被多个服务依赖，一次不兼容的变更影响的不是一个服务，而是整条依赖链。

常见坑

• 每一跳独立设置超时，不传递截止时间：链路前段已经放弃，后段还在空转浪费资源。
• 流式接口不处理背压，默认无限缓冲：消费者一旦跟不上，内存持续增长直至耗尽。
• 所有错误都用同一个通用状态码：调用方无法区分该重试还是该放弃。
• 接口定义变更时复用了已废弃字段的编号：新旧版本对同一个编号的语义解读完全不同，数据被错误解析。
• 连接复用后负载均衡失衡没有被监控发现：少数实例长期过载，另一些长期空闲，问题隐藏在"整体健康"的假象之下。

常见问题

RPC 协议和普通 REST 接口应该怎么选？

内部服务间调用、对性能和强类型接口定义有明确诉求时，RPC 协议通常更合适；面向外部、需要良好的通用工具兼容性（浏览器、第三方调用方）时，REST 更省心。多数系统会两者并用：对外用 REST 或走网关统一转换，服务内部用 RPC。

截止时间传递需要每个服务都手动实现吗？

多数主流 RPC 框架原生支持截止时间的自动传递，只要调用链上所有服务都使用同一套框架的标准调用方式，无需手动编写传递逻辑。真正需要关注的是确保每个服务都正确读取了传入的截止时间去计算自己的可用预算，而不是忽略它另起一个固定超时。

流式接口一定比一问一答的调用方式更高效吗？

不一定。流式接口在需要持续传输大量数据或实时性要求高的场景下有优势，但也带来了背压、连接长期占用等额外的运维复杂度。请求量不大、数据量不大的场景，一问一答的调用方式实现简单、故障排查也更直观，没必要为了"用了流式接口显得更先进"而增加不必要的复杂度。

接口定义文件应该放在哪个仓库管理？

如果被多个服务共享，通常建议独立出一个专门的仓库或制品，各服务通过依赖引用而不是各自复制一份，避免版本不一致导致的兼容性问题。变更流程上要当作影响多个下游的公共资源来对待，见 接口版本管理与兼容性治理 中关于下线与变更公告的思路同样适用。

资料来源

主流 RPC 框架（如 gRPC）的公开协议文档，关于连接复用、流控与截止时间传递机制的官方说明，以及分布式系统中错误处理与接口演进的通用工程实践。本文为通用运维说明，仅供参考，具体方案请结合团队技术栈与调用规模设计。