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

2. gRPC 基础回顾：通信模型、Protocol Buffers 与 RPC 模式

在深入连接池动态调整与链路追踪之前，必须重新夯实 gRPC 的核心基础。本章将聚焦三个关键维度：通信模型（HTTP/2 多路复用）、序列化契约（Protocol Buffers）以及四种 RPC 模式（一元、服务端流、客户端流、双向流）。这些基础直接决定了连接池的复用策略与追踪数据的采集粒度。

2.1 gRPC 通信模型：基于 HTTP/2 的二进制传输

gRPC 默认使用 HTTP/2 作为传输层协议，这是其高性能的核心来源。与 HTTP/1.1 的文本头部、队头阻塞不同，HTTP/2 引入了以下关键机制：

特性	HTTP/1.1	HTTP/2 (gRPC 基础)
传输格式	文本（头部+体）	二进制帧（头部压缩 HPACK）
多路复用	串行，需多个连接	单一连接，多流并行
队头阻塞	存在（请求级）	无（流级独立）
头部压缩	无	HPACK 压缩，减少开销
服务器推送	不支持	支持（gRPC 较少使用）

  关键理解： gRPC 的“连接池”本质上是 HTTP/2 连接池。一个连接可以承载数千个并发流（Stream），因此连接池的大小通常远小于 HTTP/1.1 场景。连接池动态调整的核心，就是根据并发流数量与系统负载，动态增减底层 HTTP/2 连接数。

2.2 Protocol Buffers：接口定义与序列化契约

Protocol Buffers（protobuf）是 gRPC 的接口定义语言（IDL）与序列化协议。它定义了服务的方法签名、消息结构以及跨语言的数据交换格式。

2.2.1 核心文件结构

一个典型的 .proto 文件包含以下要素：

syntax = "proto3";  // 使用 proto3 语法

package user.v1;     // 包名，用于命名空间隔离

// 引入依赖
import "google/protobuf/timestamp.proto";

// 定义服务
service UserService {
  // 一元 RPC
  rpc GetUser (GetUserRequest) returns (GetUserResponse);

  // 服务端流式 RPC
  rpc ListUsers (ListUsersRequest) returns (stream User);

  // 客户端流式 RPC
  rpc UpdateUsers (stream UpdateUserRequest) returns (UpdateUserResponse);

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

// 请求消息
message GetUserRequest {
  string user_id = 1;  // 字段编号 1
}

// 响应消息
message GetUserResponse {
  string user_id = 1;
  string name = 2;
  string email = 3;
  google.protobuf.Timestamp created_at = 4;
}

字段编号（Field Number）：1-15 使用 1 字节编码，16-2047 使用 2 字节编码。高频字段应分配小编号以节省带宽。这是 protobuf 二进制紧凑性的关键设计。

2.2.2 序列化与反序列化流程

protobuf 的序列化过程不依赖反射，而是通过生成的代码直接操作内存布局，性能远高于 JSON/XML。

定义 .proto 文件：声明消息结构和服务接口。
代码生成：使用 protoc 编译器生成目标语言的桩代码（Stub）。
序列化：客户端将消息对象编码为二进制字节流，每个字段按 Tag-Length-Value（TLV）格式写入。
传输：二进制数据通过 HTTP/2 DATA 帧发送。
反序列化：服务端根据生成的代码解析字节流，还原为内存对象。

2.3 一元 RPC 与流式 RPC

gRPC 支持四种 RPC 模式，它们对连接池的复用效率与追踪上下文传播方式有直接影响。

RPC 模式	请求/响应	典型场景	连接池影响
一元 RPC	1 请求 → 1 响应	查询用户、下单	短连接行为，高并发时需大量流
服务端流式	1 请求 → N 响应	订阅事件、日志推送	长连接，单流占用时间长
客户端流式	N 请求 → 1 响应	批量上传、聚合数据	长连接，客户端持续发送
双向流式	N 请求 → N 响应	实时聊天、游戏同步	全双工，连接复用率最高

2.3.1 一元 RPC 的调用流程

一元 RPC 是最常用的模式，其生命周期清晰，适合作为链路追踪的切入点。

// 客户端调用（Java 示例）
UserServiceGrpc.UserServiceBlockingStub stub = UserServiceGrpc.newBlockingStub(channel);
GetUserResponse response = stub.getUser(GetUserRequest.newBuilder()
    .setUserId("12345")
    .build());

// 服务端实现
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
    @Override
    public void getUser(GetUserRequest request, StreamObserver<GetUserResponse> responseObserver) {
        // 业务逻辑
        GetUserResponse response = GetUserResponse.newBuilder()
            .setUserId(request.getUserId())
            .setName("Alice")
            .build();
        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

注意： 一元 RPC 虽然语义简单，但在高并发场景下，每个请求都会创建一个 HTTP/2 流。如果连接池中的连接数不足，会导致流排队或连接创建延迟。这正是连接池动态调整需要解决的典型问题。

2.3.2 流式 RPC 的流控制

流式 RPC 依赖 HTTP/2 的流控制（Flow Control）机制。每个流都有初始窗口大小（默认 64KB），接收方可以通过 WINDOW_UPDATE 帧动态调整窗口。

服务端流式：客户端发送一个请求后，服务端可以持续推送消息。适用于事件驱动场景。
客户端流式：客户端发送多个请求后，服务端返回一个聚合响应。适用于批量处理。
双向流式：双方独立发送消息，没有严格的请求-响应顺序。适用于实时交互。

2.4 本章小结

gRPC 的基础架构决定了连接池的设计方向：

HTTP/2 多路复用 使得一个连接可以承载大量并发流，连接池规模通常较小（例如 2-10 个连接）。
Protocol Buffers 提供了高效的二进制序列化，减少了传输延迟，但连接池的瓶颈更多出现在流调度而非序列化上。
四种 RPC 模式 对流生命周期的不同要求，是连接池动态调整策略的核心输入。一元 RPC 适合快速扩缩流，流式 RPC 需要更精细的容量规划。