孙宇聪：打通开发环境与生产环境的任督二脉

个人简介 孙宇聪，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不想要了等情况。