如何欺騙 Go Mod ?

最近在做 prometheus 生態的 cortex 優化工作，遇到一個比較坑的 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 中

福利

我爲大家整理了一份從入門到進階的 Go 學習資料禮包，包含學習建議：入門看什麼，進階看什麼。關注公衆號 「polarisxu」，回覆 ebook 獲取；還可以回覆「進羣」，和數萬 Gopher 交流學習。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rqtVoNe8h4lqxrNjESXjKw