如何提升Golang RPC响应速度_使用压缩和流式传输

关键在减少网络传输量和避免阻塞等待：启用gzip压缩大消息体，改用流式传输替代单次响应，结合protobuf序列化与HTTP/2多路复用，可降延迟30%–70%。

提升 Go RPC 响应速度，关键不在重写框架，而在减少网络传输量和避免阻塞等待——压缩和流式传输是两个最直接有效的手段。

启用消息体压缩（如 gzip）

RPC 请求/响应体较大时（比如返回结构体含 JSON 字段、日志列表、批量数据），未压缩的字节流会显著拖慢网络耗时。Go 的 net/rpc 本身不支持压缩，但可通过包装底层连接实现。

• 在客户端 dial 后、服务端 accept 后，用 gzip.NewReader / gzip.NewWriter 包裹 conn 的读写器
• 约定请求头或第一个字节标识是否启用压缩（例如前 4 字节为 0x1f8b 表示 gzip 流）
• 注意：小消息（2KB 才压缩）

改用流式接口替代单次响应

当业务需要返回大量数据（如导出百万行记录、实时日志推送），传统 RPC “请求-等待-返回完整结果” 模式会造成内存暴涨和长延迟。改用流式可边生成边发送。

• 推荐使用 gRPC（原生支持 streaming），定义 rpc StreamData(Request) returns (stream Response);
• 若坚持标准 net/rpc，可手动实现“连接复用 + 分块推送”：服务端持续 write，客户端 goroutine 持续 read + decode
• 记得设好 conn.SetWriteDeadline 和心跳机制，防止流挂死

配合其他轻量优化

压缩和流式是主力，但需搭配基础调优才能发挥最大效果：

• 序列化尽量用 protobuf 替代 JSON（体积小、解析快）
• 禁用 HTTP/1.1 的 Keep-Alive 复用开销，gRPC 默认走 HTTP/2 多路复用更高效
• 服务端避免在 RPC handler 中做同步 IO 或复杂计算，该异步的异步，该缓存的缓存

基本上就这些。压缩解决“传得多”，流式解决“等得久”，两者结合，多数场景下 RPC 延迟能降 30%–70%。