英文:
Error types in gRPC streaming
问题
我有一个 gRPC 端点，可以在查询和结果之间进行流式传输，服务器端经常会出现错误，我希望将这些错误发送回去。我目前处理错误的方法是在回复中包含错误消息。
我怀疑创建一个单独的消息可能更高效，这样一个错误消息就不必包含所有其他数据。我不太愿意创建和同步多个消息，因为我不想增加太多复杂性。拆分消息可以获得哪些效率提升？有没有一种标准的做法（特别是在 Go 中）？
以下是翻译好的内容：
我有一个 gRPC 端点，用于在查询和结果之间进行流式传输，服务器端经常会出现错误，我希望将这些错误发送回去。我目前处理错误的方法是在回复中包含错误消息。
service MyService {
rpc Query (stream QueryRequest) returns (stream QueryReply) {}
}
message QueryReply {
string id = 1;
repeated string kind = 2;
message DataList {
repeated string data = 1;
}
map<string, DataList> data = 3;
string error = 4;
}
我怀疑创建一个单独的消息可能更高效，这样一个错误消息就不必包含所有其他数据。但是，我不太愿意创建和同步多个消息，因为我不想增加太多复杂性。拆分消息可以获得哪些效率提升？有没有一种标准的做法（特别是在 Go 中）？
英文:
I have a gRPC endpoint that streams queries and results back and forth, and there will frequently be errors on the server side that I want to send back. My current approach to error handling is just including an an error message to the reply.
service MyService {
rpc Query (stream QueryRequest) returns (stream QueryReply) {}
}
message QueryReply {
string id = 1;
repeated string kind = 2;
message DataList {
repeated string data = 1;
}
map<string, DataList> data = 3;
string error = 4;
}
I suspect it would be more efficient to create a separate messages, so that an erroring message doesn't have to contain all that other data. I am hesitant to make and sync multiple messages because I don't want to add too much complexity. What efficiency can be gained from splitting up the message? Is there a canonical way of doing this (in go in particular)?
答案1
得分: 0
很可能将其拆分为protobuf并不真正更高效，因为protobuf不会发送空的（默认）字段。
因此，在设置error="foo"的情况下，基本上只有foo会被发送。
英文:
It's likely that it isn't really more efficient to split it up as protobuf doesn't send empty (default) fields.
so, in the case where you set error="foo"
basically only foo is sent on the wire.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论