gRPC 四种通信模式，各自的用武之地

gRPC 的四种模式不是四选一的口味题，是四种业务形态的对应。

一元 RPC，一问一答，最普通也最常用：查用户资料、读配置。三种流按方向各有场景。服务端流，一次请求服务端持续推回：报表导出百万行边生成边推，客户端内存平稳；订阅式推送（价格变动、进度更新）。客户端流，客户端持续发服务端汇总回一个：埋点批量上报，攒批或定时返回确认。双向流，两边随时写：实时协作、聊天、语音转写，连接复用下低延迟交互。

service Report {
  // 一元：小查询
  rpc GetSummary(DateRange) returns (Summary);
  // 服务端流：大结果分批推
  rpc StreamRows(Query) returns (stream Row);
  // 客户端流：埋点批量上报
  rpc UploadEvents(stream Event) returns (UploadAck);
  // 双向流：交互式会话
  rpc Chat(stream ChatMsg) returns (stream ChatMsg);
}

工程要点比模式本身值钱。一元调用的 deadline 会自动覆盖整条链路，流没有内建超时——长时间空闲的流会被中间的 LB 断掉，要加应用层心跳和 idle 检测；流式消息要有序列号，断流重连后按序号续传，否则重连就是乱序；HTTP/2 多路复用让单连接跑大量并发调用，但同一条 TCP 上有队头阻塞的可能，网关和客户端的 max_concurrent_streams 要对齐。

我们内部服务间已把六成 REST 迁到 gRPC，剩下的是调试便利要求高的边缘接口。迁移的动力从来不是性能数字，是契约先行的 proto 文件让前后端并行开发顺了。