Question

这是一个消耗事件流的服务的原型定义来自客户

message Event {
  // ...
}

service EventService {
  rpc Publisher(stream Event) returns (google.protobuf.Empty);
}

问题是需要告知服务器如何处理此流。理想情况下，它会首先收到Options消息：

message Event {
  // ...
}

message Options {
  // ...
}

service EventService {
  rpc Publisher(Options, stream Event) returns (google.protobuf.Empty);
}

但是，grpc仅支持rpc方法的一个参数。一种解决方案是引入额外的PublishMessage消息可以包含Options或Event消息。

message PublishMessage {
  oneof content {
    Options options = 1;
    Event event = 2;
  }
}

然后，该服务会期望第一个PublishMessage包含Options消息，所有后续消息都包含Event个消息。这引入了包装消息的额外开销，使api变得有点笨拙。

是否有更简洁的方法可以达到相同的效果？

Answer 1

当许多字段或消息在播放时，使用oneof是建议的方法。开销很小，因此通常不会引起关注。虽然有笨拙。

如果只有几个字段，您可能希望将Options和Event中的字段合并为一条消息。或者类似地将“事件”选项添加到字段中。您希望选项字段出现在第一个请求中，而后续丢失。当配置字段较少时，这种方法效果会更好，例如“名称”。

GRPC：带有配置消息的客户端流

1 个答案: