2. gRPC 基础回顾：通信模型与四种 RPC 模式

在深入错误处理与事务边界之前，必须牢固掌握 gRPC 的通信模型及其四种核心 RPC 模式。gRPC 基于 HTTP/2 协议，利用 Protocol Buffers（protobuf）作为接口定义语言（IDL）和序列化工具，构建了高效、强类型的远程调用体系。本章将系统梳理其通信模型，并逐一剖析四种 RPC 模式的特点、适用场景与关键代码结构。

2.1 gRPC 通信模型总览

gRPC 采用客户端-服务器（C/S）架构，通信建立在 HTTP/2 的单一长连接之上。HTTP/2 的多路复用（Multiplexing）机制允许在同一个 TCP 连接上并发处理多个 RPC 调用，大幅减少了连接开销。核心通信流程如下：

1. 服务定义：使用 protobuf 在 .proto 文件中定义服务接口和消息结构。
2. 代码生成：通过 protoc 编译器生成客户端 Stub 和服务器骨架代码。
3. 连接建立：客户端通过 HTTP/2 升级握手与服务器建立持久连接。
4. 数据序列化：请求与响应数据被序列化为二进制 protobuf 格式，通过 HTTP/2 的 DATA 帧传输。
5. 流控制：HTTP/2 的流控机制确保发送方不会压垮接收方。

2.2 四种 RPC 模式详解

gRPC 基于 HTTP/2 的流（Stream）概念，定义了四种 RPC 模式。这些模式决定了客户端与服务器之间消息交换的时序和数量，直接影响错误处理策略和事务边界的定义。

2.3 模式一：Unary RPC（一元 RPC）

Unary RPC 是最简单的模式，客户端发送一个请求，服务器返回一个响应。其行为类似于传统的 HTTP REST 调用，但基于 HTTP/2 和 protobuf 提供了更低的延迟和更强的类型安全。

protobuf 定义示例：

service UserService {
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}

message GetUserRequest {
  int64 user_id = 1;
}

message GetUserResponse {
  string name = 1;
  string email = 2;
  int32 age = 3;
}

客户端调用（Go 语言示例）：

conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure())
defer conn.Close()
client := pb.NewUserServiceClient(conn)

ctx, cancel := context.WithTimeout(context.Background(), time.Second)
defer cancel()

resp, err := client.GetUser(ctx, &pb.GetUserRequest{UserId: 123})
if err != nil {
    // 处理 gRPC 错误（如 DeadlineExceeded, Unavailable 等）
    log.Fatalf("could not get user: %v", err)
}
log.Printf("User: %s, Email: %s", resp.Name, resp.Email)

2.4 模式二：Server Streaming RPC（服务器流式 RPC）

客户端发送一个请求，服务器返回一个消息流。客户端通过迭代读取流中的消息，直到流结束。此模式适用于服务器需要向客户端推送大量数据或持续事件的场景。

protobuf 定义示例：

service EventService {
  rpc SubscribeEvents (SubscribeRequest) returns (stream Event);
}

message SubscribeRequest {
  string topic = 1;
}

message Event {
  int64 id = 1;
  string payload = 2;
  int64 timestamp = 3;
}

客户端读取流（Go 语言示例）：

stream, err := client.SubscribeEvents(ctx, &pb.SubscribeRequest{Topic: "orders"})
if err != nil {
    log.Fatalf("could not subscribe: %v", err)
}

for {
    event, err := stream.Recv()
    if err == io.EOF {
        // 流正常结束
        break
    }
    if err != nil {
        // 流中发生错误（如网络中断、服务器错误）
        log.Printf("error receiving event: %v", err)
        break
    }
    log.Printf("Received event: %d - %s", event.Id, event.Payload)
}

2.5 模式三：Client Streaming RPC（客户端流式 RPC）

客户端发送一个消息流，服务器在接收完所有消息后返回一个响应。此模式适用于客户端需要批量提交数据，然后等待服务器聚合处理的场景。

protobuf 定义示例：

service UploadService {
  rpc UploadChunks (stream Chunk) returns (UploadSummary);
}

message Chunk {
  bytes data = 1;
  int32 sequence_number = 2;
}

message UploadSummary {
  int64 total_bytes = 1;
  int32 chunk_count = 2;
}

客户端发送流（Go 语言示例）：

stream, err := client.UploadChunks(ctx)
if err != nil {
    log.Fatalf("could not start upload: %v", err)
}

for _, chunk := range chunks {
    if err := stream.Send(chunk); err != nil {
        // 发送过程中出错（如流已关闭、网络问题）
        log.Printf("error sending chunk: %v", err)
        break
    }
}

summary, err := stream.CloseAndRecv()
if err != nil {
    // 服务器返回的错误（如校验失败、处理超时）
    log.Printf("upload failed: %v", err)
} else {
    log.Printf("Upload summary: %d bytes, %d chunks", summary.TotalBytes, summary.ChunkCount)
}

2.6 模式四：Bidirectional Streaming RPC（双向流式 RPC）

客户端和服务器可以独立地发送和接收消息流。双方的消息顺序在各自流内保持有序，但两个流之间没有严格的时序依赖。此模式适用于需要实时双向交互的场景。

protobuf 定义示例：

service ChatService {
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message ChatMessage {
  string user = 1;
  string text = 2;
  int64 timestamp = 3;
}

客户端双向交互（Go 语言示例）：

stream, err := client.Chat(ctx)
if err != nil {
    log.Fatalf("could not start chat: %v", err)
}

// 启动一个 goroutine 接收消息
go func() {
    for {
        msg, err := stream.Recv()
        if err == io.EOF {
            break
        }
        if err != nil {
            log.Printf("receive error: %v", err)
            break
        }
        log.Printf("[%s] %s", msg.User, msg.Text)
    }
}()

// 主 goroutine 发送消息
for _, msg := range messagesToSend {
    if err := stream.Send(msg); err != nil {
        log.Printf("send error: %v", err)
        break
    }
}
stream.CloseSend()

2.7 模式选择与错误处理策略总结

选择哪种 RPC 模式，直接决定了后续错误处理和事务边界设计的复杂度。以下表格总结了不同模式下的关键考量：