如何欺騙 Go Mod ?
hi，大家好，我是 haohongfan。
最近在做 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 的問題，其實知道問題的根本所在，解決起來就很簡單了，有兩種方式吧：
- 由于 gomod MVS 算法，我們直接在主項目 cortex 中指定 kuberesolver 的版本為 v2.4.1
- 方案 1 僅對于向下兼容的項目比較適用，如果某項目沒有這個責任心的話，這么做可能是會出問題的，所以比較直接的解決辦法，直接修改 thanos 的 go.mod, 將 thanos 的所依賴的 kuberesolver 從 replace 挪到 require 中
