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

2. gRPC 基础回顾：通信模型、Protocol Buffers 与四种服务类型

在深入分析 gRPC 调用超时与 GC 停顿的根因之前，必须牢固掌握 gRPC 的核心通信模型与编程范式。本章将系统回顾 gRPC 的底层通信机制、序列化协议以及四种 RPC 服务类型，为后续的故障排查与性能调优奠定基础。

2.1 gRPC 通信模型

gRPC 是一个高性能、开源、通用的 RPC 框架，基于 HTTP/2 协议传输，使用 Protocol Buffers 作为接口定义语言（IDL）和序列化工具。其核心通信模型具有以下关键特征：

HTTP/2 多路复用：单个 TCP 连接可承载多个并发流（Stream），消除 HTTP/1.x 的队头阻塞问题，显著降低连接建立开销。
双向流式通信：基于 HTTP/2 的流式语义，gRPC 天然支持客户端与服务端的双向流式数据传输。
Protobuf 二进制序列化：数据以紧凑的二进制格式传输，体积小、解析快，相比 JSON 可减少 60%-80% 的传输数据量。
Stub 与 Channel：客户端通过 Stub（存根）发起调用，Stub 内部通过 Channel（通道）管理 HTTP/2 连接的生命周期。

  关键概念：gRPC 的通信模型本质上是一个 客户端-服务端 的远程过程调用模型，但通过 HTTP/2 和 Protobuf 实现了极致的性能与灵活性。理解 Channel、Call 和 Stream 三者的关系是诊断超时问题的第一步。

2.2 Protocol Buffers（Protobuf）

Protocol Buffers 是 gRPC 的接口定义语言（IDL）和默认序列化协议。它通过 .proto 文件定义服务接口和消息结构，然后生成各语言的代码。

2.2.1 核心语法

syntax = "proto3";

package user.v1;

// 定义服务
service UserService {
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
  rpc ListUsers (ListUsersRequest) returns (stream User);
  rpc UpdateUser (stream UpdateUserRequest) returns (UpdateUserResponse);
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

// 定义消息
message GetUserRequest {
  int32 user_id = 1;
  string trace_id = 2;
}

message GetUserResponse {
  int32 user_id = 1;
  string name = 2;
  string email = 3;
  int32 age = 4;
  repeated string tags = 5;
}

2.2.2 Protobuf 序列化特点

特性	Protobuf	JSON	XML
序列化格式	二进制	文本	文本
数据体积	极小（压缩率高）	中等	大（冗余标签多）
解析速度	极快（无需解析标签名）	中等	慢
Schema 强制	是（强类型）	否（动态类型）	可选（XSD）
向后兼容	优秀（字段编号机制）	需手动处理	需手动处理
语言支持	10+ 主流语言	所有语言	所有语言

性能提示：在 gRPC 调用中，Protobuf 的序列化/反序列化时间通常只占 RPC 总耗时的 1%-5%。但在高并发场景下，频繁的序列化操作会加剧 GC 压力，这是后续章节分析 GC 停顿的重要线索。

2.3 四种服务类型

gRPC 基于 HTTP/2 的流式语义，定义了四种 RPC 服务类型。理解它们的通信模式对于诊断超时和资源竞争至关重要。

2.3.1 类型对比

类型	客户端请求	服务端响应	典型场景	超时风险点
Unary RPC	单条消息	单条消息	查询用户信息、下单	网络延迟、服务端处理慢
Server Streaming	单条消息	多条消息（流）	订阅通知、日志推送	流未及时关闭、客户端消费慢
Client Streaming	多条消息（流）	单条消息	批量上传、日志聚合	客户端发送超时、服务端聚合慢
Bidirectional Streaming	多条消息（流）	多条消息（流）	实时聊天、游戏同步	双向流控制、内存泄漏、GC 停顿

2.3.2 四种类型的通信模式详解

下面通过两张 SVG 图分别展示 Unary / Server Streaming 和 Client Streaming / Bidirectional Streaming 的通信时序。

2.4 四种服务类型的代码示例

以下代码片段展示了四种服务类型的 gRPC 调用方式（以 Java 为例）：

2.4.1 Unary RPC

// 客户端调用
GetUserResponse response = stub.getUser(
    GetUserRequest.newBuilder()
        .setUserId(1001)
        .setTraceId("abc-123")
        .build()
);
System.out.println("User: " + response.getName());

2.4.2 Server Streaming

// 客户端调用
stub.listUsers(request, new StreamObserver<User>() {
    @Override
    public void onNext(User user) {
        System.out.println("Received user: " + user.getName());
    }
    @Override
    public void onError(Throwable t) {
        System.err.println("Error: " + t.getMessage());
    }
    @Override
    public void onCompleted() {
        System.out.println("Stream completed");
    }
});

2.4.3 Client Streaming

// 客户端调用
StreamObserver<UpdateUserRequest> requestObserver = 
    stub.updateUser(responseObserver);
requestObserver.onNext(request1);
requestObserver.onNext(request2);
requestObserver.onNext(request3);
requestObserver.onCompleted();

2.4.4 Bidirectional Streaming

// 客户端调用
StreamObserver<ChatMessage> requestObserver = 
    stub.chat(new StreamObserver<ChatMessage>() {
        @Override
        public void onNext(ChatMessage msg) {
            System.out.println("Server: " + msg.getContent());
        }
        @Override
        public void onError(Throwable t) { }
        @Override
        public void onCompleted() { }
    });
requestObserver.onNext(ChatMessage.newBuilder()
    .setContent("Hello Server!").build());

超时与 GC 关联预警：在 Bidirectional Streaming 场景中，如果客户端或服务端未能及时消费流中的消息，会导致消息在内存中堆积，进而引发频繁的 Young GC 甚至 Full GC。这是后续章节分析 GC 停顿根因的核心场景之一。

2.5 本章小结

gRPC 基于 HTTP/2 和 Protobuf，提供高性能的远程过程调用能力。
四种服务类型（Unary、Server Streaming、Client Streaming、Bidirectional Streaming）覆盖了从简单请求-响应到复杂双向流通信的全部场景。
理解每种类型的通信模式、超时风险点和内存管理方式，是诊断 gRPC 调用超时和 GC 停顿的前提。
在后续章节中，我们将基于这些基础知识，深入分析超时配置、连接池管理、流控机制以及 GC 停顿对 gRPC 调用的影响。