定义gRPC RPC

Question

我在这里找些建议。usecase是一个网络设备(如路由器)，它通过gRPC执行网络操作。

假设有"n“模型对象，如路由器、接口、路由配置对象(如OSPF )等。每一次网络操作，比如最后是一个CRUD on或许多模型对象。

现在，当在gRPC服务上定义它时，似乎有两个选项：

1. 定义通用的gRPC gRPC，如"SET“和"GET”。该参数将是对象和操作的列表。像SET(路由器，更新)，(接口，更新)..。
2. 定义非常具体的RPC。比如"setInterfaceProperty_x"，“createOSPFInstance”。而且可能有许多这样的RPC。

使用#2，我们正在构建RPC本身的应用程序智能。每个新特性都可能需要此服务中的新RPC。

对于#1，RPC是手段，但是智能驻留在在上下文中使用RPC的应用程序中。RPC列表将是非常少的，不会随着时间的推移而改变。

首选的方法是什么？通用RPC(并保持它非常少)或有数十(或更多)操作驱动RPC？我看到了一些开源项目，比如P4Runtime采用第一种方法。

耽误您时间，实在对不起。如果需要，我可以提供更多的信息。

Answer 1

您应该使用选项2，这将您的接口契约放在proto中，而不是在应用程序中。如果选择第二种选择，你会留下许多敞开的大门，否则会很麻烦或无法承受：

• 如果对象的API定义与内部表示不匹配，则需要定义两者之间的映射。假设您更新了您的内部代码，不再需要InterfaceProperty，而是将它移到一个名为BetterInterfaceProperties的新字段中。选项一将迫使您保持旧字段公开，而选项2将允许您重新解释调用并做正确的事情。
• 使用特定的方法，细粒度的访问控制更容易。所有用户都可以设置publicProperty，但只有管理员才能设置dangerousProperty。通过将所有字段分组到单个调用中(如#1中所示)，调用方必须重新解释错误消息，而选项2则更清楚授权失败的原因。
• 返回值较小。拥有像getSpecificProperty这样的方法比getFullObject做的工作要少得多。随着数据模型变得越来越复杂，您将不得不在返回消息中包含越来越多的数据。即使打电话的人只关心一件事，他们也得等待所有的事情。考虑一个数据库应用程序。数据库可能需要执行几个不必要的查询，以填充客户永远不会读取的字段。

使用#1是有原因的，但在您确定哪些属性在一起并在逻辑上是一个RPC之前，它们并不那么有价值。(如Get)