使用GRPC流式传输多种类型的最佳方法

Question

我有一台将消息传递给客户端的服务器。消息的类型不同，服务器对客户端使用通用的handleMessage和passMessage方法。

现在我打算对此进行调整并使用GRPC。我知道我可以通过在.proto文件中定义服务来公开服务器的所有方法。但是还有办法：

• Stream
• 异类
• 一次RPC调用
• 使用GRPC

有oneof允许我设置仅包含其中一个属性的消息。我可以MessageContainer oneof，我的所有消息类型都包含在此容器中。现在容器只有一种类型，我只需要写一个

service {
   rpc messageHandler(ClientInfo)  returns (stream MessageContainer)
}

这样，服务器可以通过一个唯一的接口将多种类型流式传输到客户端。这有意义吗？或者让所有方法单独曝光更好吗？

更新

我发现this thread认为oneof是可行的方式。我明白这一点，因为它避免了我必须创建潜在的数十个服务和存根。它还有助于确保它是一个FIFO设置，而不是多路复用多个流，而不确定哪个消息首先出现。但由于某种原因感觉脏。

Answer 1

是的，这是有道理的（您所谓的MessageContainer最好被理解为sum type）。

...但是最好定义不同的方法（＆＃34;更好＆＃34;这里意味着＆＃34;更具惯用性，系统的未来维护者更易读，更能够成为当方法语义需要改变＆＃34;）时，将来会发生变化。

是否将服务表示为返回sum类型或多个RPC方法的单个RPC方法的问题归结为在RPC调用时是否可以知道将使用的特定加数类型。如果您将request.my_type_determining_field设置为5，则服务器传输的流始终包含MessageContainer个oneof设置为MyFifthKindOfParticularMessage的消息实例？如果是这样，那么您应该只编写一个返回MyFifthKindOfParticularMessage消息流的单独RPC方法。但是，如果是这样的话，在RPC调用时你不知道确定知道从服务器传输的消息的使用加数类型是什么（和＆＃34;消息在同一个流中使用不同的加数类型＆＃34;是这个的子用例 - 然后我认为你的服务可能被分解为不同的RPC并且正确的事情是你要做的是有一个RPC方法返回一个sum类型的流。