【问题标题】:How to release changes to shared .proto files in a Git proto repo?如何在 Git proto 存储库中发布对共享 .proto 文件的更改?
【发布时间】:2021-02-19 14:32:04
【问题描述】:

共享协议缓冲区的常见策略似乎是将这些文件存储在多个答案所建议的单独 Git 存储库中:

所以我决定建立这样一个结构,但是在建立部署时卡住了。

我现在的情况

我有一个名为magic-service 的服务,它实现了一个存储在proto-repo 中的.proto 文件。所以magic-service repo 不存储自己的 proto 文件,而是在构建服务时获取它。

现在我想为magic-service 发布一个新功能,但这需要先更新 .proto 文件。但是,在实现可用之前,当然不能更新公共 protobuf 文件。这是一个循环依赖。

问题

如何安全地部署我的服务,而无需先发布其 proto 文件?

我认为这是一个常见问题,但我找不到任何相关信息。欢迎任何建议或资源!

【问题讨论】:

    标签: microservices protocol-buffers grpc rpc


    【解决方案1】:

    我们在一个 Go 语言项目中使用了类似的结构。我们在 Git 上有一个 proto 存储库,其他项目正在使用 proto 存储库中的这些 proto 文件。

    其他项目不是在 Git 中引用最新的 proto 文件,而是在 Git 中引用具有特定标签(版本)的 proto 文件。因此,我们从未遇到过这种循环依赖问题。可能这个解决方案对你有帮助。

    【讨论】:

      【解决方案2】:

      在分布式系统中更新 proto 文件肯定需要一些技巧。

      一种策略(在另一条评论中提到)是使用发布。这样一来,您就可以让服务器发布比客户端更新的版本。

      另一种选择是通过文档解决这个问题。事实上,原型文件可以在实现部署并可用之前发布。在较大的系统中,最好在评论中将该字段标识为尚不可用。

      已由编组器设置但解组器不知道的字段被视为“未知”字段。更新必须小心协调,以确保更改不会向后或向前不兼容。

      • 向后不兼容的更改意味着该类型的旧版本不能用于解组该类型的新版本生成的消息。
      • 转发不兼容的更改意味着该类型的新版本不能用于解组该类型的旧版本生成的消息。

      有关更新原型类型的更多信息,请参阅文档。

      https://developers.google.com/protocol-buffers/docs/proto3#updating

      例如,添加新字段的典型流程可能遵循以下模式:

      1. 向 proto 文件添加一个新字段并将其记录为不可用。
      2. 更新阅读代码以了解如何阅读新字段。
      3. 删除有关其可用性的文档。
      4. 更新编写代码以了解如何编写新字段。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-10-03
        • 2022-06-11
        • 2011-11-08
        • 1970-01-01
        • 2012-02-11
        • 1970-01-01
        • 2017-05-02
        • 1970-01-01
        相关资源
        最近更新 更多