问题描述
共享协议缓冲区的常见策略似乎是按照多个答案的建议将这些文件存储在单独的 Git 存储库中：
- Where to store proto files which are shared among projects?
- How to share Protobuf definitions for gRPC?
- How to Maintain Proto Files?
所以我决定建立这样一个结构，但在设置部署时卡住了。
我现在的情况
我有一个名为 magic-service 的服务，它实现了存储在 .proto 中的 proto-repo 文件。因此，magic-service 存储库不存储自己的 proto 文件，而是在构建服务时获取它。
现在我想为 magic-service 发布一项新功能，但这需要先更新 .proto 文件。但当然，公共 protobuf 文件在实现可用之前是无法更新的。这是一个循环依赖。
问题
如何安全地部署我的服务而不必先发布其 proto 文件？
我认为这是一个常见问题，但我找不到任何相关信息。欢迎任何建议或资源！
解决方法
我们在一个 Go 语言项目中使用了类似的结构。我们在 Git 上有一个 proto 存储库，其他项目正在使用 proto 存储库中的这些 proto 文件。
其他项目不是在 Git 中引用最新的 proto 文件，而是在 Git 中引用具有特定标签（版本）的 proto 文件。因此，我们从未遇到过这种循环依赖问题。也许这个解决方案可以帮助你。
,在分布式系统中更新 proto 文件肯定需要一些技巧。
一种策略（在另一条评论中提到）是使用发行版。这样，您可以让服务器遵循比客户端更新的版本。
另一种选择是通过文档解决这个问题。事实上，Proto 文件可以在部署部署并可用之前发布。在更大的系统中，最好在评论中将字段标识为不可用。
已由编组器设置但解组器不知道的字段被视为“未知”字段。更新必须小心协调，以确保更改不会向后或向前不兼容。
- 向后不兼容的更改意味着旧版本的类型不能用于解组由新版本的类型生成的消息。
- 转发不兼容的更改意味着该类型的新版本不能用于解组由该类型的旧版本生成的消息。
有关更新原型类型的更多信息，请参阅文档。
https://developers.google.com/protocol-buffers/docs/proto3#updating
例如，添加新字段的典型流程可能遵循以下模式：
- 向 proto 文件添加一个新字段并将其记录为不可用。
- 更新阅读代码以了解如何阅读新字段。
- 删除有关其可用性的文档。
- 更新编写代码以了解如何编写新字段。