gRPC API体系结构建议

Question

现在我正在用Python开发微服务应用程序。

基本上它就像GUI -(gRPC)-> Server -(gRPC?)-> Workers。

GUI对服务器进行各种调用，例如，所有配置都存储在服务器上。为了性能和简单性，我决定使用#gRPC作为API传输。

我已经实现了客户端和服务器类，现在我有一个进退两难的问题：

1. 性能最佳实践告诉我们Always re-use stubs and channels when possible.。因此，我可以制作通用rpc通道，如：

UniMsg {
int32 id = 1;
string name = 2;
bytes data = 3;
}

在客户端打包数据
(在某些情况下，不可能在proto中创建完整的数据模式。例如，config被写为JSON以将其传输到GUI。我要么必须在proto中实现所有配置字段，这对我来说有点头疼，要么我可以将JSON编码为字节并以这种方式发送。它不会是透明的，但它将允许修改配置结构，而无需修改/编译protong编码的字节似乎明显更好的性能wize，我不需要序列化/反序列化它。(
，用name标记它，根据name字段在服务器端进行解压缩和处理。这重用了CCD_ 8，并将所需的CCD_
唯一的缺点是它有点不像RPC，更像data bridge。

2. 我可以创建几个services，但它们确实需要单独的stubs和整个数据描述。从API描述的角度来看，这是很好的(即，为了进一步扩展，不需要查看服务器/客户端的"黑盒"，只需查看原型文件并根据所描述的规则发送消息(，但由于我们使用了新的stubs，因此性能大小较低

syntax = "proto3";
message FilesAndFilters {
repeated string file = 1;
repeated string ext = 2;
}
message ResultList {
repeated string file = 1;
}
//   <ServiceName>
service FList {
// This is common method, it is described on server and called via stub on client.
// <MethodName>(<ParamRequest>)
rpc StreamFiles(FilesAndFilters) returns (ResultList);
}
message Settings {
int32 profile = 1;
bytes config = 2;
}
service CCConfig {
rpc StreamConfig(Settings) returns (Settings);
}

gRPC大师们的问题是：什么是保持一切透明、不言自明并保持性能的最佳中间立场。

请考虑一下，在某个时候可能会出现这样的争论，即我的应用程序负载很低，性能损失可以忽略不计。我在这里的目标是在将技术投入生产之前分享经验并了解所有的怪癖，所以同样的方法也可以用于高负载系统。

谢谢。

Answer 1

我想你可能误解了短语"尽可能重复使用存根和通道"本指南旨在避免重复拆卸和重新创建客户端通道，而不是将所有RPC服务合并为一个。

简而言之，选择选项#2。拥有多个服务是习惯做法，也是鼓励的做法。