大家好，我是煎魚。

作為一個(gè)資深的 “技術(shù)客服”（經(jīng)?；卮鹛幚砀鞣N問題），前段時(shí)間遇到了一個(gè)比較無語的事情。還埋伏了挺久。

在我朋友他們當(dāng)年搭建微服務(wù)生態(tài)時(shí)，go-micro 是非?；鸬?，也沒有那么多其他 Go 框架的競爭對手。因此很多第三方庫（例如：這次遇到是 sentinel 的庫）有直接或間接依賴到他們。

但沒有想到，最近有同學(xué)反饋?zhàn)约涸谛颅h(huán)境運(yùn)行程序后報(bào)錯(cuò)了。我一看，go-micro 組織下的這個(gè)庫：github.com/micro/cli 竟然 “刪庫跑路” 了。。。

圖片

對應(yīng)到程序里，執(zhí)行 go mod tidy 命令后，會報(bào)如下報(bào)錯(cuò)：

github.com/micro/cli/v2@v2.1.2: invalid version: unknown revision v2.1.2
...

真的是挺無語的。

那為什么 micro/cli 要?jiǎng)h庫呢？我翻了一圈，好多人在 issues 提出了疑問。

官方給出了答復(fù)：

圖片

原因是：“由于維護(hù)不善，已被棄用?！?/p>

這里最無語的是，棄用完全可以理解。但作為知名開源組織，有人引用和大量下載的情況下，竟然直接刪庫了，是非常的不講武德的。

圖片

goproxy.cn 的模塊統(tǒng)計(jì)數(shù)據(jù)

合理的調(diào)整，應(yīng)該要把倉庫轉(zhuǎn)成歸檔倉庫（Archiving repositories），對于用戶較為友好。

這個(gè)問題，解決方向一般有以下幾種：

1、萬能 replace 和升級間接依賴庫：

這種情況下，直接在 go.mod 文件，把有問題的庫 replace 掉就可以了。

像本文的例子，官方是建議 replace 為 github.com/urfave/cli/v2 即可。

顯然遇到這種問題的，更多的是大量的存量程序。個(gè)人覺得這非常治標(biāo)?？偛荒苊總€(gè)新同學(xué)來跑程序都要卡一會吧。??

所以這個(gè)方案對于存量程序來講，如果出問題的人都要 replace 一遍，那還不如直接當(dāng)時(shí)就讓他升級庫，把依賴去掉了。

2、換合適的 GOPROXY 源：

這個(gè)朋友一開始 GOPROXY 用的是 goproxy.io，但是這個(gè)鏡像加速是不會對已刪除庫進(jìn)行緩存的（或者會失效？）。我們只需要切換為 goproxy.cn 即可。

他在切換 GOPROXY 后，源庫被刪除的 micro/cli/v2 正常拉取。萬事大吉。因?yàn)?nbsp;goproxy.cn 會對已刪除的庫有緩存機(jī)制。做好了兜底策略。

這個(gè)方案可能是較為無感的。對于存量的同學(xué)來講，如果一開始就使用的是 goproxy.cn，便不會有任何的感知。后面在漸進(jìn)式的慢慢升級就好了。

另外其產(chǎn)線 CICD 配置的也是 goproxy.cn，所以一直沒有被人發(fā)現(xiàn)。直至最近有人換新電腦新環(huán)境，重新配置時(shí)才遇到。

總結(jié)

一個(gè)知名開源庫的維護(hù)是否標(biāo)準(zhǔn)，對于上下游的框架和工具均有一定的影響。對于這次發(fā)現(xiàn) go-micro 直接刪掉一個(gè)有近 20w 次下載的庫，還是比較失望的。

在相關(guān) issues 里也看到了不少國外開發(fā)者的無語。幸虧這次在 goproxy.cn 的緩存機(jī)制下有所兜底，否則免不了又是一次許多人介入的更新?；蛘咴偌右粚拥钠渌桨噶?。