如何定义支持可选流式/Unary响应的单个proto3 RPC？

首先明确：proto3不支持将RPC的stream关键字设为可选，RPC的响应类型（Unary/流式）是在定义阶段就固定的，无法让同一个RPC接口同时支持两种响应模式。

下面是两种可行的实现方案，以及各自的优劣分析：

方案一：定义两个独立的RPC接口（推荐） #

这是最符合gRPC设计理念的规范做法，分别定义Unary和流式两个接口，客户端根据自身需求选择调用。

示例Proto定义 #

syntax = "proto3";

service DataService {
    // Unary响应：一次性返回全部内容
    rpc GetData(GetDataRequest) returns (DataResponse) {}
    
    // 流式响应：分批返回内容
    rpc GetDataStream(GetDataRequest) returns (stream DataResponse) {}
}

message GetDataRequest {
    string query = 1; // 业务请求参数
}

message DataResponse {
    bytes content_chunk = 1; // 数据片段（Unary时为完整内容）
    bool is_final = 2; // 流式响应专用：标记是否为最后一个片段
}

优势 #

• 接口语义清晰，其他开发者看Proto就能明确各接口的用途
• 客户端可以根据场景选择最合适的调用方式，无需额外处理流式逻辑（如果只需要Unary的话）
• 服务端可以复用核心业务逻辑，仅在接口层做响应封装：Unary接口把所有数据打包成一个DataResponse返回，流式接口则分批推送片段

方案二：用单个流式RPC，通过请求参数控制响应模式 #

这种方式可以避免定义多个接口，但客户端必须始终按照流式API来处理请求。

示例Proto定义 #

syntax = "proto3";

service DataService {
    rpc GetData(GetDataRequest) returns (stream DataResponse) {}
}

message GetDataRequest {
    string query = 1;
    bool return_single = 2; // 控制是否返回单条响应
}

message DataResponse {
    bytes content = 1;
}

实现逻辑 #

服务端根据return_single字段判断：

• 如果为true：仅返回一条包含全部内容的DataResponse，然后关闭流
• 如果为false：分批返回多个DataResponse片段

劣势 #

• 客户端无论是否需要流式响应，都必须编写流式调用的逻辑（比如处理流的生命周期、接收消息），增加了不必要的复杂度
• 接口语义模糊，Proto文件无法直接体现接口同时支持两种模式，不利于团队协作和维护

总结 #

优先选择方案一，定义两个独立的RPC接口。这是gRPC官方推荐的最佳实践，既能保证接口语义清晰，也能让客户端灵活选择调用方式。方案二仅适合临时场景，不建议作为长期的API设计方案。

内容的提问来源于stack exchange，提问作者tutu056