真是头疼,Proto 代码到底放哪里?

时间:2022-04-20 23:37:27

真是头疼,Proto 代码到底放哪里?

大家好,我是煎鱼。

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

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

实施方案

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

一共有如下几种方案:

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

方案一:存放在代码仓库

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

真是头疼,Proto 代码到底放哪里?

缺点

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

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

优点

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

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

方案二:独立仓库

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

真是头疼,Proto 代码到底放哪里?

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

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

真是头疼,Proto 代码到底放哪里?

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

缺点

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

优点

  • 使得安全性较高(但 IDL 本身没有太多的秘密)。
  • 按需拉取,不需要关注其余的服务 Proto。

方案三:集中仓库

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

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

真是头疼,Proto 代码到底放哪里?

缺点

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

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

优点

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

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

方案四:镜像仓库

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

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

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

真是头疼,Proto 代码到底放哪里?

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

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

方案五:其他

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

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

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

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

小结

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

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

原文链接:https://mp.weixin.qq.com/s/cBXZjg_R8MLFDJyFtpjVVQ