作者 | 孫健波（天元）? 阿里巴巴技術專家

導讀：go modules 是 golang 1.11 新加的特性。如今 1.13 都已經發布了第 7 個小版本了，幾乎所有大項目均已開始使用，這自然也包括 Kubernetes 生態中的眾多項目。筆者在開發?OAM?相關項目的時候，卻發現 modules 的各項功能看似簡單，卻并沒有那么好用，于是便想給大家分享一下使用心得，希望大家也能在最短時間內學會 modules 的使用，避免踩坑。

modules 是什么？

簡單說就是包管理，Golang 的包管理素來以混亂著稱，以前是依賴?$GOPATH，只要你的代碼放在指定路徑下就好了，完全沒有“包管理”的概念。被社區吐槽了很久以后開始搞 vendor 機制，簡單來說就是代碼不光是可以放到指定路徑，還可以放在項目自身路徑的 vendor 文件夾。這個解決的問題是：你引用的代碼包上游變更不會直接影響你的項目，這顯然是開始關心“包版本”了。遺憾的是依舊沒有解決包管理的問題，比如不同的包依賴了同一個包的不同版本怎么辦？版本間代碼沖突怎么辦？vendor 機制并沒有解決，于是圍繞 vendor/ 社區就出了幾十個包管理工具，一時間百花齊放、百家爭鳴、各有所長，導致 golang 的包管理生態變得有些混亂。對這段歷史感興趣的可以閱讀下筆者曾經寫的文章《Go 包管理的前世今生》。

更有意思的是，在 go 官方社區看到包管理工具的亂象后，也做了個功能類似的工具 dep，原理與其他各類依靠vendor/ 機制的包管理工具類似，準備對包管理做統一。當大家對?dep?工具報以期望并紛紛開始切換到?dep?工具管理依賴包的時候，go 官方又發布了現在的 modules 機制，完全放棄了之前的?dep?工具與?vendor?機制。這樣的操作在社區引起了巨大的爭議，modules 與?go get、go build?等官方工具生態有很好的集成，官方的意圖自然是希望拋開原有的歷史包袱，通過全新的方式拯救世界。然而實際體驗下來，卻依舊不盡如人意。

總的來說大趨勢已經是用 modules，go1.13 也對 modules 機制做了不少工作。

言歸正傳，本文的目標是希望能用 5~10 分鐘時間帶您學會使用 go modules，然后通過 QA 的形式，描述一些常見的問題。如果希望詳細理解相關內容，也可以參考官方文檔。

初始化

modules 機制在 go 里面的子命令是 go mod。

modules 機制是 go 1.11 才引入的，所以開始用之前先檢查下自己的 go 版本 go version，建議使用最新的 1.13 版本，涵蓋了 module 機制相關的較多更新和功能。

在保證 go 版本至少在 1.11 或以上之后，就要開啟一下環境變量 GO111MODULE，啟用 module 機制。

export GO111MODULE=on

或者設置為 auto 模式，這樣在 GOPATH 路徑下的項目可以不使用 module 機制。

export GO111MODULE=auto

建議加到?~/.bashrc、~/.zshrc ?等配置中啟動便自動生效。

如果您的項目之前已經用 modules 管理了，那么到此為止你本地的環境已經完成初始化了。

如果項目里之前沒有使用 modules，切換過來也很簡單，刪除原先的 vendor 文件夾（保險起見可以移動到項目之外的地方），在項目里執行一下初始化命令即可。

go mod init [module名稱]

包名跟以前一樣，還是跟 go path 強關聯的，比如我們的項目一般是在 http://github.com/oam-dev/oam-go-sdk，那么你的包名就是這個了。

go mod init github.com/oam-dev/oam-go-sdk

初始化完成后就會看見項目里有個 go.mod 文件。

然后通過 ?go mod download 就可以下載所有原先?vendor?中的依賴。

日常包管理

使用了 go module 以后，你的許多命令就會與包管理集成，比如 go get、go build、go run 都會自動查找并在go.mod 里面更新依賴。

所以按照 Go 官方團隊的意思，一般情況下，你根本不用關心包管理的問題了。( 當然，這真的純粹只是官方在 YY )

所以到這里你就已經學會 go modules 了，沒超過5分鐘吧？

FAQ

實際因為 go 官方對包管理重視的太晚，各種包都沒有版本的概念，隨隨便便就會出現各種沖突，而且由于 go modules 實在是太自動了，所以就算你學會了怎么用 modules，最后還是會比較頭疼。

下面我們就以 FAQ 的形式回答項目中遇到各種問題怎么辦。

有些包由于特定網絡原因無法訪問怎么辦？

Go module 加入了代理的機制，只要設置一個代理地址，就可以提供代理訪問。阿里云就提供了這樣一個?go 的代理?，是完全免費的服務。公共代理倉庫會代理并緩存go模塊，你可以利用該代理來避免 DNS 污染或其他問題導致的模塊拉取緩慢或失敗的問題，加速你的項目構建。

設置的方式非常簡單，只需要設置如下環境變量即可，執行命令：

export GOPROXY=https://mirrors.aliyun.com/goproxy/

go1.13 加入了 mirror 機制，可以通過 go env -w 設置 mirror，其實就是之前的 GOPROXY 做的更到位一些，執行命令：

go env -w GOPROXY=https://mirrors.aliyun.com/goproxy/,direct

逗號后面可以增加多個 proxy，最后的 direct 則是在所有 proxy 都找不到的時候，直接訪問，代理訪問不到的私有倉庫就可以正常使用了。

這個功能基本上是在家遠程辦公的必備工具了。

公司通過 gitlab 搭建了私有庫，二方依賴庫下載不下來怎么辦？

這個幾乎是最常見的問題，比較簡單的解決方案是 hack 一下 git 配置：

git config --global url."git@gitlab.your-company.com:<your>/<package>.git".insteadOf "https://gitlab.your-company.com/<your>/<package>.git"

這個方案依賴你本地的 ~/.ssh/id_rsa， 這樣你就可以正常 go get 了。

Dockerfile 中構建鏡像怎么解決私有庫的依賴包問題？

• 方案一：上述方式通過修改 git config ，卻依賴你本地的 ?~/.ssh/id_rsa，在構建時可以通過?multistage-build?把私鑰 add 到 stage 0 里面 build，然后用后面新的 stage 生成鏡像，這樣構建的鏡像就不會包含私鑰；
• 方案二： 更為安全的方式是，在每次構建 Docker 鏡像之前，先在本地用 go mod vendor 把包緩存下來，在 Dockerfile 構建鏡像過程中還是用 GOPATH 和 Vendor 機制來管理依賴。

依賴包怎么更新指定版本？

先查看版本：

$ go list -m -versions rsc.io/sampler rsc.io/sampler v1.0.0 v1.2.0 v1.2.1 v1.3.0 v1.3.1 v1.99.99

再更新：

$ go get rsc.io/sampler@v1.3.1 go: finding rsc.io/sampler v1.3.1 go: downloading rsc.io/sampler v1.3.1 go: extracting rsc.io/sampler v1.3.1 $ go test PASS ok example.com/hello 0.022s

某些依賴包的地址變更導致無法找到了怎么辦？

go 的依賴與項目名直接相關，這就導致如果我們使用了 github 上的項目，然后項目的維護人員突發奇想改個項目名稱，就會導致所有依賴它的項目都無法找到依賴。

還好有 replace 的機制：

replace golang.org/x/crypto v0.0.0-20190313024323-a1f597ede03a => github.com/golang/crypto v0.0.0-20190313024323-a1f597ede03a

版本沖突怎么辦？

這就要梳理版本了，是最沒有捷徑的。一個比較簡單的辦法是把所有 go.mod?里不需要指定版本的包全部刪掉，僅指定必要的包版本，然后通過 go build 讓項目自動構建依賴包的版本。

