📚 课程目录第2章 gRPC基础回顾

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

在深入服务端流与尾延迟压测之前，必须牢固掌握 gRPC 的两大基石：Protocol Buffers（protobuf） 接口定义语言，以及 四种通信模式 的语义与适用场景。本节将系统梳理这些基础概念，为后续章节的压测设计与安全合规分析建立共同语言。

2.1 Protocol Buffers：接口定义语言（IDL）

gRPC 默认使用 Protocol Buffers 作为接口定义语言（IDL）和序列化协议。一个典型的 .proto 文件包含 消息类型（message） 和 服务定义（service） 两部分。

  核心要点：protobuf 通过 syntax 声明版本（proto3 为当前主流），使用 message 定义结构化数据，使用 service 定义 RPC 方法签名。字段编号（field number）是二进制编码的关键，一旦发布不应修改。

2.1.1 消息定义示例

syntax = "proto3";

package performance.practice;

// 请求消息：包含用户标识和查询参数
message UserQueryRequest {
  string user_id = 1;
  int32 page_size = 2;
  string query_token = 3;
}

// 响应消息：包含用户信息和时间戳
message UserDetailResponse {
  string user_id = 1;
  string user_name = 2;
  string email = 3;
  int64 last_login_timestamp = 4;
  map<string, string> attributes = 5;
}

2.1.2 服务定义与 RPC 方法签名

service UserService {
  // 一元 RPC
  rpc GetUser(UserQueryRequest) returns (UserDetailResponse);

  // 服务端流式 RPC
  rpc ListUsers(UserQueryRequest) returns (stream UserDetailResponse);

  // 客户端流式 RPC
  rpc BatchCreateUser(stream UserQueryRequest) returns (UserDetailResponse);

  // 双向流式 RPC
  rpc Chat(stream UserQueryRequest) returns (stream UserDetailResponse);
}

元素	说明	版本要求
`syntax`	声明 protobuf 版本，proto3 移除了 required/optional，默认所有字段 optional	proto3
`package`	防止命名冲突，生成代码时对应 Java package 或 C# namespace	proto3 / proto2
`message`	定义结构化数据，字段类型支持标量、枚举、嵌套 message、map、oneof	proto3 / proto2
`service`	定义 RPC 服务接口，包含一个或多个 rpc 方法	proto3 / proto2
`rpc`	声明远程调用方法签名，通过 `stream` 关键字标识流式模式	proto3 / proto2

2.2 gRPC 四种通信模式

gRPC 基于 HTTP/2 流式传输，支持四种通信模式。理解每种模式的 消息流方向 和 生命周期 是正确设计压测场景的前提。

压测视角提示：四种模式在连接复用、内存分配、背压处理上差异显著。服务端流和双向流在尾延迟压测中尤其需要关注服务端推送速率与客户端消费速率的匹配。

2.2.1 模式对比总览

模式	客户端请求	服务端响应	典型场景	压测关注点
Unary（一元）	1 条消息	1 条消息	简单的 CRUD、认证	请求/响应延迟、吞吐量
Server Streaming（服务端流）	1 条消息	多条消息（流）	日志推送、数据导出、实时订阅	首字节延迟、流完成时间、背压
Client Streaming（客户端流）	多条消息（流）	1 条消息	批量上传、文件分片上传	流写入速率、合并延迟
Bidirectional Streaming（双向流）	多条消息（流）	多条消息（流）	实时聊天、协同编辑、游戏同步	双向延迟、消息顺序、流控制

2.2.2 四种模式通信流程示意图

2.3 四种模式的详细语义与压测含义

2.3.1 Unary（一元 RPC）

最基础的 RPC 模式，客户端发送一个请求，服务端返回一个响应。语义上等同于传统 HTTP 请求-响应模型，但基于 HTTP/2 和 protobuf 序列化，性能更高。

生命周期：客户端发起调用 → 服务端接收请求 → 处理 → 返回响应 → 连接关闭。
压测指标：延迟（p50/p90/p99）、吞吐量（QPS）、错误率。
安全合规关注点：每个请求独立认证，适合携带短生命周期 token。

2.3.2 Server Streaming（服务端流 RPC）

客户端发送一个请求，服务端返回一个消息流（多条消息）。这是本课程 核心关注模式，因为服务端流在推送大量数据时，服务端的内存分配、GC 压力和客户端背压处理会直接影响尾延迟。

生命周期：客户端发起请求 → 服务端开始推送消息流 → 客户端逐条读取 → 服务端发送状态（trailer）→ 流结束。
压测指标：首字节延迟（TTFB）、流完成时间、消息间延迟（inter-message latency）、背压事件次数。
安全合规关注点：流持续期间认证上下文需保持有效；服务端需在流中定期校验客户端活性。

2.3.3 Client Streaming（客户端流 RPC）

客户端发送一个消息流，服务端在接收完所有消息后返回一个响应。适用于批量数据上传场景。

生命周期：客户端开始发送流 → 服务端持续接收 → 客户端关闭流 → 服务端处理并返回响应。
压测指标：流写入速率（msg/s）、合并处理延迟、服务端内存峰值。
安全合规关注点：流中每条消息是否需要单独签名？合规审计需记录流开始和结束事件。

2.3.4 Bidirectional Streaming（双向流 RPC）

客户端和服务端可以独立发送消息流，双方读写操作完全解耦。消息顺序由应用层保证，gRPC 不保证读写顺序的因果关系。

生命周期：双方同时或先后打开流 → 独立读写 → 任一方关闭流 → 另一方检测到关闭后也关闭。
压测指标：双向消息延迟、消息顺序正确性、流控制窗口耗尽频率。
安全合规关注点：双向流中身份认证应在流建立时完成；消息级加密需在应用层实现。

2.4 模式选择决策树

常见误区：不要将 Bidirectional Streaming 误认为“必须同时读写”。实际上，双向流的读写是独立的，服务端可以在收到客户端第一条消息之前就开始推送数据。压测时需明确区分“读写并发”与“读写交替”两种模式，否则延迟数据会失真。

2.5 本章小结

Protocol Buffers 是 gRPC 的 IDL 和序列化基础，service 定义 RPC 方法，message 定义数据结构。
四种通信模式在消息流方向、生命周期和压测指标上差异显著。
Server Streaming 是本课程压测重点，其首字节延迟和流完成时间是尾延迟分析的关键维度。
选择通信模式时，根据“客户端发送几条消息”和“服务端返回几条消息”两个维度即可快速决策。