作为一个资深的 “技术客服”(经常回答处理各种问题),前段时间遇到了一个比较无语的事情。还埋伏了挺久。在我朋友他们当年搭建微服务生态时,go-micro 是非常火的,也没有那么多其他 Go 框架的竞争对手。因此很多第三方库(例如:这次遇到是 sentinel 的库)有直接或间接依赖到他们。但没有想到,最近有同学反馈自己在新环境运行程序后报错了。我一看,go-micro 组织下的这个库:github.com/micro/cli 竟然 “删库跑路” 了。。。
对应到程序里,执行 go mod tidy 命令后,会报如下报错:
github.com/micro/cli/v2@v2.1.2: invalid version: unknown revision v2.1.2
...
真的是挺无语的。那为什么 micro/cli 要删库呢?我翻了一圈,好多人在 issues 提出了疑问。
官方给出了答复:
原因是:“由于维护不善,已被弃用。“
这里最无语的是,弃用完全可以理解。但作为知名开源组织,有人引用和大量下载的情况下,竟然直接删库了,是非常的不讲武德的。
合理的调整,应该要把仓库转成归档仓库(Archiving repositories),对于用户较为友好。
这个问题,解决方向一般有以下几种:
1、万能 replace 和升级间接依赖库:
这种情况下,直接在 go.mod 文件,把有问题的库 replace 掉就可以了。像本文的例子,官方是建议 replace 为 github.com/urfave/cli/v2 即可。显然遇到这种问题的,更多的是大量的存量程序。个人觉得这非常治标。总不能每个新同学来跑程序都要卡一会吧。所以这个方案对于存量程序来讲,如果出问题的人都要 replace 一遍,那还不如直接当时就让他升级库,把依赖去掉了。
2、换合适的 GOPROXY 源:
这个朋友一开始 GOPROXY 用的是 goproxy.io,但是这个镜像加速是不会对已删除库进行缓存的(或者会失效?)。我们只需要切换为 goproxy.cn 即可。他在切换 GOPROXY 后,源库被删除的 micro/cli/v2 正常拉取。万事大吉。因为 goproxy.cn 会对已删除的库有缓存机制。做好了兜底策略。这个方案可能是较为无感的。对于存量的同学来讲,如果一开始就使用的是 goproxy.cn,便不会有任何的感知。后面在渐进式的慢慢升级就好了。另外其产线 CICD 配置的也是 goproxy.cn,所以一直没有被人发现。直至最近有人换新电脑新环境,重新配置时才遇到。
总结
一个知名开源库的维护是否标准,对于上下游的框架和工具均有一定的影响。对于这次发现 go-micro 直接删掉一个有近 20w 次下载的库,还是比较失望的。在相关 issues 里也看到了不少国外开发者的无语。幸亏这次在 goproxy.cn 的缓存机制下有所兜底,否则免不了又是一次许多人介入的更新。或者再加一层的其他方案了。