BT

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

孙宇聪:打通开发环境与生产环境的任督二脉
录制于:

| 受访者 孙宇聪 关注 0 他的粉丝 作者 魏星 关注 0 他的粉丝 发布于 2015年5月21日 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!
19:16

个人简介 孙宇聪,Coding.net 技术负责人。Google Senior Site Reliblity Engineer(2007-2014) 就职于Moutain View 总部。主要项目: Youtube视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月), Youtube CDN 网络管理系统 (峰值流量~10Tbps), Youtube 直播系统 (2012 Summer Olympics), Borg/Omega, GCE 全球百万台服务器生命周期管理系统及任务管理系统., Linkedin: Yucong Sun。

QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来,已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 在QCon北京2015大会演讲过后,我们采访了Coding的CTO孙宇聪先生。他在2014年2月回国创业,加入Coding.net。采访中孙宇聪向我们详细介绍了Coding如何采用Docker的容器化理念,来打通生产环境与开发环境的任督二脉。

孙宇聪:我是07年本科毕业的,当时比较幸运直接加入了Google中国,然后在Google中国做了一年半之后,就调到了美国总部。14年底机缘巧合,结识了张海龙,就是我们的CEO,当时也有回国创业的打算,所以就应他的邀请,今年2月份回国加入Coding.net。

   

2. 您的从业经历中有哪些人,哪些事让你印象比较深刻?

孙宇聪:Google给我印象最深刻的,就是他们团队强大的生产力。在Google里面,所有的同事都是非常聪明的人,背景非常好,都是世界一流的人,和他们比起来,我就是一个小菜鸟,写代码经常被人批。我就感觉每天在Google里面都在学习新东西。Google的灵活性也让我印象深刻,我作为工程师加入Google的那天起,到离开Google,几乎每天都在干不同的事,做不同的项目。

   

3. 那你一开始的时候怎么想到要回国创业呢?

孙宇聪:Google是大公司,在一些方面非常灵活,但也背负了非常沉重的包袱。比如说我们的Coding.net想做的这些事情,原代码管理等,Google有一套现成的方法论,这个方法论是好是坏,它都已经是现状了,改变起来非常困难。我们想做的云计算平台,在Google里面也是发展了十多年了,包袱非常大,所以很多时候想的不是怎么样把这个东西设计好,而是怎么样说服领导,说这个事值得干。我觉得创业是一个新的开始,能够从0开始按照自己的想法实现。

   

4. 前两天,Google宣布要把Google Code关掉,是不是因为一些沉重的包袱,还是GitHub的竞争导致?

孙宇聪:Google Code关闭,我们内部也有讨论,它的主要问题是在于没有人维护。Google的软件是日新月异的,每一周都是不同的东西,如果一个产品没有相应的人去维护,就会导致这个产品可能在几个月之后就运行不起来了,因为它所依赖的那些东西变了,这是一问题。它最大的问题还是安全性,Google肯定不希望哪天突然爆了一个漏洞,大家代码都泄露了,或者是都抹掉了,这是他最不想看到的。

   

5. 其实换个角度解读,Google觉得这个东西,投入产出比太低,没有什么盈利前景,就把它关掉了?

孙宇聪:我觉得Google80%多的工程师,做得都是没有任何金钱产出的产品。这些产品给公司带来的价值却是非常巨大的,是有潜在价值的。我今天改了一行代码,让编译快了一秒,虽然没省钱,但是累计起来,每个人都省了一秒,公司就省了无数的钱。至于跟其他的竞争,我觉得可能它成立之初就没打算跟Github竞争,现在Github这么成功,更可以说明这个Google Code没有搞的必要了。

   

6. 那我们下面聊一聊Coding,在你看来,现在国内开发者的生产环境跟开发环境有什么区别?有哪些措施保证开发环境代码部署到生产环境之后不会出问题,出了问题如何及时捕获?

孙宇聪:Google一直就是这么做的,每个原代码最后都会编译成一个包,这个包跟现在的Docker Image很像,比Docker Emage还要轻量级。有了Docker之后,容器化解决了把软件装到盒子里的问题,以前的软件,就像是一包糖,是散着的,这个文件在这,那个文件在那。容器化了之后,相当于把所有的糖都装到了一个袋子里,从此以后就管这个袋子就行了,袋子放到哪,它就在哪边运行,只要大平台没有什么太大的改变,它都能正常工作。当然这个不是绝对的,肯定跟平台有依赖性,但是基本上80%-90%的问题都能解决。把软件装到了盒子里是第一步,它可以把盒子从你的机器搬到服务器,以前很难做到,或者是很难维护。第二步是让这个盒子能够感知环境的变化,这个盒子的配置文件搬到生产环境需要改,生产环境是一个样,在开发环境是另一个样,怎么样实现修改呢?现在的做法是通过Docker环境变量实现。这个也是Docker设计出来的,可以解决一部分问题,但是也不是完美的,我们在实践的过程中也在想,怎么样能把这个东西做得更好。

   

7. 以前开发过程中需要开发一些类库,一些类似API接口的东西?在Docker里面要规范这些东西吗?

孙宇聪:我们针对Docker做了一个叫Stack的小脚本。这个脚本就是一个轻量级的这个Docker,他做得就是用一个配置文件定义,哪些任务要运行在哪些机器上,他们之间的依赖关系是什么样的,什么东西在运行,什么东西要改。以后只要改这个配置文件,自动执行一系列Docker命令,就能完成Setup。我们也特别希望能跟大家交流,把这套方法论公布出来,最后能形成一个规范。现在Docker Swarm 、Mesos也在讨论类似事情,我希望国内的人能够一起参与这个讨论,去把这个东西定义好。

   

8. 你们选择Docker是因为技术上便捷和应用场景需求,应用场景上Docker更适合一些?

孙宇聪:其实我们现在也觉得Docker有点重,因为它有些功能我们其实也不需要。这是一个取舍,如果什么东西都自己做,这个成本也很大。我们在讨论能不能直接用Docker内部的一个组件来完成想要的东西。我们是在用Container这个理念,而不一定非要用Docker这个程序。Docker把我们这个理念实现得更好,我们就采用它。

   

9. 你们为什么选择Docker?相对其他技术,Docker有哪些技术优势?

孙宇聪:我觉得Docker最主要的优势还是轻量级,它符合以前Unix设计哲学,他只做了一个小工具Docker,但是它没有解决环境定义问题。这样做有利有弊,没有定义,你就可以自由发挥,可以跟其他东西组合;坏处就是现在出现了好几种实现,大家每天都在吵哪种是更好的。我觉得还是要看具体情况,因为我们采用的是最简单的方式。Docker化就是我们的基础,Docker是事实上的标准了,就只做Docker。等到下一步有了生产环境、开发环境定义的基础,标准的时候,我们也可以迁移过去,之前做的工作也不会浪费。

   

10. 具体到Coding上,你们在Docker上的运用场景是怎样的?

孙宇聪:我们的生产环境、开发环境,都是在Docker下执行的。就是原代码的编译、打包、运行都是用Docker。生产环境经过一段时间努力,我们现在已经把它全部转化为Docker了。我们Web IDE下面的产品是一个比较有创新性的产品。Web IDE项目里面带有一个Terminal功能,可以在线打开一个命令行窗口。传统的实现方法是用虚拟机,而我们这个用的是Docker。我们可能是国内第一家公开的Docker化项目,Docker化服务,我觉得这个也比较创新,对Docker的安全性也有比较大的考验。因为有root权限问题,所以我们也特别希望,大家和我们一起去完善这个事情,去研究问题。因为在没有经过充分测试之前谁也不知道,我们希望有人帮我们去研究。我们有一个项目,就是说如果你能提出,能够发现我们公司某个产品的问题、安全上的漏洞,那么我们也有相应的补偿。我们非常希望能够有白帽子专家跟我们一起把这个东西做好。

   

11. 你们在开发的过程中踩过哪些Docker的坑,你们是怎么应对的?对后来人,你们有什么建议?

孙宇聪:Docker实践的时候要宜早不宜迟。因为Docker实际上,就Container技术,是一个对自我的约束,就是说你非常清楚地知道,我哪些东西需要拷贝到Container里面,哪些不需要。在开发时,你就要去考虑这问题,以前新加一台机器,上面执行一堆命令,ATT 、 GET、Install……执行完就忘了,没有人知道以后是什么样的。在Docker里执行命令,它能帮你记住,但是更重要的是我们把它整理成代码了。我们可以Review,别人可以过来看,这个执行需不需要改,有没有可以简化的可能,多个项目之间,有没有可能做得更好。例如,我们一开始是每个项目自己建了一个Docker范围,Install一些东西。后来我们发现Install的东西都差不多,就建了一个基础的Docker Image,把东西都装好了,其他人直接用就行了。还有一个好处就是,他能把依赖降到最低?像ATT、GET可能会有一堆依赖,对吧?这样做了之后,把以前不透明的过程变得透明了,也就是把它代码化了,代码化了之后,程序员们就可以挑错了。

   

12. 刚才你提到Code Review这个功能,你能谈一谈,添加Code Review功能的具体想法以及技术实现吗?

孙宇聪:添加Code Review的时候我还没来。我觉得也是Github在这方面做得先驱工作。但是问题是这样,我们在使用的过程中发现Github的这种模式也不是很好用。因为第一,他在加之前就没有做这个工具的集成,第二就说他发Command的时候,缺少定制功能。每个人发的Command都没有格要求,也没有一个tracking机制,这个东西是应该执行,还是不执行?我想把这个东西规范成一套方法论,我认为Code Review是一套方法, Code Review里面有几个角色。我们特别想做一套通用的工具,它的方法论就是,你要玩儿Code Review,可以有人来当Review者,有人来当仲裁者。每一条建议都要分类,可执行、不可执行、以后再执行。用一个通用的工具来实现一个非常具体的计划,更好地帮助那些不知道怎么开始做Code Review的中小团队。如果觉得这个东西不适合,他们可以随时改,我们工具是通用的。我们也希望能够跟大家交流,能再提炼出一些Best Practice,搞出一套适合创业公司的Code Review流程,这个是最重要的。

   

13. Code Review有些自动化的功能,你们是怎么做的,是基于建模还是规则匹配?

孙宇聪:我们这个是基于WebHold做的,因为GitHub也是基于WebHold做的。基于WebHold相当是说,我不管了,你们随便。这种哲学我感觉在这个阶段不行,我们准备实现一些比较通用的模块,比如说我有一个Lint模块,你可以点一个对话框来起用,它背后是通过WebHold进行的。但对用户来说,以后每个提交都可以拿到针对这个工具的一个完整的反馈,比如代码或命令写得好不好。这个工具不是我们自己开发的,而是整合来的。比如说现在社区里最好的Lint是什么,最好的Java 的Lint工具,最好的Python 的Lint工具,我们把它完整地整合到我们的生态环境里,而不是我们自己去开发一堆错误检查工具,这个是不现实的。

   

14. 现阶段Code Review功能是不是更像黑盒测试?

孙宇聪:我觉得是像白盒测试。你提出问题,直接就看到了。如果你这行代码有问题,那他就自动转化成了Comment,就相当于机器人帮你提了一个错误建议。然后你可以说以后你就不要再来烦我了,我认为你提的不好。这个配置的过程都省了,你只要告诉他这个好,那个不好,它以后就不再提类似的问题了,这个应该是未来发展的方向。

   

15. 这样可能会通过一些机器学习让他更智能、更完善?

孙宇聪:这就降低用户的学习成本,用户只需要管理这个Comment就行了。他不用去管运行失败了需要配哪些Comment,哪些Comment不想要了等情况。

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT