2. gRPC 通信模式：一元RPC、服务端流式RPC、客户端流式RPC、双向流式RPC详解

gRPC 基于 HTTP/2 协议，定义了四种核心的通信模式（Communication Patterns）。这些模式决定了客户端与服务端之间如何交换消息，直接影响压测场景的建模方式、线程模型选择以及性能瓶颈的定位。理解这四种模式是进行精准压测诊断的前提。

2.1 四种通信模式概述

下表从消息流方向、典型应用和压测关注点三个维度，对四种模式进行横向对比：

2.2 一元 RPC（Unary RPC）

一元 RPC 是最简单、最常用的模式，其行为与传统的 HTTP REST 接口类似：客户端发起一次请求，服务端处理完成后返回一次响应。在 gRPC 中，一元 RPC 的调用过程包含 序列化、HTTP/2 帧封装、网络传输、反序列化 四个阶段。

Proto 定义示例：

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

message GetUserRequest {
    int32 user_id = 1;
}

message GetUserResponse {
    string name = 1;
    string email = 2;
}

压测诊断要点：

• 连接池效率： 一元 RPC 的压测瓶颈往往不在服务端处理能力，而在客户端能否高效复用 HTTP/2 连接。压测时需监控 GOAWAY 帧频率和连接创建速率。
• 序列化开销： Protobuf 序列化/反序列化在消息体较大时（> 1MB）会成为 CPU 瓶颈，压测时应关注 protobuf_serialize 和 protobuf_deserialize 耗时指标。
• 超时控制： 一元 RPC 的 deadline 设置不当会导致大量超时重试，压测时需区分“服务端处理超时”和“网络传输超时”。

2.3 服务端流式 RPC（Server Streaming RPC）

客户端发送一个请求后，服务端通过流（Stream）连续返回多条消息。这种模式在压测时，客户端接收消息的速度 成为关键变量。如果客户端消费速度跟不上服务端生产速度，HTTP/2 的流控机制会触发背压，导致服务端写入阻塞。

Proto 定义示例：

service MonitorService {
    rpc SubscribeMetrics (MetricsRequest) returns (stream MetricsEvent);
}

message MetricsRequest {
    string metric_name = 1;
    int32 interval_ms = 2;
}

message MetricsEvent {
    int64 timestamp = 1;
    double value = 2;
}

压测诊断要点：

• 流控窗口： HTTP/2 的 INITIAL_WINDOW_SIZE（默认 64KB）决定了流控粒度。压测时如果消息体较大，需要调大窗口值，否则吞吐量会受限于流控更新帧的往返延迟。
• 内存泄漏： 服务端流式 RPC 中，如果客户端断开连接后服务端未正确取消流上下文（Context），会导致 goroutine/线程泄漏。压测时需监控服务端活跃流数量。
• 消息批处理： 服务端在流中发送小消息时，建议使用 flush 控制或批处理合并，避免大量小帧导致 HTTP/2 头部压缩效率下降。

2.4 客户端流式 RPC（Client Streaming RPC）

客户端通过流发送多条消息，服务端在所有消息接收完毕后返回一个聚合响应。这种模式在压测时，客户端发送速率 和 服务端合并策略 是性能关键。

Proto 定义示例：

service UploadService {
    rpc UploadTelemetry (stream TelemetryRecord) returns (UploadSummary);
}

message TelemetryRecord {
    string device_id = 1;
    int64 timestamp = 2;
    bytes payload = 3;
}

message UploadSummary {
    int32 total_records = 1;
    int64 processing_time_ms = 2;
}

压测诊断要点：

• 发送速率控制： 客户端流式 RPC 的压测需要模拟真实场景的发送间隔。如果发送速率过快，服务端缓冲区可能溢出；过慢则无法压满服务端处理能力。建议使用 令牌桶 或 固定间隔 控制发送节奏。
• 服务端合并延迟： 服务端在接收完所有消息后才返回响应，因此压测时需关注 last_message_received 到 response_sent 之间的合并处理耗时。
• 半关闭语义： 客户端发送完所有消息后必须调用 closeAndWait() 或 complete() 通知服务端。压测中如果忘记半关闭，服务端会一直等待，导致连接泄漏。

2.5 双向流式 RPC（Bidirectional Streaming RPC）

双向流式 RPC 允许客户端和服务端独立、并发地发送消息，实现全双工通信。这是四种模式中最复杂、也最容易出现性能问题的模式。在压测时，消息顺序性、并发度 和 资源竞争 是核心诊断维度。

Proto 定义示例：

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

message ChatMessage {
    string user_id = 1;
    string room_id = 2;
    string content = 3;
    int64 timestamp = 4;
}

压测诊断要点：

• 全双工吞吐： 压测时需分别统计 上行吞吐（客户端→服务端）和 下行吞吐（服务端→客户端）。如果上下行共享同一个 HTTP/2 流，需关注流控窗口的竞争。
• 消息顺序性： 双向流中，消息在同一个 HTTP/2 流上是保序的。但如果服务端使用多线程处理，可能出现乱序。压测时需在消息中嵌入序列号，验证顺序性。
• 连接稳定性： 双向流长连接场景下，网络抖动、服务端重启、负载均衡策略都可能导致流中断。压测时需模拟断连重连场景，测试客户端的自动重连和消息去重能力。

2.6 四种模式的核心差异对比（压测视角）

下表从压测工具配置、线程模型、资源消耗三个维度，给出四种模式的差异对比：

2.7 四种通信模式的交互流程（SVG 图）

下图展示了四种通信模式在 HTTP/2 流上的消息交互流程，帮助理解压测时的消息流向和并发模型：

2.8 压测场景与通信模式的匹配策略

在实际压测诊断中，需要根据被测服务的通信模式选择对应的压测策略。下表给出了四种模式的压测场景匹配建议：

2.9 流式 RPC 的背压与流控机制（SVG 图）

流式 RPC 的性能瓶颈往往与 HTTP/2 的流控机制密切相关。下图展示了服务端流式 RPC 中背压产生的过程：

在压测诊断中，理解背压机制有助于解释为什么服务端流式 RPC 的吞吐量会随着客户端数量增加而出现非线性下降。通常的优化方向包括：

• 调大流控窗口： 将 INITIAL_WINDOW_SIZE 从 64KB 调整为 1MB 或更大，减少流控更新帧的交互次数。
• 异步消费： 客户端使用异步非阻塞方式读取流，避免消费线程被阻塞。
• 消息批处理： 服务端将多条小消息合并为一条大消息发送，减少帧头开销和流控交互。