stream - gRPC 流服务只能有一个参数的原因

Question

目前，gRPC 服务定义只能有一个参数，即使它是一个流服务，这使得表示“初始”请求具有挑战性。例如，考虑一个用户可以加入聊天室的聊天应用程序。

在这种情况下，域可以建模如下。

message JoinRoomRequest {
  required string room = 1;
}

message ChatMessage {
  required string content = 2;
}

聊天应用程序的消费者将发送加入请求并启动双向消息流，因此可以用这种方式描述服务。

service SimpleChat {
  rpc joinChatRoom (JoinRoomRequest, stream ChatMessage) returns (stream ChatMessage);
}

但是，在 gRPC 中，上述语法无效。表示所描述的聊天服务的唯一方法是

service SimpleChat {
  rpc joinChatRoom (stream ChatMessage) returns (stream ChatMessage);
}

这个决定背后的原因是什么，以及如何在 gRPC 中建模类似的域？

Answer 1

简单。将请求/响应建模为单个有效负载而不是可变参数要容易得多，尤其是在您希望多重性不同的情况下 - 例如，这意味着什么

(A, stream B, C, stream D)

而且......如果你可以获取多个元素，你也可以返回多个元素吗？毕竟，许多语言都支持这个概念。

不，接收(作为输入或输出)请求或单一类型的请求流要容易得多。

在您的场景中，也许可以将请求类型视为所有实际预期消息的 oneof (区分联合)的事物包装器，并且只需让您的代码强制第一个是“加入”:

message ChatRequest {
  oneof RequestType {
    JoinRoomRequest join = 1;
    ChatMessage message = 2;
  }
}

并取一个 ChatRequest 流