4. gRPC 基础回顾：Protocol Buffers 定义与四种通信模式

在深入排查 gRPC 接口故障之前，必须牢固掌握其底层通信契约与交互模型。gRPC 的核心由两部分构成：Protocol Buffers（protobuf） 作为接口定义语言（IDL）与序列化协议，以及基于 HTTP/2 的四种通信模式。本节将系统回顾这两大基础，为后续的故障定位提供理论支撑。

4.1 Protocol Buffers 定义与核心语法

Protocol Buffers 是 gRPC 的默认序列化框架，使用 .proto 文件定义服务接口和消息结构。其核心优势在于：二进制编码体积小、解析速度快、前后向兼容性强。

4.1.1 消息类型定义

一个典型的 protobuf 消息定义包含字段编号、字段类型和字段规则。字段编号（Field Number）是二进制编码的关键标识，1-15 号占用 1 字节，16-2047 号占用 2 字节，因此高频字段应分配小编号。

syntax = "proto3";

package cache.v1;

// 缓存条目消息
message CacheEntry {
  string key = 1;               // 缓存键
  bytes value = 2;              // 缓存值（二进制）
  int64 ttl_seconds = 3;        // 过期时间（秒）
  map<string, string> tags = 4; // 标签映射
}

// 批量查询请求
message BatchGetRequest {
  repeated string keys = 1;     // 键列表
  bool include_metadata = 2;    // 是否包含元数据
}

4.1.2 服务接口定义

服务定义使用 service 关键字，每个 RPC 方法需指定请求消息类型和响应消息类型。gRPC 根据方法签名自动推断通信模式。

service CacheService {
  // Unary：单次请求-响应
  rpc GetCache(CacheEntry) returns (CacheEntry);

  // Server Streaming：服务端流式推送
  rpc WatchCache(WatchRequest) returns (stream CacheEvent);

  // Client Streaming：客户端流式上传
  rpc BatchSet(stream CacheEntry) returns (BatchSetResponse);

  // Bidirectional Streaming：双向流式通信
  rpc SyncCache(stream SyncRequest) returns (stream SyncResponse);
}

4.2 gRPC 四种通信模式详解

gRPC 基于 HTTP/2 的流式帧（Stream Frame）实现了四种通信模式。理解每种模式的生命周期和背压（Backpressure）机制是排查超时、内存溢出、连接泄漏等故障的前提。

4.2.1 Unary RPC（一元模式）

客户端发送一个请求，服务端返回一个响应。这是最常用的模式，行为与传统的 HTTP REST 类似，但使用二进制协议和 HTTP/2 多路复用。

• 生命周期： 客户端发起连接 → 发送请求消息 → 服务端处理 → 返回响应 → 关闭流。
• 故障特征： 超时（DeadlineExceeded）、请求体过大（ResourceExhausted）、序列化失败（Internal）。
• 排查手段： 检查 gRPC 状态码、抓取 HTTP/2 帧（grpcurl -d）、对比 protobuf 序列化大小。

4.2.2 Server Streaming RPC（服务端流式）

客户端发送一个请求，服务端返回一个消息流。适用于订阅通知、日志推送、大数据集分页等场景。

• 生命周期： 客户端发起 → 服务端持续发送多个响应消息 → 服务端发送状态码并关闭流。
• 故障特征： 流中断（Unavailable）、消息乱序（DataLoss）、客户端消费慢导致服务端背压阻塞。
• 排查手段： 监控流式消息的 FlowControlWindow 大小、检查客户端 Recv() 调用是否阻塞。

4.2.3 Client Streaming RPC（客户端流式）

客户端发送一个消息流，服务端返回一个响应。适用于批量上传、日志聚合、大文件分片上传。

• 生命周期： 客户端发送多个请求消息 → 客户端关闭发送 → 服务端处理并返回单个响应。
• 故障特征： 客户端发送过快导致服务端 OOM、消息顺序依赖错误、服务端未收到 CloseSend 信号导致死等。
• 排查手段： 检查服务端 Recv() 循环退出条件、设置 MaxRecvMsgSize 限制。

4.2.4 Bidirectional Streaming RPC（双向流式）

客户端和服务端可以独立并发地发送消息流。适用于实时聊天、协同编辑、分布式同步。

• 生命周期： 双方独立读写，各自调用 Send() 和 Recv()，任意一方关闭发送后，对方读取完剩余消息后关闭流。
• 故障特征： 死锁（双方同时阻塞在 Send()）、消息顺序错乱、流关闭竞争条件。
• 排查手段： 使用 goroutine 分离读写协程、设置合理的 WriteDeadline 和 ReadDeadline。

4.3 四种通信模式对比与选型

4.4 gRPC 通信模式交互流程（SVG）

下图展示了四种通信模式在 HTTP/2 流上的交互时序，重点标注了 流生命周期 和 消息边界，帮助理解故障发生时数据帧的流向。

4.5 gRPC 故障排查关键指标

在后续章节的缓存穿透故障排查中，以下 gRPC 指标是必须监控的黄金信号：