本文转载自微信公众号《我的大脑是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。大家好，我是炸鱼。虽然我的朋友们从大单体转向微服务已经有一定年头了，但总会有人对一些细节有不同的看法。而且时不时会有人出来反复问，其中一个重要的讨论点就是Proto的IDL的代码放在哪里？经过几轮讨论实现方案，Proto的存储方式和对应关系的优缺点。有以下几种解决方案：代码仓库。独立仓库。集中仓库。镜像仓库。方案一：存入代码仓库，直接将项目依赖的所有Proto文件存入proto/目录，无需开发工具自动拉取和发布：缺点：项目所有依赖的Proto都存入代码仓库，所以所有对Proto的依赖都需要手动向其他业务组“请教”，然后放到proto/目录下。人工干预极其麻烦。Proto的升级和变更往往要重复第一步，沟通成本高。优点：项目所有依赖的Proto都存放在代码仓库中，不存在个人开库权限问题。减少了多个Proto的切换开销，因为它们都在代码仓库下，不用到处找。方案二：独立仓库独立仓库存储是我们最早采用的方式，即每个服务对应一个Proto仓库：这种方案的好处是所有的Proto仓库都可以独立管理，权限划分清晰。但最大的优势也是最大的劣势。因为一个服务会依赖多个Proto仓库，存在跨业务组调用的情况：如上图，svc-user服务依赖三个Proto仓库，分别是自己组、业务组A、和业务组B.6个原始存储库。缺点假设你是一个新开发者，那么你需要找不同的业务组去申请不同的仓库权限，非常麻烦。如果没有批量授权工具，没有管理员权限，那就需要一个一个授权，很麻烦。运行该服务时，您需要下拉所有关联的Proto存储库。如果没有半自动支持的工具，麻烦的程度是无法忍受的。优点安全性高（但IDL本身没有太多秘密）。按需拉取，无需关注服务Proto的其余部分。方案三：集中仓集中仓也是一些公司考虑的方法之一，就是按照公司或者大业务部门的维度来存放Proto代码。这样只需要拉取一个仓库就可以得到所有需要的IDL：缺点是安全性降低，因为其他业务组的IDL也全部“泄露”了。非点播拉取，查看原文件时，需要注意一些冗余。好处是只需要拉一次Proto仓库，就可以轻松收集一个服务需要的IDL。降低仓库权限管理的复杂度。方案四：镜像仓库结合以上方案的特点，我们也可以得出镜像仓库的方式。即把自己服务的proto文件存放在代码仓库的proto文件中。该功能提交或发布后，会自动同步到镜像仓库。你所依赖的其他服务的Proto是通过读取集中镜像仓库直接获取的：这样通过开发工具的配合，开发者在开发时只需要关注自己项目的Proto即可。集中镜像仓库主要用于构建和部署，大大减少多个Proto的注意力和切换开销。方案五：其他从本质上讲，上述所有方案都各有优缺点，都需要开发工具来支持，否则在实践中会很麻烦。如果想一劳永逸，可以通过云开发环境来解决，因为你分配云开发机器的时候，你已经有了身份认证，能有什么权限，不能有什么权限，基本都是清除。所以，一般情况下，组内联调或者跨组联调的时候也可以直接调度，不需要像其他方案那样关注太多，甚至可以在本地跑一套微服务。这需要大量的工具/资源支持，也需要一定规模的研发。小结在这篇文章中，我介绍了五种常见的Proto代码管理方式，每种方式各有优缺点，不同的公司和不同的人有不同的理解或适应。大家可以根据实际环境选择，建议邀请核心人员一起讨论选型，因为Proto代码涉及的范围比较广，或多或少会有不同的意见。
