2. gRPC核心原理：Protocol Buffers序列化机制、HTTP/2多路复用、流式通信模型

gRPC 的高性能与跨语言能力，根植于其三大核心支柱：Protocol Buffers 序列化机制、HTTP/2 多路复用以及流式通信模型。理解这三者如何协同工作，是掌握 gRPC 架构演进与后续限流熔断优化的基础。

2.1 Protocol Buffers 序列化机制

Protocol Buffers（简称 Protobuf）是 gRPC 的接口定义语言（IDL）与数据序列化协议。相比 JSON/XML，它在序列化速度、数据体积和类型安全上具有显著优势。

2.1.1 核心编码原理：T-L-V 结构

Protobuf 采用 Tag-Length-Value (T-L-V) 的二进制编码格式。每个字段由 Tag（字段编号 + 类型）、Length（仅变长类型）和 Value（实际数据）组成。

2.1.2 Varint 与 ZigZag 编码

• Varint（变长整数）：每个字节的最高位（MSB）作为结束标志，剩余7位存储数据。小整数（如 0-127）仅占1字节，大整数则占用更多字节。
• ZigZag 编码：针对有符号整数，将负数映射为正数后再进行 Varint 编码。例如 -1 映射为 1，1 映射为 2，避免负数在 Varint 中占用大量字节。

// 示例：int32 类型字段编号1，值150的二进制编码
// Tag: 0x08 (0000 1000)
// Value: 0x96 0x01 (1001 0110 0000 0001)
// 解码过程：去掉MSB -> 001 0110 000 0001 -> 拼接 -> 10010110 -> 150

2.1.3 字段类型与 wire_type 映射

2.2 HTTP/2 多路复用

gRPC 选择 HTTP/2 作为传输层，核心原因是其 多路复用 能力。HTTP/2 允许在单个 TCP 连接上并发处理多个请求-响应流，彻底解决了 HTTP/1.x 的队头阻塞问题。

2.2.1 流、帧与多路复用

• 流 (Stream)：一个独立的双向数据交换单元，每个流由唯一的 Stream ID 标识。
• 帧 (Frame)：HTTP/2 的最小通信单位，包含 HEADERS、DATA、SETTINGS、GOAWAY 等类型。
• 多路复用：多个流可以交错发送帧，接收方根据 Stream ID 重组数据，实现并行传输。

2.2.2 gRPC 与 HTTP/2 帧映射

2.2.3 流式通信模型

基于 HTTP/2 的流式能力，gRPC 定义了四种通信模式，满足不同场景需求。

1. 一元 RPC (Unary RPC)：客户端发送一个请求，服务端返回一个响应。最常用的模式，类似传统 HTTP API。
2. 服务端流式 RPC (Server Streaming RPC)：客户端发送一个请求，服务端返回多个响应消息。适用于订阅、日志推送等场景。
3. 客户端流式 RPC (Client Streaming RPC)：客户端发送多个请求消息，服务端返回一个响应。适用于批量上传、数据聚合等场景。
4. 双向流式 RPC (Bidirectional Streaming RPC)：客户端和服务端可以独立发送多个消息，顺序由应用层保证。适用于实时聊天、协同编辑等场景。

// 双向流式 RPC 的 Protobuf 定义示例
service ChatService {
  rpc Chat(stream ChatMessage) returns (stream ChatMessage);
}

message ChatMessage {
  string user_id = 1;
  string content = 2;
  int64 timestamp = 3;
}

2.3 核心原理综合架构图

下图展示了 gRPC 从客户端到服务端的完整调用链路，以及 Protobuf、HTTP/2 多路复用和流式通信的协同关系。

2.4 核心原理对比总结