在gRPC C++中实现客户端流式RPC必须使用异步API吗

// 要实现流式分块上传，需要在请求参数前加stream关键字标识为客户端流式RPC
rpc fileUpload (stream fileRequest) returns (fileResponse)  {}
  
message fileRequest{
  oneof request {
    MetaData metadata = 1;
    File file = 2;
  }
}

message MetaData {
  string name = 1;
  string type = 2;
}

message File {
  bytes content = 1;
}

// 响应结构可按需自定义字段，比如状态码、错误信息、文件存储路径等
message fileResponse {
  int32 code = 1;
  string msg = 2;
}

该场景不需要强制使用gRPC异步API，直接使用同步API就可以完整实现分块流式上传图片的需求。

gRPC同步API原生支持全部四种RPC通信模式，你需要的客户端流式上传完全在同步API的支持范围内，且开发门槛比异步API低很多，代码可读性和可维护性更好，适合绝大多数普通业务场景。

同步API实现逻辑 #

• 客户端实现步骤：
  1. 调用stub的fileUpload方法获取客户端写入流对象
  2. 先写入第一个fileRequest，oneof字段设置为MetaData，传输文件名、文件类型等元信息
  3. 循环读取本地图片文件的分块（建议单块大小1~4MB，避免触发gRPC默认4MB消息大小限制），每个分块封装为File类型的fileRequest，调用流的Write方法发送
  4. 全部分块发送完成后调用流的WritesDone方法，等待服务端返回响应即可
• 服务端实现步骤：
  1. 重写fileUpload服务方法，获取客户端读取流对象
  2. 循环调用流的Read方法读取客户端发来的fileRequest，解析第一个请求拿到文件元数据，后续请求解析出二进制分块追加写入服务端本地文件
  3. 所有请求读取完成后，返回自定义的fileResponse标识上传结果即可

仅以下场景需要考虑使用异步API #

• 你需要支持上万级别的并发上传请求，同步API单RPC对应单线程的模型存在性能瓶颈，无法满足吞吐量要求
• 你的服务本身是异步架构，需要和其他异步逻辑做协同
• 你需要实现复杂的自定义流控、超时策略、批量处理等高级逻辑，同步API的灵活性无法满足需求

普通业务场景下使用同步API开发效率更高，调试排查问题也更简单，完全可以满足需求。

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