大家好，我是煎鱼。

虽然我朋友他们已经从大单体切换为微服务化有一定的年头了，但一些细节方面的处理总会有不同的人有不同的看法。

而且时不时就会有人出来反复问，这其中的一个重要讨论点，就是 Proto 这个 IDL 的代码到底放在哪里？

实施方案

经过多轮讨论对 Proto 的存储方式和对应带来的优缺点。

一共有如下几种方案：

• 代码仓库。
• 独立仓库。
• 集中仓库。
• 镜像仓库。

方案一：存放在代码仓库

直接将项目所依赖到的所有 Proto 文件都存放在 proto/ 目录下，不经过开发工具的自动拉取和发布：

缺点

1. 项目所有依赖的 Proto 都存储在代码仓库下，因此所有依赖 Proto 都需要人工的向其它业务组 “要” 来，再放到 proto/ 目录下，人工介入极度麻烦。

2. Proto 升级和变更，经常要重复第一步，沟通成本高。

优点

1. 项目所有依赖的 Proto 都存储在代码仓库下，因此不涉及个人开仓库权限的问题。

2. 多 Proto 的切换开销减少，因为都在代码仓库下，不需要看这看那。

方案二：独立仓库

独立仓库存储是我们最早采取的方式，也就是每个服务对应配套一个 Proto 仓库：

这个方案的好处就是可以独立管理所有 Proto 仓库，并且权限划分清晰。但最大的优点也是最大的缺点。

因为一个服务会依赖多个 Proto 仓库，并且存在跨业务组调用的情况：

如上图所示，svc-user 服务分别依赖了三块 Proto 仓库，分别是自己组的、业务组 A、业务组 B 总共的 6 个 Proto 仓库。

缺点

1. 假设你是一个新入职的开发人员，那么你就需要找不同的业务组申请不同的仓库权限，非常麻烦。如果没有批量赋权工具，也没有管理者权限，那么就需要一个个赋权，非常麻烦。
2. 在运行服务的时候，你需要将所有相关联的 Proto 仓库拉取下来，如果没有工具做半自动化的支持，麻烦程度无法忍受。

优点

1. 使得安全性较高（但 IDL 本身没有太多的秘密）。

2. 按需拉取，不需要关注其余的服务 Proto。

方案三：集中仓库

集中仓库也是一些公司考虑的方式之一，是按公司或大事业部的维度进行 Proto 代码的存储。

这样子只需要拉取一个仓库，就可以获取到所有所需的 IDL：

缺点

1. 安全性下降，因为其它业务组的 IDL 也全都 “泄露” 了。

2. 非按需拉取，在查看原始文件时，需要关注一些多余的。

优点

1. 只需要拉取一次 Proto 仓库就可以轻松把一个服务所需的 IDL 集齐。

2. 仓库权限管理的复杂度下降。

方案四：镜像仓库

结合上面几种方案的特点，我们也可以得出镜像仓库的方式。

也就是自己服务的 Proto 文件存放在代码仓库的 proto 文件中，在本次 feature 提交或发布后，自动同步到镜像仓库去。

你所依赖的其他服务 Proto 则直接通过读取集中的镜像仓库的方式获取：

这样子的话，通过开发工具的配合，开发人员在开发时就只需要关注自己项目的 Proto 就好了。

集中的镜像仓库主要用于构建和部署，大幅度降低了多 Proto 的关注和切换开销。

方案五：其他

本质上上述的所有方案多多少少都有一些利弊存在，并且都需要开发工具来进行支持，否则实操起来还是非常麻烦。

如果想一劳永逸，可以通过云开发环境来解决，因为在分配云开发机时，你已经有了身份认证，你能够拥有什么权限，不能拥有什么权限，基本都是明确的。

所以一般在组内、跨组联调时，也可以直接调度，不需要像其它方案那样进行过多的关注，甚至在自己本地运行一套微服务。

这需要大量的工具/资源支持，也需要研发有一定规模才能做。

小结

在本文中我介绍了比较常见的 5 种 Proto 代码的管理方式，其各有利弊，不同公司不同人的理解或适配度都不一样。

大家可以根据实际环境进行选用，并且建议拉上核心的人员进行讨论和选型，因为 Proto 代码涉略面还是比较广的，多多少少都有人有不一样的看法。

你是怎么解决的，欢迎在评论区交流和留言：）

你好，我是煎鱼，出版过 Go 畅销书《Go 语言编程之旅》，再到获得 GOP（Go 领域最有观点专家）荣誉，点击蓝字查看我的出书之路。

日常分享高质量文章，输出 Go 面试、工作经验、架构设计，加微信拉读者交流群，和大家交流！