4. gRPC 通信模式详解：Unary RPC（简单RPC）的工作流程、客户端与服务端交互模型、同步与异步调用

Unary RPC（一元 RPC）是 gRPC 中最基础、最常用的通信模式。它遵循经典的“请求-响应”模型：客户端发送一个请求消息，服务端处理完成后返回一个响应消息。这种模式在语义上等同于传统的 HTTP/1.1 或 RPC 调用，但底层基于 HTTP/2 和 Protobuf 序列化，具备更高的性能和跨语言能力。

4.1 Unary RPC 的工作流程

一次完整的 Unary RPC 调用从客户端发起请求到收到响应，经历了以下核心步骤：

1. 客户端存根（Stub）发起调用：客户端代码调用由 protoc 生成的 Stub 方法，传入请求参数。
2. 序列化与帧封装：gRPC 客户端将 Protobuf 消息序列化为二进制数据，并封装为 HTTP/2 DATA 帧。
3. HTTP/2 流传输：通过已建立的 HTTP/2 连接，将请求帧发送到服务端。每个 Unary 调用使用一个独立的 HTTP/2 Stream。
4. 服务端接收与反序列化：服务端 Transport 层接收帧，重组为完整的 Protobuf 消息，并传递给业务逻辑处理器。
5. 业务处理：服务端执行用户定义的 Handler 方法，处理请求并构造响应消息。
6. 序列化与响应：服务端将响应消息序列化，通过相同的 HTTP/2 Stream 返回给客户端。
7. 客户端接收与反序列化：客户端 Transport 层接收响应帧，反序列化为 Protobuf 对象，并返回给调用方。

4.2 客户端与服务端交互模型

Unary RPC 的交互模型可以拆解为四个关键角色：客户端应用、客户端 Stub、服务端骨架（Skeleton）和服务端业务实现。它们之间的协作关系如下：

4.3 同步调用与异步调用

gRPC 在客户端同时支持同步（阻塞）和异步（非阻塞）两种调用方式。选择哪种方式取决于应用场景对延迟、吞吐量和编程复杂度的要求。

4.3.1 同步调用（Blocking/Unary）

同步调用是最直观的方式：客户端发起调用后，当前线程会阻塞等待服务端返回响应或超时。适用于对延迟不敏感、调用频率较低或需要强顺序保证的场景。

// 同步调用示例（Java）
GreeterGrpc.GreeterBlockingStub blockingStub = GreeterGrpc.newBlockingStub(channel);
HelloRequest request = HelloRequest.newBuilder().setName("World").build();
try {
    HelloResponse response = blockingStub.sayHello(request);
    System.out.println("收到响应: " + response.getMessage());
} catch (StatusRuntimeException e) {
    System.err.println("RPC 失败: " + e.getStatus());
}

4.3.2 异步调用（Non-Blocking/Unary）

异步调用允许客户端在发起 RPC 后立即返回，不阻塞当前线程。响应通过回调（Callback）或 Future 机制在后续时间点获取。适用于高吞吐、低延迟或需要并发处理多个 RPC 的场景。

// 异步调用示例（Java，使用 ListenableFuture）
GreeterGrpc.GreeterFutureStub futureStub = GreeterGrpc.newFutureStub(channel);
HelloRequest request = HelloRequest.newBuilder().setName("World").build();
ListenableFuture<HelloResponse> future = futureStub.sayHello(request);

// 注册回调，不阻塞主线程
Futures.addCallback(future, new FutureCallback<HelloResponse>() {
    @Override
    public void onSuccess(HelloResponse response) {
        System.out.println("异步收到响应: " + response.getMessage());
    }
    @Override
    public void onFailure(Throwable t) {
        System.err.println("异步 RPC 失败: " + t.getMessage());
    }
}, executor);

4.3.3 同步 vs 异步对比

4.4 实践建议与常见陷阱

• 超时设置：无论是同步还是异步调用，都应设置合理的超时时间（withDeadlineAfter()），避免客户端无限等待。
• 资源管理：异步调用中，务必确保回调不会阻塞 EventLoop 线程，否则会降低整体吞吐量。
• 错误传播：同步调用的异常通过 StatusRuntimeException 直接抛出；异步调用需在回调中显式处理 onFailure，避免静默吞掉错误。
• 选择依据：对于发布拓扑中的配置查询、状态上报等低频操作，优先使用同步调用；对于实时数据推送、批量事件处理等高频场景，推荐使用异步调用。