gRPC

传输与编码上，gRPC 跑在 HTTP/2 之上，用 protobuf 二进制序列化，报文体积常比 JSON 小数倍、编解码零反射更快；HTTP/2 多路复用让长连接上并发大量调用无队头阻塞，并原生支持双向流。接口契约上，proto 文件即 IDL，代码生成强类型客户端与服务端，跨语言一致性好，契约即文档。REST 优势在人可读、浏览器与 CDN、网关、调试工具生态全，学习成本低，对外公开 API 与第三方集成仍是首选。gRPC 局限：浏览器不能直连，需 grpc-web 加代理；防火墙与中间件对 HTTP/2 支持参差；抓包调试成本高。选型结论：内部微服务间高吞吐低延迟通信用 gRPC，对外开放平台与资源型接口用 REST，两者可并存（grpc-gateway 一份 proto 同时生成两种接口）。

protobuf 用 TLV 思想的二进制格式：每个字段写成 tag（字段号加线型）加 value，字段名不上线只传编号；varint 变长整数让小数值只占一两个字节；负数经 zigzag 映射（0 与 -1 交替）避免 int32 负数占满十字节；嵌套消息递归内嵌，字符串与字节直接原样存储。反序列化按 .proto 描述文件把编号映射回字段，顺序访问一次解码，无反射与文本解析。空间上通常比 JSON 小三到十倍，编解码速度快一个量级，且向前向后兼容：新增字段旧代码跳过未知 tag（unknown fields 保留），字段号不复用即可安全演进，注意 required 已废弃、不要改动已有字段编号与类型。代价是人类不可读与自描述性弱，调试依赖工具。答出 varint、zigzag、字段号三点即达标。

proto 里 rpc 定义四种模式。一元调用 unary：一请求一响应，最常用，等同普通 RPC；客户端流 client streaming：客户端发多帧请求、服务端回一个响应，典型是上传分块、批量写入与聚合上报，服务端可边收边处理提前失败；服务端流 server streaming：一请求、服务端持续推送多帧直至结束，适合订阅推送、大结果分批下发与长任务进度；双向流 bidi streaming：两边都可随时收发，读写在各自协程独立进行，适合聊天、实时协同、双向心跳与代理隧道。流的实现依托 HTTP/2 的 stream id，多路复用单连接并发；流上也可发 metadata 与截断错误。注意点：流没有内建重试语义，背压要靠流量控制窗口与客户端限速，结束要正确 sendClose 与回收。能各举一个业务例子即完整。

gRPC 客户端的 Channel 对应一条 HTTP/2 连接，天然多路复用：所有调用共享连接，以 stream id 区分，不需要按并发建连接池，单 channel 通常足够（超高并发可建少量 channel 分散负载）。连接管理上，gRPC 内建按名称解析（DNS 或自定义 resolver）与负载均衡（默认 pick-first，可换 round_robin），地址变化自动重连与重平衡；keepalive 通过 HTTP/2 PING 帧探活防止中间设备静默掐断长连接，需配置 keepalive time 与 permit keepalive，服务端对过于频繁的 PING 有 GOAWAY 保护。调用级配置走 client 加 With 的拦截器与 per-RPC context；超时用 context deadline 并配合重试策略（重试与 hedging 对幂等方法）。能对比 HTTP/1.1 连接池解释为何免池化即佳。

错误用标准 status 模型：状态码（如 NotFound、InvalidArgument、Unavailable、DeadlineExceeded、ResourceExhausted）加 message 加详情，跨语言映射到 HTTP/2 的 trailers；自定义错误负载放错误详情（error_details）。超时与取消是面试重点：deadline 附着在请求 metadata 里随调用链自动传播，上游 100 毫秒的预算传到下游只剩剩余量，下游续用同一 deadline，超时或客户端取消时 context 级联取消整条链路，避免无效计算浪费资源。因此每个下游调用都应透传 context 而不是新建。重试策略：仅对幂等一元方法与 Unavailable 等可重试码配置重试或对冲请求，配退避与令牌限流；应用层错误不要滥用 Internal，业务校验失败用 InvalidArgument 语义更准。能讲 deadline 传播链路一个例子即优秀。