定义 gRPC RPC

Posted 2023-02-16

【中文标题】定义 gRPC RPC

【英文标题】：Defining gRPC RPCs

【发布时间】：2018-09-12 15:09:14

【问题描述】：

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

假设有“n”个模型对象，例如路由器、接口、路由配置对象（例如 OSPF 等）。每个网络操作，例如最终对一个或多个模型对象进行 CRUD。

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

定义通用 gRPC RPC，如“SET”和“GET”。该参数将是对象和操作的列表。像 SET((router, update), (interface, update)..

定义非常具体的 RPC。像“setInterfaceProperty_x”、“createOSPFInstance”.. 这样的 RPC 可能有很多很多。

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

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

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

感谢您的宝贵时间。如果需要，我可以提供更多信息。

【参考方案1】：

您应该使用选项 #2。这会将您的接口合同放在原型中，而不是在您的应用程序中。选择第 2 项，否则会很麻烦或无法支持，从而为自己打开了许多大门：

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

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