标签 Google 下的文章

Go项目组织:在单一repo中管理多个Go module指南

本文永久链接 – https://tonybai.com/2023/05/10/a-guide-of-managing-multiple-go-modules-in-mono-repo

0. 单repo单module管理回顾

众所周知,Go在1.11版本中引入了go module,随着近几年Go module机制的逐渐成熟,它已经被Go团队确定为Go标准的依赖管理与构建方案,原先的GOPATH mode已经被彻底废弃。

在Go module模式下,最常见的Go项目组织方式就是一个repo(代码仓库)对应一个Go module。repo的根路径中放置go.mod文件,repo的根路径也是module root directory。该Go module下的package的导入路径则由go.mod中的module path以及该package相对于module root directory的路径共同构成。

以“example.com/go”这一module path为例,如果某个package存放在foo/bar下,那么bar下的package的导入路径就是“example.com/go/foo/bar”;如果是v2版本,那么导入路径为“example.com/go/v2/foo/bar”。

在一个repo对应一个Go module的策略下,Go module的版本管理和发布也相对容易,通常我们采用分支方式来进行major号升级(如下图),通过tag来进行版本发布

上图是单repo单module的分支管理方案,两种方案均可。

左侧的方案中:master分支承载v0-v1,每升级一个major号,建立一个vN分支,default分支指向最高major号的分支,方便开发者clone repo时直接拿到最新的代码。

注:左侧方案有一个问题,那就是一旦default分支执行最高major号分支vN,那么你如果要go get master分支的最近更新,需要显式指定master分支,比如: go get example.com/go/foo/bar@master。使用latest或不加任何分支名都无法获取到master上的最新更新。

右侧的方案也是建立vN分支,但不同的是,该方案会将master分支作为active开发分支,也是默认分支并定期将稳定后的feature同步到最高major号分支,这也是我个人比较喜欢的方式。前不久刚刚被官宣为redis官方Go客户端的go-redis采用的就是这个方案(下面是go-redis的vN分支情况):

注:在单一repo中管理一个go module的方法十分成熟了。我在专栏《Go语言第一课》的06和07讲对此做了系统的讲解,感兴趣的小伙伴可以去阅读一下。

有了单repo单module的项目组织方式,就会有单repo多module的组织方式,比如著名的etcd项目,就是在一个repo中管理多个go module的典型例子。

那么为什么要在一个repo中管理多个go module呢?我们继续往下看。

1. 为什么要在一个repo中管理多个Go module

其实这个问题的本质是monorepo与multiple repo之间的“战争”。那么上述问题也就变成了一个monorepo与multiple repo的优劣对比。我个人从未真正使用过monorepo这种所有项目代码都放在一个单一仓库中的组织形式,不过从网上的公开资料来看,monorepo有如下的一些优点:

  • 容易看到

如果你正在做一个调用其他微服务的微服务,你可以看一下代码,了解它是如何工作的,并确定bug是来自你自己的代码还是其他团队的微服务。

  • 代码共享

团队为微服务重复编写代码会产生额外的工作开销。有了monorepo,团队可以更容易地分享代码。

  • 改进协作

有了monorepo,就更容易在各团队之间实现代码和工具的标准化。

  • 标准化

单一代码仓库使得跨团队的代码和工具的标准化更加容易。

  • 可发现性

有了monorepo,更容易找到你需要的代码。

  • 发布管理

单一版本使我们更容易地管理跨多个服务的发布。

  • 更容易重构

重构代码在单版本中更容易,因为所有的代码都在一个地方。

当然,使用单一代码仓库也有一些缺点,这些缺点也足以让很多组织和开发团队对其望而却步:

  • 增加仓库的大小

一个单库通常会比只包含一个项目的版本库大。这可能会导致更长的构建时间和更多的磁盘空间使用。

  • 增加复杂性

单一代码仓库的管理比只包含一个项目的版本库更复杂。这是因为有更多的代码需要跟踪和管理。

  • 增加冲突的风险

当多个开发者在单一仓库中处理相同的代码时,会有更大的冲突风险。这是因为开发人员可能在同一个代码的不同版本上工作。

  • 不能限制访问

monorepo不允许有选择的分享。

  • 陡峭的学习曲线

