关于protobuf:Proto-代码到底放哪里

48次阅读

共计 1443 个字符,预计需要花费 4 分钟才能阅读完成。

尽管公司曾经从大单体切换为微服务化有肯定的年头了,但一些细节方面的解决总会有不同的人有不同的认识,这其中一个探讨点,就是 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 代码涉略面还是比拟广的,多多少少都有人有不一样的认识。

正文完
 0