如何欺骗 Go Mod ?

最近在做 prometheus 生态的 cortex 优化工作，遇到一个比较坑的 go mod 的问题，这里分享一下。

我为什么将标题称为：如何欺骗 Go mod 呢？这个挺有意思的，这里先卖个关子，不过确实是突破了 Go mod 的相关特性。(嗯，曹大的 Go mod 十宗罪又可以增加一宗了）

在正式展开这个话题之前，需要简单的介绍下 cortex 和 thanos 这两个项目。

Prometheus 的局限性

说到业务开发基本上都离不开监控系统，Prometheus 做为云原生的宠儿，以优秀的设计，灵活的使用方式，以优异成绩从 CNCF 顺利毕业，也是很多公司做监控的首选。

但是呢，Promethues 也有其自身局限性，其中影响最大的就是其数据的高可用方案和集群方案。监控也是业务系统的重中一环，不能因为监控系统宕机导致报警无法及时发出。

Prometheus 官方也有提出联邦方案来解决集群问题，但是这个方案极其复杂而且很多问题还是解决不了，于是就造就了另外两个 CNCF 的沙箱项目：cortex 和 thanos。这两个项目都是为了解决 Promethues 的集群，高可用的。

由于这两个项目要解决问题的目的是一致的，所以就会出现很多功能都是可以相互复用的，于是有趣的事情就发生了。

cortex

话说因为某些的需求，不得已需要更改下 thanos 的相关代码。我本地调试的时候将 cortex 依赖的 thanos 给 replace 了一下。

replace github.com/thanos-io/thanos => /Users/hhf/goproject/cortex/thanos

再等我编译的时候，就编译不过了

# github.com/sercand/kuberesolver
../../../go/pkg/mod/github.com/sercand/kuberesolver@v2.1.0+incompatible/builder.go:108:82: undefined: resolver.BuildOption
../../../go/pkg/mod/github.com/sercand/kuberesolver@v2.1.0+incompatible/builder.go:163:32: undefined: resolver.ResolveNowOption

这就让人很无奈，别着急，我们看看这个 kuberesolver 是被谁依赖的。

先看下被 replace 之前:

▶ go mod graph| grep kuberesolver
github.com/weaveworks/common@v0.0.0-20210419092856-009d1eebd624 github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/weaveworks/common@v0.0.0-20210112142934-23c8d7fa6120 github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/weaveworks/common@v0.0.0-20200206153930-760e36ae819a github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/weaveworks/common@v0.0.0-20201119133501-0619918236ec github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/weaveworks/common@v0.0.0-20200914083218-61ffdd448099 github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/weaveworks/common@v0.0.0-20200625145055-4b1847531bc9 github.com/sercand/kuberesolver@v2.1.0+incompatible
github.com/thanos-io/thanos@v0.13.1-0.20200731083140-69b87607decf github.com/sercand/kuberesolver@v2.4.0+incompatible

可以看到正常版本下，kuberesolver@2.4.0 被 thanos 所依赖，kuberesolver@v2.1.0 被 weaveworks 所依赖。

replace 之后

▶ go mod graph| grep kuberesolver
github.com/weaveworks/common@v0.0.0-20210419092856-009d1eebd624 github.com/sercand/kuberesolver@v2.1.0+incompatible

是不是很神奇，kuberesolver@v2.4.0 这个版本竟然消失了。由于 kuberesolver 的 v2.1.0 和 v2.4.0 是不兼容的，所以导致 replace 之后就无法编译了。

Gomod replace 语义

其实这并不神奇，这个涉及到 Go mod 的 replace 语义，不过也是很容易让人忽略的特性。

replace directives：(https://golang.org/ref/mod#go-mod-file-replace)

replace directives only apply in the main module’s go.mod file and are ignored in other modules. See Minimal version selection for details.

其实很简单，replace 只对主模块（也就是你的当前项目）是生效的。可以做如下的总结：

• 主模块的 replace 对于被依赖的模块是不生效的
• 被依赖的模块的 go.mod 的 replace 对主模块也是不生效的

所以，当 replace 之后，cortex 依赖的 thanos 的 replace 是不生效的。我们理一下依赖树：

• 主模块 cortex => require github.com/weaveworks/common v0.0.0-20210419092856-009d1eebd624
• weaveworks => requre github.com/sercand/kuberesolver v2.1.0+incompatible
• 于是整体上 kuberesolver 就只有了 v2.1.0 了

这个逻辑是跟 gomod 的 replace 语义是吻合的，也就是 replace 之后编译不过是正确的。

欺骗 gomod

那就更加神奇了，为何 cortex 直接 require thanos 就能编译成功，按照 gomod replace 语义来说，这也是编译不过的才是正确的。

因为根据文档我们知道，replace 仅仅作用于主模块，脱离了主模块是一律不生效的，这个是毋庸置疑的。

我做了个实验放在了 https://github.com/georgehao/gomodtestmain ，有兴趣的可以试一下，这个能验证 gomod 是遵循 gomod replace 语义 和 MVS (最小版本选择）算法的。

问题基本陷入了僵局，我们如何破局呢？

继续使用 go mod graph 功能，来查看 cortex 依赖的 thanos 的依赖树。

github.com/thanos-io/thanos@v0.19.1-0.20210729154440-aa148f8fdb28 gopkg.in/yaml.v3@v3.0.0-20210107192922-496545a6307
github.com/thanos-io/thanos@v0.13.1-0.20210401085038-d7dff0c84d17 github.com/Azure/azure-pipeline-go@v0.2.2
github.com/thanos-io/thanos@v0.8.1-0.20200109203923-552ffa4c1a0d k8s.io/utils@v0.0.0-20191114200735-6ca3b61696b6
github.com/thanos-io/thanos@v0.13.1-0.20210204123931-82545cdd16fe gopkg.in/yaml.v2@v2.3.0
github.com/thanos-io/thanos@v0.13.1-0.20201030101306-47f9a225cc52 go.uber.org/goleak@v1.1.10
github.com/thanos-io/thanos@v0.13.1-0.20200807203500-9b578afb4763 go.elastic.co/apm/module/apmot@v1.5.0
....
github.com/thanos-io/thanos@v0.13.1-0.20200731083140-69b87607decf github.com/gogo/protobuf@v1.3.1

由于这个依赖树太长（700多行），我就不贴了，基本上也能看出来，cortex 依赖了 thanos N 多个版本，其中在最后一个版本中的 go.mod 中我们发现了一个有意思的东西：

require (
  github.com/sercand/kuberesolver v2.4.0+incompatible // indirect
）

也就是闹了半天，由于 thanos 某个很古老的版本的 gomod require kuberesolver@v2.4.0，让 gomod 误以为 cortex 依赖的 thanos 依然是 require 了 kuberesolver@v2.4.0 了。虽然 thanos 早就改成了 repace kuberesolver，但也就让 cortex 顺利编译过去了。

这算不算 gomod 的 bug 呢？

为什么 cortex 会依赖 thanos 这么多版本呢？这就要回到开篇说的 cortex 和 thanos 功能复用的问题了。

目前 cortex 和 thanos 这个两个项目，基本上是这么依赖的：

cortex 1.9.0 -> thanos v0.19.1-0.20210729154440-aa148f8fdb28
thanos v0.19.1-0.20210729154440-aa148f8fdb28 -> cortex v1.8.1-0.20210422151339-cf1c444e0905
cortex v1.8.1-0.20210422151339-cf1c444e0905 -> thanos v0.13.1-0.20210401085038-d7dff0c84d17
....

cortex 与 thanos 之间的相互引用，就像俄罗斯套娃一样，简直就是 gomod 的噩梦。go mod replace 语义，竟然让这两个套娃给破解了。

如何解决

对应如何cortex replace thanos 的问题，其实知道问题的根本所在，解决起来就很简单了，有两种方式吧：

1. 由于 gomod MVS 算法，我们直接在主项目 cortex 中指定 kuberesolver 的版本为 v2.4.1
2. 方案 1 仅对于向下兼容的项目比较适用，如果某项目没有这个责任心的话，这么做可能是会出问题的，所以比较直接的解决办法，直接修改 thanos 的 go.mod, 将 thanos 的所依赖的 kuberesolver 从 replace 挪到 require 中

本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/S8XBbklDsGLyC4xquLK1eQ