通過 go mod graph 可以查看具體依賴路徑：

$ go mod graph github.com/oam-dev/oam-go-sdk github.com/go-logr/logr@v0.1.0 github.com/oam-dev/oam-go-sdk github.com/onsi/ginkgo@v1.10.1 github.com/oam-dev/oam-go-sdk github.com/onsi/gomega@v1.7.0 github.com/oam-dev/oam-go-sdk github.com/stretchr/testify@v1.4.0 github.com/oam-dev/oam-go-sdk golang.org/x/net@v0.0.0-20191004110552-13f9640d40b9 github.com/oam-dev/oam-go-sdk k8s.io/api@v0.17.0 github.com/oam-dev/oam-go-sdk k8s.io/apimachinery@v0.17.0 github.com/oam-dev/oam-go-sdk k8s.io/client-go@v0.17.0 github.com/oam-dev/oam-go-sdk sigs.k8s.io/controller-runtime@v0.4.0 ...

左邊是項目包，右邊是被依賴的包和版本。

如果確實存在兩個需要指定版本的包互相沖突，那就要做取舍，修改代碼，升級或降級某個包了。

本地包如何引用？

如果在代碼調試過程中，涉及到修改其他依賴項目代碼，這時候就要引用本地包，也可以采用 replace 機制：

require (golang.org/x/crypto v0.0.0 ) replace golang.org/x/crypto v0.0.0 => ../crypto

后面這個就是個相對項目路徑的本地依賴所在路徑。

解決了上面的這些問題，基本上你就可以愉快的使用 module 功能啦。

go mod 命令一覽

go mod 里還有一些其他功能，也在此列舉，方便大家查閱：

最后

OAM（Open Application Model）開放應用模型是阿里聯合微軟針對云原生應用的模型，第一次對“以應用為中心”的基礎設施和構建規范進行了完整的闡述。應用管理者只要遵守這個規范，就可以編寫出一個自包含、自描述的“應用定義文件”。

OAM 將應用劃分為應用組件和應用特征兩部分，應用組件是應用本身的邏輯，而應用特征則是云上的各種通用能力（如擴縮容、監控、灰度等等），大大提升了應用構建時模塊化復用能力，將云上的各類資源和能力都轉化為了標準化的可“聲明”對象。

同時 OAM 強調關注點分離，通過標準化的模型將應用開發不同階段的 API 進行分層，流程上先由研發定義應用組件，再由運維配置云上的各種策略，最后由基礎設施團隊統一提供各類模塊化的能力。OAM 則在其中起著彼此協作的粘合劑作用，大大提高了應用交付的效率。

OAM 相關內容在?github?上完全開源，同時我們也為 Go 生態編寫了 oam-go-sdk 方便快速實現 OAM。

目前，阿里巴巴團隊正在上游貢獻和維護這套技術，如果大家有什么問題或者反饋，也非常歡迎與我們在上游或者釘釘聯系。

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論群

• 通過 Gitter 直接參與討論
• OAM 開源實現地址
• 點擊 star 一下

招聘

我們也在招聘，感興趣的同學歡迎加入我們。在這里，既有 CNCF TOC 和 SIG 聯席主席，也有 etcd 創始人、K8s Operator 創始人與 Kubernetes 核心維護成員組成的、國內最頂尖的 Kubernetes 技術團隊。在這里，你將同來自全球的云原生技術領域專家們（比如 Helm 項目的創始人、Istio 項目的創始人）密切合作，在獨一無二的場景與規模中從事 Kubernetes、Service Mesh、Serverless、Open Application Model （ OAM ）等云計算生態核心技術的研發與落地工作，在業界標桿級的平臺上既賦能阿里巴巴全球經濟體，更服務全世界的開發者用戶。

簡歷投遞至 jianbo.sjb@alibaba-inc.com

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術圈。”

總結

以上是生活随笔為你收集整理的五分钟学会使用 go modules（含在家办公使用技巧）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。