AI 辅助：高性能 RPC 框架设计：延迟预算要从协议层开始
一、RPC 不是套一层 HTTP 就结束
高性能 RPC 框架要处理连接复用、序列化、压缩、超时、重试、负载均衡、背压和可观测性。业务看到的是一次函数调用，底层其实是一整套网络系统。如果协议层没有延迟预算，上层再怎么优化也会被排队、重试和拷贝吃掉。
设计 RPC 时，先确定目标：低延迟、强吞吐、跨语言、易调试，还是服务治理能力。不同目标会推导出不同协议和实现。
二、调用链路：每一段都消耗预算
flowchart LR A[客户端编码] --> B[连接池排队] B --> C[网络传输] C --> D[服务端解码] D --> E[业务处理] E --> F[响应编码]一次 P99 延迟不是业务处理时间，而是所有环节相加。连接池等待和队列拥塞经常被忽略，但它们会在高峰期放大。
三、代码示例：请求上下文携带 deadline
use std::time::{Duration, Instant}; struct RpcContext { request_id: String, deadline: Instant, } impl RpcContext { fn remaining(&self) -> Option<Duration> { self.deadline.checked_duration_since(Instant::now()) } }deadline 应传递到下游，而不是每一层重新设置固定超时。否则多级调用会把总超时放大，用户已经等不住，系统还在内部重试。
四、工程边界：重试必须配合幂等
RPC 重试很危险。读请求通常可以重试，写请求要看幂等键和业务语义。没有幂等保护的重试，可能造成重复扣款、重复创建任务或重复发送通知。框架可以提供机制，但不能替业务决定所有语义。
取舍方面，二进制协议性能好，但调试成本高；HTTP/JSON 易排查，但开销更大。内部高频调用可以使用紧凑协议，对外接口保留可读性。框架不要只追求极限性能，也要给排障留入口。
还要实现背压。当服务端排队超过阈值，客户端应该快速失败或降级，而不是继续堆请求。高性能系统最怕无限排队，因为它会把局部慢变成全局雪崩。
序列化格式也要按场景选择。Protobuf 生态成熟，FlatBuffers/Cap'n Proto 可减少拷贝，JSON 易排查但体积大。框架可以支持多编码，但默认路径必须稳定。每增加一种编码，就增加兼容测试和安全解析成本。
连接管理同样关键。长连接能降低握手开销，但要处理心跳、空闲回收、连接泄漏和负载迁移。客户端连接池要限制最大连接数和每连接并发数，否则高峰期会把服务端打成连接风暴。
最后，RPC 框架要把错误分类清楚。超时、拒绝、下游错误、协议错误、鉴权失败，不能都变成同一个异常。错误语义清楚，上层才能做正确降级。
可观测性要内置在框架里。每次调用的 request_id、目标服务、重试次数、排队时间、编码耗时、网络耗时和服务端处理耗时，都应该能进入 tracing。否则框架越高性能，排障时越像黑盒。
安全也要考虑。内部 RPC 不能默认可信，至少要有身份认证、权限边界和消息大小限制。高性能解析器如果不限制输入，很容易被异常大包拖垮。
版本兼容也要提前设计。字段新增、枚举扩展、协议升级，都不能让新旧服务互相读不懂。RPC 框架越底层，兼容错误影响越大。发布时最好支持双读或灰度协议，确认无误后再移除旧字段。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
五、总结
高性能 RPC 框架设计要从延迟预算、deadline 传递、幂等重试和背压开始。协议和实现都要服务稳定性，而不是只追求单次 benchmark 数字。
