定义gRPC RPC

Question

我在这里寻找一些建议。用例是一个网络设备（如路由器），通过gRPC执行网络操作。

假设存在“n”模型对象，如路由器，接口，路由配置对象，如OSPF等。每个网络操作，最后都是一个CRUD on或许多模型对象。

现在，在通过gRPC服务定义时，似乎有两个选项：

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

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

对于＃1，RPC是手段，但智能驻留在上下文中使用RPC的应用程序。 RPC列表只是极少数，并且不会随时间而变化。

什么是首选方法？通用RPC（并保持很少）或有几十（或更多）操作驱动的RPC？我看到一些像P4Runtime这样的开源项目采取方法＃1。

谢谢你的时间。如果需要，我可以提供更多信息。

Answer 1

你应该使用选项＃2。这会将您的接口合同放在proto中，而不是在您的应用程序中。通过选择那些麻烦或不受支持的选项＃2，你可以让自己多开门：

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

有理由使用＃1，但在确定哪些属性在一起并且逻辑上是单个RPC之前它们没有那么有价值。 （比如Get）