更改服务定义后更新 grpc 服务器或客户端实现

Question

假设您已经完成了制定服务定义、生成服务器和客户端存根并实现它的整个过程。如果您对服务定义进行了更新，修改了方法并添加了新方法。例如，我是否需要重新生成服务器的存根，然后将未更改的实现从旧版本的代码复制到新的存根，或者是否有更好的方法？

最近发现了 gRPC，如果这是一个愚蠢的问题，我深表歉意。

只是对更新定义和无缝更新实现的理想流程有疑问

Answer 1

几乎所有更改（例如，

package

、

service

、

rpc

、

message

类型）都需要重新生成存根，以便客户端和服务器实现可以反映这些更改；如果你添加例如a

rpc

，在代码中使用它的唯一方法是重新生成存根。

一般过程是，您的构建过程将由 protobuf 更改触发，以重新生成存根（通常在同一个存储库中）并向实施者发出信号¹有新版本可用。

Protobuf 的设计包含向后和向前兼容的功能。只要您遵守最佳实践，使用非当前版本中的存根的客户端|服务器将继续能够生成|消费消息（来自当前客户端|服务器），尽管没有看到任何添加（例如添加了

rpc

，

message

或字段）。

message

的组织字段，但与其他编译代码一样，

message

和字段名称不 包含在在线（二进制|序列化）消息中。二进制消息使用模式和二进制消息的字段编号来反序列化

message

。因此，只要类型和字段编号

不

更改，就可以（尽管不建议）重命名 message 和字段。

一个很好的资源是协议缓冲区向后和向前兼容性的最佳实践

¹ 通过手动推送（例如电子邮件）或自动拉取（例如 Go 模块更新可用）。