dubbo-go v3 版本 go module 踩坑记

喜欢ヅ旅行 2022-10-17 00:48 128阅读 0赞

![头图.png][.png]

作者 | 董剑辉、盛傲飞  
来源 | [阿里巴巴云原生公众号][Link 1]

# 问题背景 #

该问题源于我们想对 dubbo-go 的 module path 做一次变更，使用 `dubbo.apache.org/dubbo-go/v3` 替换之前的 `github.com/apache/dubbo-go`。  
  
首先，我们做了路径映射，在 dubbo.apache.org 下放置了一个 **dubbogo/v3** 文件，内容如下：

<html>
      <head>
        <meta name="go-import" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go>">
        <meta name="go-source" content="dubbo.apache.org/dubbo-go/v3 git <https://github.com/apache/dubbo-go/tree/3.0{/dir}> <https://github.com/apache/dubbo-go/blob/3.0{/dir}/{file}#L{line}>">
        <meta http-equiv="refresh" content="0; url=https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3">
      </head>
      <body>
        <p>Redirecting to <a href="<https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3>">pkg.go.dev/dubbo.apache.org/dubbo-go/v3</a>...</p>
      </body>
    </html>

其次，我们修改了 go.mod 的 module 和对应的所有 import，并修改了所有子模块引用 dubbo-go 使用的 module 路径。

# 问题分析 #

在做完上述的修改后，我们提 PR 时，发现 CI 失败，经过进一步的日志排查，我们确定是 CI 在跑集成测试时发生了错误，具体的错误提示信息如下：  
  
![1.png][]

这一段的执行逻辑是希望利用 docker 对 dubbo-go 中的集成测试内容构建镜像，并启动容器进行测试，该镜像打包所用的 Dockerfile 路径在 `github.com/apache/dubbo-go/test/integrate/dubbo/go-server` 目录下，对照错误日志的 STEP 标识，我们可以定位到具体错误发生下面的两个步骤：

# ...
    
    # STEP 9
    RUN test ${PR_ORIGIN_REPO} && go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/{PR_ORIGIN_REPO}@${PR_ORIGIN_COMMITID} || go get -u dubbo.apache.org/dubbo-go/v3@develop
    
    
    # ...
    
    
    # STEP 11
    RUN go mod tidy && go install github.com/apache/dubbo-go/test/integrate/dubbo/go-server

在 STEP 9 中，我们使用 `go mod edit -replace` 替换了 dubbogo 的依赖路径，将其替换为发起 PR 请求的仓库地址和 commit id。在此基础上，当镜像构建跑到 STEP11 ，尝试使用 `go mod tidy` 拉包时发生了错误。  
  
回过头查看错误日志，我们可以发现：  
  
![2.png][]

由于我们只指定了 commit id，因此在 go mod 实际运行过程中，它会为我们生成一个假定版本号（关于假定版本号的更多说明可以查看本文最后的**问题拓展**），这个假定版本号抓取远程仓库的最新有效 tag 为 v1.4.1【注：此处远程仓库为 github.com/Mulavar/dubbo-go，这是我自己的 dubbo-go 分支，该分支拉取 fork 的时间比较早，其最后 tag 是 v1.4.1】，并自增为 v1.4.2，主版本是 v1。但在先前，我们的 dubbogo module path 是声明为 `dubbo.apache.org/dubbogo/v3`，主版本是 v3，这导致了 `go mod edit -replace` 前后的依赖主版本分别是 v3 和 v1 ，出现了不一致，实际拉取 dubbogo 依赖的时候出错。

# 问题解决 #

在问题分析一节中我们定位到这个问题在镜像构建的 STEP 9，即：

# STEP 9
    RUN test ${PR_ORIGIN_REPO} && go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/{PR_ORIGIN_REPO}@${PR_ORIGIN_COMMITID} || go get -u dubbo.apache.org/dubbo-go/v3@develop

这一步，我们使用 `go mod edit -replace` 时**将一个 v3 版本的 go module 替换成了一个 v1 版本的 module，导致主版本不一致发生错误**，因此我们只需在替换依赖路径时指定替换后的 module 主版本也为 v3 即可，我们在 g`o mod edit -replace` 后的模块依赖路径后也加上 v3 后缀如下所示。  
  
修改前：  
  
`go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/{PR_ORIGIN_REPO}@${PR_ORIGIN_COMMITID}`  
  
⇒ 修改后：  
  
`go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/${PR_ORIGIN_REPO}/v3@${PR_ORIGIN_COMMITID}`  
  
修复该问题后我们提交代码查看 CI，在 STEP 8 打印的日志信息中，可以看到替换后的 dubbogo 路径多了 v3，并且在拉包的时候跟的版本号（`v3.0.0-20210509140455-2574eab5ad0b`）主版本同样是 v3，成功拉取了依赖。

![3.png][]

# 问题拓展 #

## 1. Semantic Import Versioning ##

在我们使用 Go modules 去构建项目的依赖关系时，对 go 项目的依赖都需要声明我们所使用的版本号，考虑到每次发布新版本时，兼容一直是开发者最为重视和头痛的问题，因此 go 通过\*\*语义导入版本控制（Semantic Import Versioning）\*\*来制定版本号的标准，来确保每个开发者能够根据自己的项目需求指定使用的依赖版本。根据 go 的语义导入版本控制准则，版本号由三部分构成：  
  
![4.png][]

> 注：上图及以上部分内容参考自《Go Modules 详解》一文。

其中 **Major version** 表示这是一个新的大版本，甚至这个新版本可能和旧版本是不兼容的。  
  
而 **Minor version** 则表示这是一个大版本中的迭代，主要用于新增 feature 时递增。  
  
**Patch version** 则是粒度最细的版本更新，表示一些 bug 的修复。  
  
而指定主版本则有两种方式，一种是如上的直接声明，另一种则是在项目路径的最后加上版本后缀，如 dubbogo 3.0 版本声明的 module 则是 `dubbo.apache.org/dubbo-go/v3`，其中 v3 就是一个主版本的声明。

## 2. pseudo-version ##

Go 在使用依赖时推崇我们指定明确的版本号，比如 dubbogo 的 go.mod 中声明的对 `cloud.google.com/go` 的依赖：  
  
![5.png][]

但考虑到在某些场景下，我们想要使用模块依赖的某个未发版的版本（该模块只有一个已知的 commit id），如 dubbogo 声明的 `github.com/Microsoft/go-winio` 依赖，就可以使用一个假定版本号（`pseudo-version`）去替代真实的版本号。假定版本号的格式为：

// (1) vX.0.0-yyyymmddhhmmss-abcdef123456
    // (2) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456
    // (3) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456+incompatible
    // (4) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456
    // (5) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456+incompatible

可以看到 `pseudo-version` 被短斜杠分为三部分，其中第一部分 X.Y.Z 与 4.1 节提到的一致，分别是 `major version`、`minor version`、`patch version`，而第二部分是一个格式为 yyyymmddhhmmss 的时间戳，第三部分是一个 12 位的 commit hash，可以手动指定，如果没有，则由 go 自动生成。  
  
关于 `pseudo-version`，go 的生成规则如下：

*  查询该项目对应主版本（若项目依赖路径没有显式的 v2/v3 后缀，则默认为 v1 版本）的最新 tag。
 *  有 tag 则使用最新 tag 递增 patch version。
 *  无 tag ，根据项目路径带的后缀版本号自动生成（如 v3 则自动生成一个 3.0.0 开头的 `pseudo-version`）。

遵循这个规则，回头看前文的问题分析和问题解决，我们就可以明白为什么在一开始 dubbo-go 的 `pseudo-version` 是 v1.4.2，这正是因为 go 认为 replace 后的 dubbogo 依赖主版本是 v1，去查找了该主版本下的最新 tag，并递增了 `patch version`，从而导致前后主版本不一致，当我们对版本路径加上 v3 后，go 查找不到对应主版本下的 tag，为我们自动生成了 v3.0.0，从而通过了 CI 。

## 3. Go 模块嵌套 ##

和 Java 不同，go 其实是没有子模块概念的。即使有些时候，我们会看到有个 repo 里有多个 Go modules，比如项目的根目录有一个 go.mod ，里面有些子目录里又有 go.mod 。  
  
这在 Go modules 被称为嵌套模块，而非父子模块，即**两个模块没有任何关系，是相互独立的**。  
  
