gRPC 基础回顾：协议原理、HTTP/2 多路复用与 Protobuf 序列化

在深入诊断 gRPC 调用异常与 GC 停顿的关联之前，必须牢固掌握 gRPC 的核心技术栈。gRPC 并非简单的 RPC 框架，它基于 HTTP/2 协议传输，使用 Protocol Buffers (Protobuf) 作为接口定义语言和序列化工具。这三者的协同工作方式，直接决定了调用延迟、资源消耗以及 GC 压力的特征。

2.1 gRPC 协议原理与调用模型

gRPC 采用 客户端-服务端 模型，通过 Stub 屏蔽网络细节。一次典型的 gRPC 调用包含以下阶段：

1. 定义服务：在 .proto 文件中声明 RPC 方法签名和消息结构。
2. 生成桩代码：使用 protoc 编译器生成客户端 Stub 和服务端骨架。
3. 建立 HTTP/2 连接：客户端与服务端通过 TLS 协商建立一条 TCP 连接。
4. 发送请求：客户端将 Protobuf 序列化的请求数据封装在 HTTP/2 的 DATA 帧中，通过 HEADERS 帧携带元数据。
5. 服务端处理：服务端反序列化请求，执行业务逻辑，序列化响应。
6. 接收响应：客户端反序列化响应，完成一次 RPC。

2.2 HTTP/2 多路复用机制

HTTP/2 是 gRPC 的传输基石，其核心优势在于 多路复用。与 HTTP/1.1 的串行请求-响应模型不同，HTTP/2 允许在 单一 TCP 连接 上并发处理多个请求和响应。

在 gRPC 中，每个 RPC 调用对应 HTTP/2 的一个 流 (Stream)。多个流在同一个 TCP 连接上交错传输，帧级别的调度由 HTTP/2 层完成。这种机制极大地减少了连接建立的开销，但也带来了新的挑战：

• 流控压力：所有流共享连接带宽，一个慢消费者可能阻塞其他流。
• 内存占用：每个流需要维护状态和缓冲区，大量并发流会增加堆内存压力，间接触发 GC。
• GC 停顿放大：当 JVM 发生 Stop-The-World GC 时，所有流的数据处理都会暂停，导致批量超时和重试风暴。

2.3 Protobuf 序列化机制

Protocol Buffers 是 gRPC 的默认序列化方案，其性能直接影响 RPC 延迟和 GC 行为。Protobuf 采用 二进制编码，使用 Varint、ZigZag 和 固定长度 等编码方式，相比 JSON/XML 具有以下优势：

• 体积小：编码后数据量通常比 JSON 小 3-10 倍，减少网络传输和内存占用。
• 解析快：无需字符串解析，直接按 Schema 映射到内存结构。
• 强类型：编译期生成代码，避免运行时类型反射开销。

以下是一个典型的 Protobuf 消息定义与序列化示例：

// user.proto
syntax = "proto3";

message UserRequest {
  int64 user_id = 1;
  string name = 2;
  repeated string tags = 3;
}

message UserResponse {
  int64 user_id = 1;
  string display_name = 2;
  int32 age = 3;
  bool is_active = 4;
}

序列化时，Protobuf 将每个字段编码为 Tag-Value 对。Tag 包含字段编号和 Wire Type，Value 根据类型采用不同编码。例如 int64 使用 Varint 编码，string 使用长度前缀编码。

2.4 三者协同与 GC 关联

理解 gRPC、HTTP/2 和 Protobuf 的协同关系，是诊断 GC 停顿导致调用异常的前提：