BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Golang中依赖管理的灾难

| 作者 Mr. Key 关注 0 他的粉丝 发布于 2016年8月16日. 估计阅读时间: 11 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

我在Golang的世界里已经遨游一段时间了,虽然远说不上精通,但是我还是发现了一些自己不太喜欢抑或不太适应的东西。通常对我来说,在决定为一样事物投入比较多的精力之前,我都会做充分的了解,在生活中选择是否看某部电影是这样,coding时也是这样。有充分的质疑,才会有充分的理解不是吗?:P

依赖管理在软件工程中一直是一个比较核心的话题。一个人的力量是有限的,在较大规模的软件开发中,你总是需要与别人协作编写代码,或是充分借助开源世界的力量。软件在它的有效生命周期内是一直在迭代的,那么在你依赖的这些"外部"代码库演进的过程中,如何保证自己的代码或工程是可以在任何时间任何地点重复编译重复部署的,而不会出现满屏的红色编译错误告警,甚至是莫名其妙的运行时崩溃?在Java世界中,通过maven工具和gradle工具编辑依赖清单列表/脚本,指定依赖库的位置/版本等信息,这些可以帮助你在合适的时间将项目固化到一个可随时随地重复编译发布的状态。这些工具对我来说已经足够优雅有效(虽然maven中也有不同依赖库的内部依赖版本冲突等令人心烦的问题)。

在初步了解了Golang中是如何管理依赖后,我确实有些失望。自然的,Golang官方团队也早已意识到语言內建的依赖管理机制不够理想,需要有一个优雅而统一的解决方案。因此,如果你打算建立一个包含外部依赖的Golang工程,不妨先参考下官方建议

那么,让我们来看一看Golang的依赖管理问题到底是怎么回事吧。

依赖

假设你已经自己设置好一个Golang的开发环境和工作目录(workdir)了,然后我们在workdir里先创建一个新的playground工程:

~/workdir/src/playground/

接下来在playground工程内新建main.go文件,并且使用一个开源的外部http库(echo框架)提供一个简单的"hello world" http服务。

package main

import (
    "net/http"
    "github.com/labstack/echo"
    "github.com/labstack/echo/engine/standard"
)

func main() {
    e := echo.New()
    e.Get("/", func(c echo.Context) error {
        return c.String(http.StatusOK, "Hello, World!\n")
    })
    e.Run(standard.New(":1234"))
}

这里我们有三个依赖:net/http是Golang的标准库,另外两个是外部依赖--echo框架。你只需要在 import 代码块中声明所需的依赖库,Golang就会自动帮你去拉取它们。怎样运行这个简单的http server呢,执行以下命令(假设GOPATH环境变量已被设置为~/workdir):

cd ~/workdir/src/playground/
go get ./...
go run main.go

声明依赖,执行几个shell命令就可以直接把工程跑起来,看起来相当简单明了。但是,事实真的如此吗?

问题在哪里

还记得我之前说过的吗,软件在它的有效生命周期内是一直在迭代的,也就是一直在变化的。如果我们依赖的echo框架改变了它的API(比如方法签名变更,过时方法删除等等),playground工程还能正常编译运行吗?项目的可靠交付受制于第三方的开源代码库,这是我们和客户都不能接受的!尽管在类似GitHub的开源平台上,知名的开源软件都尽力的保持着自身的可靠性和API的一贯性,但是作为软件开发人员,我们很清楚事与愿违的事情还是经常发生不是吗?总有一天,我们会发现当我们想要去升级一个老系统,迁移使用新版、性能更高的外部依赖库时,之前的代码都不工作了。更糟的是,如果没有做好模块或调用链的解耦,没有对外部依赖库做进一步的封装,工程内部到处是外部依赖库中"不稳定"API的调用,在大型的软件系统中,基于这样的遗留代码的重构就是个灾难!(熟悉的"满屏飘红"又回来了)

与外部依赖库的最新版本保持一致的风险实在太大,如何避免这种后向兼容性被打破的情况?有一些团队的做法是直接将外部依赖库的某个特定版本代码进行拷贝并纳入到自身的版本控制系统中去。据我所知,Google内部当时是这么做的。事实上,我所在的团队初期也是这么做的。这样,所有项目所需的依赖都使用被纳入到内部版本控制系统中的版本,这些代码由专人或团队去维护,一来可以统一不同团队使用的外部库版本;二来最大可能的降低了API被更新升级打破的可能性。

好吧,那就把代码拉进svn/git吧……现在没有问题了吧?让我们来看看工作目录的情况吧。之前我们执行了这条命令:

go get ./...