当新的开发者开始与已经有monorepo的组织合作时,他们通常需要足够长的时间来适应所有紧密耦合的依赖关系。

总的来说,使用monorepo既有优点也有缺点,是否使用monorepo最终还是要取决于项目和团队的具体需求。

不过,monorepo下的多module是实际存在的,并且Google内部就是如此,显然go module也一定要对此做很好的支持的,下面我们就来看看go是如何支持mono repo下的多个go module的。

我们先来看看mono repo下各个go module的导入路径的确定。

2. monorepo中各个go module下的package的导入路径

在前面回顾单repo单module的项目组织方式下,module下的package的导入路径为:module path+package在module root directory下的相对路径。那么monorepo中各个go module下的package的导入路径又是什么呢?

首先monorepo下的各个go module的module root路径并非monorepo的root路径,以下面的结构举例;

example.com
└── go/
    ├── mqtt/
    │   ├── bar/
    │   │   └── go.mod
    │   └── foo/
    │       └── go.mod
    └── vehicle/
        ├── baz/
        │   └── go.mod
        └── zoo/
            └── go.mod

我们看到在example.com这个顶层目录下并没有go module,go modules分布在example.com下的各个子目录中。以mqtt/bar下的go module为例,它的module path应该为repo根路径+bar的相对路径,即example.com/go/mqtt/bar,这样bar下面的package pkg1,它的导入路径就为example.com/go/mqtt/bar/pkg1,如果bar这个go module升级到v2版本,则pkg1的导入路径就会变为example.com/go/mqtt/bar/v2/pkg1。其余的go module下的packge的导入路径以此类推。

3. monorepo下各个go module的版本发布

在单repo单module下,我们通过打vx.y.z标签的方式发布module,但是在monorepo多module下,再在repo上针对repo打整体的、诸如v1.0.1这样的标签就没有太大意义了(当然为了整体管理的需要,依然可以打整体标签,比如像etcd那样打v3.5.8),并且对于monorepo下的多个go module而言,go get也不会识别这种整体标签,那么我们该如何发布monorepo下的go module呢?

其实也很简单,我们为module单独打标签来发布。以上面的example.com/go/mqtt/bar这个module为例,如果我们要为其发布v1.0.0版本,我们需要为example.com这个repo打上tag:go/mqtt/bar/v1.0.0;如果它要发布v1.1.0版本了,我们则需为example.com这个repo打上tag:go/mqtt/bar/v1.1.0。也就是说要发布哪个module,就用module相对于monorepo根的相对路径+版本号作为tag号

4. monorepo下各个go module的major版本变更

了解了上述monorepo下各个go module的版本发布方式后,我们就可以将monorepo下的每个go module像单repo单module那样单独对待了!以example.com/go/mqtt/bar为例,当major版本变更时,我们可以建立类似go/mqtt/bar/v1分支,然后将master分支的go.mod中的module path改为example.com/go/mqtt/bar/v2,这样我们就可以在go/mqtt/bar/v1分支继续维护v1版本的bar module,并打tag:go/mqtt/bar/v1.x.y;在master分支维护v2版本的bar module,并打tag:go/mqtt/bar/v2.x.y。

当然go还支持另外一种major版本的维护方式,那就是通过目录隔离。当major版本要升级为v2时,我们可以在go/mqtt/bar下面建立v2目录(像v2这类目录被称为major version subdirectories),然后在v2目录下维护major为v2的版本,这种方式下你就无需建立vN分支了,可以在master上通过目录隔离的方式同时维护多个major版本。发布时,同样打go/mqtt/bar/v2.x.y标签。这种方式一个最大的好处就是与GOPATH mode可以“无缝衔接”,因为GOPATH mode下,go工具链就是通过路径查找package的。

不过这种major version subdirectories的方式并不常用,即便在开源项目中也是比较少见的。

5. 小结

本文介绍了go module的基础概念,回顾了单repo单module的包管理方法,包括版本发布、major号升级等。接下来,我们介绍了monorepo下管理多个go module的方案,除了在打tag时要注意带上相对路径外,monorepo下module的包管理方法与单repo单module本质上是一致的。

6. 参考资料

  • REPO STYLE WARS: MONO VS MULTI – https://gigamonkeys.com/mono-vs-multi/
  • Mono Repo vs Multi Repo: Deep Dive Into The Neverending Debate – https://speakerdeck.com/lemiorhan/mono-repo-vs-multi-repo-deep-dive-into-the-neverending-debate

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go为什么能成功

本文永久链接 – https://tonybai.com/2022/12/07/why-go-succeed


大家在入门Go语言时,多埋头于Go语法,忙于练手或快速完成公司的项目,无暇思考。

但当大家到了要进阶,要冲刺高级阶段的时候,我建议你不能再稀里糊涂了。既然入了Go这个坑,在进入高级阶段前,我们最好在门口的“影壁墙”前驻留一下。

仔细思考一下我们投入这么多精力研究的Go为什么能成功,后续还能否持续成功下去。你要有自己的基本的判断,自我暗示也好,坚定信心也罢,我们要为继续攀登Go高峰进行蓄能

一. 头脑风暴一下Go成功的因素

相信无论针对哪个gopher群体做头脑风暴,让大家列举Go成功的因素,大家的主流答案也无外乎下图中这些:

图中的各个因素与Go的成功都不无干系,但是究竟哪个或哪几个是决定性的呢?

二. Go成功的根本因素

很显然,这个问题是没有标准答案,是见仁见智的。这里我列举一下我的观点,供大家参考。

直接上结论,我认为Go成功的根本因素就一个:Google

为什么这么说呢?下面我们展开来看(见下图)!

我将Go社区比做一支军队,而Go就是Go社区的武器,与其他编程语言搏杀,占地盘(fans)。下面我们就来解构一下这支军队的构成以及为什么这支军队目前有诸多成功案例!

1. Google为Go社区提供了统帅与武器

众所周知,2007年Google的三名员工Robert Griesemer、Rob Pike和Ken Thompson(retire很早,精神上领袖,给予Go名誉上的背书)一起发明了Go语言,2009年Go开源后,Go社区逐渐形成。统帅是一支军队的灵魂,他们做出了影响Go和Go社区的最初的也是最重要的决策和这背后的Go设计哲学!

a) 设计决策

在2022年,Go团队在美国计算机学会通讯(Communications of the ACM)期刊上发表paper:《Go编程语言与环境》,对当年做出的诸多决策做了细致说明,这里对其中两个最重要的决策做简单说明:

  • Go旨在成为一个编程环境

Go语言之父们认为语言特性仅是编程语言的一部分,而编程环境特性与语言特性同等重要,这些环境特性包括:库、工具、惯例和针对软件工程的整体做法,它们都对使用Go语言编程提供了支持,不可或缺。而这些环境特性恰恰是在传统的编程语言设计中并没有受到应有的重视的。

这样的决策让Go在开源之初就为开发者提供了使用Go进行编程所需的几乎一切:包括功能丰富、开箱即用的标准库以及全面的工具集,代码格式化、代码静态检查、依赖关系管理、构建(包括跨平台交叉编译)、测试、性能剖析、查看和生成文档等,并且这些工具集在今天都统一放在了go命令的下面。这个决策也帮助Go在开源后吸引了第一批Go社区用户。

  • Go的一致性的表现

Go的一个目标是让它在不同的实现、执行环境中,甚至在不同的时间内表现出相同的行为。所以,Go语言尽可能地规定了一致的结果。比如:Go程序生命周期内一致的性能(相对于使用JIT慢启动的语言)、一致的GC的开销等。甚至对于最常见的编程错误提供了明确定义的语义,这有助于可理解性和调试,而不是像C/C++中那样,充斥着各种未定义的行为。

而我认为最重要的一致性则是从2012年发布的Go 1.0开始,Go团队公开承诺只对语言和标准库进行向后兼容的修改,这样程序在编译到较新的Go版本时可以继续运行而不发生变化。这一承诺对业界产生了吸引力,它不仅鼓励了那些长声明周期的工程项目(比如Google内部的一些大型项目或者像Kubernetes这样的社区顶级项目),也鼓励了其他努力,如书籍、培训课程和第三方软件包的繁荣生态系统。这一一致性的决策也为Go招募了相当数量的拥趸。 Go1兼容性,同样可以避免社区分裂(像python2/python3那样),即便是10多年来变更最大的泛型语法落地,也没有违反Go1兼容性,这实属不易。

b) 设计哲学

上述的设计决策的背后蕴含着Go语言之父们的设计哲学。

  • 简单

Tony Hoare在1980年图灵奖演讲中说了这样的观点:“我的结论是,构建软件设计有两种方法:一种方法是让它变得如此简单,显然没有缺陷,另一种方法是让它变得如此复杂,以至于没有明显的缺陷。第一种方法要困难得多。它需要同样的技能,奉献,洞察力,甚至灵感,就像发现作为自然复杂现象基础的简单物理定律一样。它还要求愿意接受受物理,逻辑和技术限制的目标,并在无法实现冲突目标时接受妥协。”

Go选择的正是Tony Hoare演进中的第一种构建软件的设计方法。Rob Pike说过的一句Go流行谚语“less is exponentially more”与此异曲同工。Go的语法简单,API简单,这些为Gopher提供了极大便利,但这些简单的背后其实是Go团队长时间的复杂的思考与实现,努力将语法和API简化为最小、最有用、最接近本质的努力工作。

同时,简单意味着可读性、可维护性,意味着代码的清晰。另一句Go谚语“Clear is better than clever”告诫Gopher们编写平淡如水的Go代码才是“政治正确”的,不要炫技。

  • 并发

多核时代,Go将并发作为语言内置特性。Go内置并发原语,包括goroutine、channel、select等。

Go鼓励在较高级别使用并发性,特别是通过通信的方式。我们耳熟能详的一句Go谚语是“Don’t communicate by sharing memory. Share memory by communicating”就是并发哲学的外在体现。

  • 组合

Go拥有类型,类型可以有method,这似乎像是一种面向对象style的实现,但Go并没有OO语言那种类型层次体系(type hierarchy),在Go中,组合才是Go类型之间建立联系的最主要手段,而interface和类型嵌入恰是这种组合哲学的具体体现。

  • 面向工程

2012年, Go开源元年,Rob Pike就在SPLASH 2012大会上以“Google的Go:为软件工程服务的语言设计”为题,讲解了Go是如何围绕Google内部存在的软件工程问题进行有针对性的语言设计的。可以看出,Go从诞生伊始就将解决软件工程领域问题作为语言的目标。同时,我们看到面向工程这个哲学与上面的旨在成为一个编程环境的决策息息相关。

除了统帅之外,Go社区的治理架构也是以Google“将领”为核心的,我们继续来看。

2. Google出钱:以Google“将领”(googler and ex-googler)为核心的Go社区治理架构

Go开源10年了,Go社区形成了以Googler和ex-googler(前google员工)为核心的Go社区治理架构,这些人就是上图中的那些“将领”,他们是Go项目某个细分领域,比如:编译器、运行时goroutine调度、GC、内存管理、网络、安全等的领头人。根据Go项目一名产品经理的描述:2021年,Google Go项目的专职人员多达50多人,Google这个“亲爹”在金钱的投入上显然表现的十分大方,不得不承认:在编程语言领域里,有个有钱的“亲爹”就是好

这种以googler和Ex-googler为开源社区治理核心的架构决定了Go社区采用的是一种我称之为“民主集中制”的决策机制。在Go社区你不要幻想会有绝对的公平投票,Go项目决策向来是由少数Googler和ex-googler主导的。这样意味着很多情况下,核心治理团队的人提出的proposal以及Google内部gopher提出proposal很容易被accept,而来自外部社区的proposal要想被accept,可能难度就要大一些。怎么说呢?Google的方案不一定总是最好的,但我们也不能不承认多数情况下,Googler提的proposal还是更优的,并且通常这些proposal对应的实现都已经在google内部测试过了,甚至和Go决策组在公司内部“吹过风”,如果你是Go社区的决策人,你会怎么做呢?你是更相信Googler还是外部一个没有任何背景的gopher呢?

我觉得在Google依然引领IT前沿的今天以及未来若干年,这种机制可能还是有利于Go的蓬勃发展的。

3. Google为Go社区提供战场/试验场

就像上面所说的那样,Go是有着非常鲜明Google烙印的编程语言,除了Go语言之父都来自google,Go社区治理架构的核心都来自Google和前google员工外,Google内部为Go的设计提供了足够的一流的问题域,也为Go的真实应用提供了试验场和真实战场,即便Go至今没有成为Google内部的第一语言。面向Google的一手且一流问题域,让Go设计者和Go开发者能够获得一手的反馈,从而对Go做进一步的打磨。

举几个例子:

  • Google内部的单一代码仓库让Go最初设计了不带版本的go get(后在社区的强烈要求下引入了go module,go get才支持版本号);
  • googler反馈,google内部工具超好用,这一定程度让Go团队认识到向Gopher提供完善的go工具链的重要性;
  • Google内部的多核与网络服务让Go设计者决定内置原生goroutine以应对多核时代的应用开发;
  • Google内性能与开发效率并重让Go设计者决定设计一门带gc的静态编程语言,将内存管理、并发管理下沉到runtime,这与近两年出现的服务网格, dapr等概念的思路一致;

  • Google内部大规模人员协作让Go决定面向软件工程,不仅要设计好语言特性,还要提供体验良好的编程环境(工具链、标准库等);
  • Google超大规模的系统构建慢让Go决定提供快速的构建能力,为此对包格式与包依赖做了精心的设计;
  • Google内部长期维护的系统(生命周期长) 让Go团队决定支持Go1兼容性并提供支持重构的语法,比如type alias等;
  • Google认为安全十分重要,促使Go提供了go sumdb和对sbom的良好支持;

同时Google内部系统为了支持Go的内部试验也是不遗余力,比如:每当Go发布大版本的RC版本,甚至是Beta版本时,Google App Engine都会首当其冲的充当“小白鼠”,在生产环境支持尚未发布正式版的Go。

另外Google在业内的领先性也让“近水楼台”的Go受益,比如像容器调度编排这样的平台,Google十年前就有了(borg),后续Googler以另起开源项目的方式将其中经验外溢输出,让Kubernetes最终选择了Go作为开发语言,从而成为Go的最大的也是最典型的成功战例。

综上,我们看到Google对Go成功的决定性作用,这种作用可决不能被理解为简单的金钱上的支撑。

三. Go语言演进历史

进入Go高级阶段后,对Go语言的演化历史要知道,当然能做到如数家珍更佳,即便不能,也要能记住Go语言的主要演化历史:

  • 2007年9月,Go语言诞生;
  • 2009年11月,Go正式开源;
  • 2012年3月,Go 1.0发布,同时Go1兼容性承诺官宣;
  • 2014年12月,Go 1.4版本发布,这是最后一个编译器和runtime由C语言实现的版本;
  • 2015年8月,Go 1.5版本发布,这个版本Go实现了自举(用go编译go),同时编译器和runtime中的绝大部分c代码都换成了go,新版gc让延迟大幅降低;
  • 2018年8月,Go 1.11版本发布,go module被正式引入;
  • 2022年3月,Go 1.18版本发布,Go泛型语法正式落地。

四. 小结

C++之父说过:“世上只有两种编程语言:一种是总是被人抱怨的,一种是从来没人用的”。

Go属于前者。世界上没有完美的编程语言,Go经过十年的打磨已经有了长足的进步,并且取得了不错的战绩,尤其是在云基础设施和云原生因公领域,就连Rob Pike也承认Go确实已成为云基础架构的语言。而这个Go走向成功的过程中,Google起着根本性的作用。

不过中国古语有云:成也萧何,败也萧何!目前Google仍然引领IT技术前沿,这对Go的发展来说是一个利好,也会不断推动Go向着好的方向发展。

但我大胆预测一下:“成也Google,败也Google”,一旦Google开始走下坡路的那天,Go语言成功的根基就不在了,Go还能像今天这样顺风顺水么?如果Go社区治理结构不重构,很可能不会再有今天这样的良好状态。大家觉得呢?

五. 参考资料

-《Go编程语言与环境:万字长文复盘导致Go语言成功的那些设计决策
-《Go内存模型》- https://research.swtch.com/gomm
-《Go语言真正的问题》 – https://vanitynotes.com/posts/20221101-the-real-problem-with-go


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文
章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必>答保证等满足你关于Go语言生态的所有需求!2022年,Gopher部落全面改版,将持续分享Go语言与Go应用领域的知识、技巧与实践,并增加诸多互
动形式。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats