dubbo-go v3 版本 go module 踩坑记

dubbo-go v3 版本 go module 踩坑记

问题背景

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

Redirecting to pkg.go.dev/dubbo.apache.org/dubbo-go/v3...

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

问题分析

这一段的执行逻辑是希望利用 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，即：​

# 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 即可，我们在 go 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，成功拉取了依赖。

问题拓展

​

1. Semantic Import Versioning

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

2. 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 多模块的开发形式。​

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

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

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

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

Redirecting to pkg.go.dev/dubbo.apache.org/dubbo-go/v3...

​

1）go-import

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

2）go-source

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

参考资料

《The Go Blog — Using Go Modules》：https://blog.golang.org/using-go-modules 《Go Modules Reference》：https://golang.org/ref/mod 《Go Module 如何发布 v2 及以上版本》：https://blog.cyeam.com/go/2019/03/12/go-version 《Go Modules 详解》：@Mulavar)，刚从 浙江大学 VLIS 实验室毕业，目前在任 猿辅导 服务端开发工程师。​盛傲飞(github @aofei)，goproxy.cn 项目作者，曾给 go 源码【如 mod 工具】提交过很多 PR。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。