如果进入 ~/workdir/src/github.com/ 目录,你就会发现labstack, mattnvalyala 这三个目录。labstack 目录是echo框架所在的目录,没有问题。mattnvalyala 则是echo框架本身所依赖的外部库,读到这里你是否已经嗅到了一丝危险的味道?如果你编写的项目依赖 mattn,并且也使用了echo框架,那么如果echo框架依赖的 mattn 版本和你依赖的版本不一致怎么办?

我们先搁置上面的问题,假设已经决定把外部依赖都纳入到版本控制系统中。好,这意味着,在GitHub上开源的代码库,对应本地的 ~/workdir/src/github.com/目录,必须受版本控制。另外,你会说,并不是所有的外部依赖库都来自GitHub吧,也有可能是bitbucket、golang.org等等,那么是不是要把整个 ~/workdir/src/ 目录都纳入版本控制呢?粗暴,丑陋……

生产环境的实践

在生产环境中,确实有一些团队就是按照上面所说把所有外部依赖纳入到自身的版本控制系统中去的。这样他们能够控制所有的依赖。但是要注意的一点是,在编写代码时,所有的导入路径(import path)必须被修改为使用内部版本控制系统管理的库版本。比如原先

import "github.com/labstack/echo"

这样的代码必须修改为类似下面这样:

import "own_dependency_root_path/labstack/echo"

你不仅要对自己的源码做更改,还必须包含依赖库的源码,以及依赖库的依赖等等,一直递归下去。有一些自动化的工具可以帮我们做这些事,但这整个方案仍然显得粗暴丑陋。

幸好,基于Golang的官方建议,我们已经可以找到许多不错的解决方案。

Golang在1.5版本引入了实验性的vendoring标记GO15VENDOREXPERIMENT,并且从1.6版本起使vendoring机制成为默认行为,不再需要额外配置。现在,如果一个package或它的父目录内包含vendor目录,它就会被作为 import 指令的依赖搜索路径。有很多工具帮我们轻松的做到这点,例如godep,那么,挑一个顺手的,去阅读他们的使用文档吧~

总结

Golang开发社区一直秉承着"简约"的宗旨,尽力不去给用户增加额外的设计上的负担。然而依赖管理的处理,确实是一个需要谨慎而精心设计的技术点。Golang官方团队对此也十分重视,它的重要性甚至超过软件工程中普遍认同的"DRY"("Don't Repeat Yourself",强调代码的复用)原则:

"Through the design of the standard library, great effort was spent on controlling dependencies. It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse." - Go at Google

Golang官方团队强调的是代码的洁净/清晰度胜过代码的复用。在Golang的世界里,这很可能是一种非常值得借鉴的编程哲学。

那么最后,结合官方团队对依赖管理的建议,这里也给出一些我在Golang日常实践中提炼出的指导性思路供参考:

  • 当你开源类库或者提供代码作为公司内部的公共库时,请尽量的少用第三方库,推崇使用标准库。

  • 发布的类库,尽量辅以版本管理(版本固化),例如使用gopkg来管理版本。

  • 使用官方推荐的工具来管理依赖。如果你有自己的想法,可以直接对这些官方推荐的工具做贡献,加入社区共同解决问题。

作者

Mr.Key,目前就职于途牛旅游网,关注DevOps,云计算平台,分布式系统


感谢木环对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

golang依赖问题 by 李 凯文

文中提到的问题在1.5之前都是存在的,1.5之后vendor文件夹的引入可以解决部分问题了。今天1.7正好发布,这个功能已经变成了强制,还有一些版本化的功能还需要各个工具自己慢慢完善了。当然最好有个类似pip/npm这样的工具就完美了

Re: golang依赖问题 by John Deng

Yep, 目前社区已经提出要给 Golang 贡献一个更好的依赖管理工具。

docs.google.com/document/d/18tNd8r5DV0yluCR7tPv...

试过gopkg.in? by 于 宝峰

Copy & Own的是一种很坏的开发模式 by 孙 奇辉

依赖管理在软件工程中一直是一个比较核心的话题 ~ 同意,作为一个10多年经验的软件工程专家,我很理解这个痛点。软件工程多年来的一个推荐的是促进代码复用,来应对软件危机。奇怪的是,GO标榜是为了解决软件工程里的问题,为什么软件复用这方面这么欠思考?不支持动态库,偏向于源码级的复用,这实际上是一种Copy & Own的很差劲的开发模式。业界顾问也这么认为。
也有编程语言顾问认为,Google在设计现代编程语言方面的历史太短了 :-)
或许社区会帮助提供类似Gradle,npm之类的事实标准,来追赶这些先进工具的水平。

Re: Copy & Own的是一种很坏的开发模式 by 张 磊

源码级的复用在于解决动态库的“依赖地狱”问题,保证你能编译即能按你期望的运行。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT