2. gRPC 核心概念回顾：Protocol Buffers、Service Definition、Unary/Server Streaming/Client Streaming/Bidirectional Streaming

在进入压测架构设计之前，必须重新校准 gRPC 的核心契约。gRPC 的通信模型、序列化协议和服务定义方式，直接决定了压测工具的构造策略。本章从三个维度展开：Protocol Buffers 的序列化契约、Service Definition 的接口契约、以及四种流式通信模式。理解这些概念，是后续设计压测数据生成器、连接池管理和流量控制器的前提。

2.1 Protocol Buffers：契约的序列化基石

Protocol Buffers（protobuf）是 gRPC 的默认序列化协议，它通过 .proto 文件定义结构化数据的编码规则。与 JSON 相比，protobuf 的二进制编码体积更小、解析速度更快，但代价是必须预先定义 schema，且调试时需借助工具反序列化。

特性 Protocol Buffers JSON
编码格式 二进制（varint + 定长） 文本（UTF-8）
Schema 要求 必须预定义 .proto 文件 可选（动态类型）
序列化速度 快（无反射解析） 慢（字符串解析）
数据体积 小（压缩字段编号） 大（字段名冗余）
向后兼容 支持（字段编号 + 可选/必选） 需手动处理
调试友好度 低（需 protoc 解码） 高（可读文本）

在压测场景中，protobuf 的二进制特性带来两个关键影响：

  • Payload 构造必须精确匹配字段编号和类型，否则服务端反序列化会失败或产生错误数据。
  • 压测工具需要内置 protobuf 编译能力，或通过反射动态生成消息，否则无法构造合法请求。
压测实践提示： 在 Go 项目中，使用 proto.Marshal() 和 proto.Unmarshal() 时，务必确保生成的 Go 结构体与 .proto 文件完全同步。建议在 CI 流程中加入 protoc 编译检查，防止字段编号偏移导致压测数据无效。

2.2 Service Definition：接口契约的声明式定义

gRPC 的服务定义（Service Definition）通过 .proto 文件中的 service 关键字声明 RPC 方法。每个方法必须指定输入消息类型和输出消息类型，并标注通信模式。以下是一个典型的服务定义示例：

syntax = "proto3";

package order.v1;

// 订单服务契约
service OrderService {
  // 创建订单（Unary）
  rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse);

  // 批量查询订单（Server Streaming）
  rpc ListOrders(ListOrdersRequest) returns (stream Order);

  // 批量上传订单（Client Streaming）
  rpc BatchCreateOrders(stream CreateOrderRequest) returns (BatchCreateOrdersResponse);

  // 实时订单状态推送（Bidirectional Streaming）
  rpc WatchOrderStatus(stream OrderStatusRequest) returns (stream OrderStatusResponse);
}

message CreateOrderRequest {
  string user_id = 1;
  repeated string item_ids = 2;
  double total_amount = 3;
}

message CreateOrderResponse {
  string order_id = 1;
  int64 created_at = 2;
}

message ListOrdersRequest {
  string user_id = 1;
  int32 page_size = 2;
  int32 page_token = 3;
}

message Order {
  string order_id = 1;
  string status = 2;
  double amount = 3;
}

message BatchCreateOrdersResponse {
  int32 success_count = 1;
  repeated string failed_order_ids = 2;
}

message OrderStatusRequest {
  string order_id = 1;
}

message OrderStatusResponse {
  string order_id = 1;
  string new_status = 2;
  int64 timestamp = 3;
}

服务定义中的 stream 关键字是区分四种通信模式的核心标记。压测工具必须根据 stream 的位置，决定请求/响应的发送和接收策略。

2.3 四种通信模式：Unary / Server Streaming / Client Streaming / Bidirectional Streaming

gRPC 的四种通信模式决定了客户端与服务端之间的数据交换方式。每种模式在压测中对应不同的连接管理、并发模型和流量控制策略。

gRPC 四种通信模式对比 Unary（一元） 客户端发送 1 个请求 服务端返回 1 个响应 典型场景：CRUD Server Streaming 客户端发送 1 个请求 服务端返回 N 个响应 典型场景：列表查询 Client Streaming 客户端发送 N 个请求 服务端返回 1 个响应 典型场景：批量上传 Bidirectional Streaming 客户端发送 N 个请求 服务端返回 N 个响应 典型场景：实时推送 四种模式压测关注点对比 维度 Unary Server Streaming Client Streaming Bidirectional Streaming 连接复用 高（短连接） 中（长连接） 中（长连接） 低（长连接） 并发模型 goroutine 池 goroutine + channel goroutine + channel goroutine + select 流量控制 无 服务端流控 客户端流控 双向流控 核心指标 QPS / 延迟 吞吐量 / 背压 吞吐量 / 背压 吞吐量 / 延迟 错误处理 简单重试 流中断重连 流中断重连 流中断重连

2.4 四种模式的压测策略差异

在压测工具设计中，四种通信模式对连接管理、并发模型和流量控制的要求截然不同。以下从压测架构角度拆解每种模式的核心关注点：

2.4.1 Unary（一元模式）

  • 连接复用：每个请求独立使用一个 gRPC 调用，HTTP/2 连接可被多个请求复用。
  • 并发模型：使用 goroutine 池 + 请求队列，每个 goroutine 负责发送一个请求并等待响应。
  • 压测指标：QPS（每秒请求数）、P50/P99 延迟、错误率。
  • 典型实现：client.CreateOrder(ctx, req)，同步阻塞调用。

2.4.2 Server Streaming（服务端流模式）

  • 连接复用：一个请求建立一条流，服务端持续推送多个响应。
  • 并发模型：每个流启动一个 goroutine 接收响应，使用 channel 传递数据。
  • 压测指标：吞吐量（每秒接收的消息数）、背压表现（服务端流控是否生效）。
  • 典型实现：stream, _ := client.ListOrders(ctx, req)，循环调用 stream.Recv()。

2.4.3 Client Streaming（客户端流模式）

  • 连接复用：一个请求建立一条流，客户端持续发送多个请求。
  • 并发模型：每个流启动一个 goroutine 发送请求，使用 channel 控制发送速率。
  • 压测指标：吞吐量（每秒发送的消息数）、客户端流控是否触发服务端背压。
  • 典型实现：stream, _ := client.BatchCreateOrders(ctx)，循环调用 stream.Send(req)，最后 stream.CloseAndRecv()。

2.4.4 Bidirectional Streaming（双向流模式）

  • 连接复用：一条流同时承载双向消息，发送和接收独立进行。
  • 并发模型：使用两个 goroutine（一个发送、一个接收），通过 select 或 channel 协调。
  • 压测指标：吞吐量（双向消息速率）、延迟（消息往返时间）、流控效果。
  • 典型实现：stream, _ := client.WatchOrderStatus(ctx)，启动发送 goroutine 和接收 goroutine，使用 select 处理超时和取消。
压测陷阱提醒： 在双向流压测中，如果发送速率超过服务端处理能力，且未正确实现流控（如未设置 grpc.MaxRecvMsgSize 或未处理 io.EOF），会导致内存溢出或连接重置。建议在压测脚本中显式设置 grpc.WithBlock() 和 grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(4*1024*1024))。

2.5 从契约到压测：关键映射关系

压测工具需要将 .proto 文件中的契约定义映射为可执行的压测逻辑。以下表格总结了契约元素与压测组件的对应关系：

.proto 契约元素 压测组件 说明
message 数据生成器 根据字段类型和编号构造随机或模板化的 protobuf 消息
rpc 方法名 压测任务定义 每个 RPC 方法对应一个压测场景，包含请求构造、发送、接收和断言
stream 关键字 流控制器 决定使用 Recv/Send 循环、goroutine 数量、channel 缓冲大小
service 名称 连接管理器 每个 service 对应一个 gRPC 客户端连接池，管理 HTTP/2 连接复用
package 命名空间隔离 多 proto 包共存时，压测工具需按包名隔离注册中心

2.6 本章小结

  • Protocol Buffers 是 gRPC 的序列化契约，压测工具必须支持 protobuf 消息的动态构造或预编译。
  • Service Definition 通过 .proto 文件声明 RPC 方法及其输入输出类型，是压测任务定义的直接依据。
  • 四种通信模式（Unary、Server Streaming、Client Streaming、Bidirectional Streaming）决定了压测工具的并发模型、连接管理和流量控制策略。
  • 压测架构设计必须从契约出发，将 .proto 元素映射为具体的压测组件，才能实现可扩展、可维护的压测系统。
← 上一章 📖 返回目录 下一章 →