那什么时候才需要单 repo 多模块呢？一般来说，碰到以下两种情况我们才会考虑使用单 repo 多模块的开发形式。

1.  某个嵌套模块变动非常频繁，需要经常发版。
2.  当中的嵌套模块仅仅依赖某个固定版本的根模块。

两种情况其实本质都是两个模块之间没什么强的版本绑定关系，但是由于一些其他原因需要放在一个 rpeo 下，因此形成了单 repo 多模块的局面。

## 4. dubbogo 静态映射文件内容解析 ##

dubbo-go 使用了静态文件映射的方式实现了模块重定向，静态文件的内容如下：  
  
其中的核心部分是 meta 标签 `go-import` 和 `go-source`。

### 1）go-import ###

`go-import` 的作用，是告诉 `go get` 去哪儿可以找到源码，content 分为三部分：

*  `dubbo.apache.org/dubbo-go/v3`：这个项目的 module 声明。
 *  `git`：使用的版本控制工具。
 *  `<https://github.com/apache/dubbo-go>`：告诉 go get 这个项目应该去哪儿找源代码。

### 2）go-source ###

`go-source` 的作用，则是给项目生成具体的 `go doc`（现为 pkg.go.dev ) 文档，一共有 4 部分，前两部分和 `go-import` 一样，是该项目的 module 声明和版本控制工具，后两部分则分别起如下作用：

*  `<https://github.com/apache/dubbo-go/tree/3.0{/dir}>`：声明该项目的源代码所在位置。
 *  `<https://github.com/apache/dubbo-go/blob/3.0{/dir}/{file}#L{line}>`：映射文档和代码，帮助我们在点击文档的目录树时，可以跳转到对应的具体内容。

比如在 `https://pkg.go.dev/dubbo.apache.org/dubbo-go/v3` 上，我们点击其中一个文件：

![6.png][]

就会跳转到对应文件对应的文档。  
  
![7.png][]

欢迎对 apache/dubbo-go 项目有兴趣的同学搜索钉钉群号 31363295，加入钉钉交流群！

## 参考资料 ##

*  《The Go Blog — Using Go Modules》：[*https://blog.golang.org/using-go-modules*][https_blog.golang.org_using-go-modules]
 *  《Go Modules Reference》：[*https://golang.org/ref/mod*][https_golang.org_ref_mod]
 *  《Go Module 如何发布 v2 及以上版本》：[*https://blog.cyeam.com/go/2019/03/12/go-version*][https_blog.cyeam.com_go_2019_03_12_go-version]
 *  《Go Modules 详解》：[*https://www.sulinehk.com/post/go-modules-details/*][https_www.sulinehk.com_post_go-modules-details]

## 作者简介 ##

**董剑辉(github @Mulavar)**，刚从 浙江大学 VLIS 实验室毕业，目前在任 猿辅导 服务端开发工程师。  
  
**盛傲飞(github @aofei)**，goproxy.cn 项目作者，曾给 go 源码【如 mod 工具】提交过很多 PR。

[.png]: /images/20221014/4568155ddba74d5fb59ea88e5967c4ab.png
[Link 1]: https://mp.weixin.qq.com/s/NFwL7YAtzkSsqZi8AYA6tw
[1.png]: /images/20221014/4ccc01db53454c0bb59fe0afb4356e3d.png
[2.png]: /images/20221014/6d5a78b601364b4398b0230bc01f8bf1.png
[3.png]: /images/20221014/ba070122ec4040488440221c0697c575.png
[4.png]: /images/20221014/6a3ddbb81ca946ba8e811beff93b858b.png
[5.png]: /images/20221014/a457fe24f3b4453cab9ceaa7afc25a7a.png
[6.png]: /images/20221014/2ded22a0970a447da3f2bcd60bd1ff98.png
[7.png]: /images/20221014/9d1499352de04b99963be0770961f1a0.png
[https_blog.golang.org_using-go-modules]: https://blog.golang.org/using-go-modules
[https_golang.org_ref_mod]: https://golang.org/ref/mod
[https_blog.cyeam.com_go_2019_03_12_go-version]: https://blog.cyeam.com/go/2019/03/12/go-version
[https_www.sulinehk.com_post_go-modules-details]: https://www.sulinehk.com/post/go-modules-details/