陈恺：灵雀云的架构演进

个人简介 陈恺，现担任灵雀云CTO一职，曾取得华盛顿大学计算机科学专业硕士学位，专注于云计算及分布式系统的研发，从2015年加入灵雀云之后，凭借其十数年大规模、企业级分布式系统及云平台研发经验，致力于打造中国第一家基于容器技术、面向开发者的云计算平台。陈恺曾于2004年加入微软，从事Windows操作系统内核（Kernel）研发，积累了大量庞大系统及平台开发经验，2010年加入微软当时全新的云平台团队（Windows Azure），担任首席架构师及软件开发经理。

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

   

1. 大家好，我现在在QCON上海大会的现场，今天很高兴邀请到了灵雀云的CTO陈恺先生来接受我们的采访，首先请陈老师做一下自我介绍。

陈恺：大家好，我是陈恺，灵雀云的CTO，之前的11年我是在美国微软，主要从事的是操作系统、分布式系统，还有云计算平台方面的研发。然后最近的5年担任的是微软的Azure云平台的首席架构师，带的团队负责开发Azure平台最核心的中控系统，叫Fabric Controller。这套系统是用来管理微软分布在全球几十个数据中心里面全部的计算资源，以及在Azure平台上几百万VM的调度、部署和管理，它其实就是微软整个云平台的后端。现在的话我们是在做灵雀云，灵雀云是中国第一家基于容器技术面向完整开发周期的云计算平台，我们称之为容器云平台。它要做的就是通过他的容器服务来优化开发和运维的整个流程，最终帮助我们的开发者来解放他们的时间和解放他们的创造力。

   

2. 您现在好像还是Base在西雅图那边，但是你们在北京也有个团队，能大概介绍一下你们团队的情况吗？

陈恺：好，介绍一下我们团队。我和左玥两个人在西雅图一起工作有将近八年的时间，一开始的时候我们一起在Windows，然后也差不多的时间去了Azure。然后从大概12年开始，左玥在微软做的事情是研发Windows版本的Container。那时候还没有Docker，他其实是在微软第一个把Windows版本Container产品化的人。后来到13年，当然他在做Windows的容器的时候，他比较关注这个业界的发展，到13年看到Docker一下子起来，然后意识到它对整个行业的影响，所以到14年的时候，就决定要去做灵雀云这样一个创业项目。当时因为我做的是Fabric Controller，他要做的事情就是等他的Windows的Container做完之后，我可以在这之上做一个容器管理的平台。看到他要去做一个基于Docker的创业项目以后，我觉得这是非常好的一个Idea，所以我们两个最后一起出来做这个灵雀云。相当于是把他底层的容器技术和我上层的容器管理的技术合在一起，就是我们现在灵雀云的容器云平台。我们团队现在将近有50个人，主要的团队在北京。但是我们在西雅图也有一个比较小的团队，主要是因为在西雅图我们知道，大家把它叫做云的故乡，因为世界上几个最大的云平台都在西雅图，像AWS、Azure，还有Google的GCE，所以在那边我们可以找到一些比较资深的，在云计算这方面有非常非常多的经验和某一些领域有一些特别的技能的人，在那边组建一个比较小的团队。

   

3. 好的。那灵雀云应该是今年3月份内测，然后6月份正式上线的吧？

陈恺：对，我们3月份的时候在中美同时开启内测，两边的服务同时上线，然后到6月份的时候正式开始商用。在不到四个月的时间里面已经积累了超过一万个开发者的用户，还有大量的企业级的用户。

   

4. 能介绍一下你们最近几个月比较重要的一些更新吗？

陈恺：行。在公司发展方面，我们最近完成了A轮千万美金的融资，这也是资本市场对于容器还有容器云平台方向的一个肯定，以及对于我们团队在过去的一年左右的时间里做出的成绩的一个肯定。然后在产品方面的话，我们也一直有大量的更新，以至于都很难去把这些更新都装在脑子里，比较大的一个变化是我们正式开启在全球范围内，对接各个主流的IAAS平台。在业界被称为云上云，因为我们是架构在分布在全球的主流的IAAS平台之上，比如说我们现在在北京区域有AWS、有Azure、有金山云、有阿里云，在杭州区域有阿里云，香港有Azure，美国有AWS，新加坡有AWS。根据我们客户的业务的需求，我们会对接当地最好的IAAS。同时也是把这些IAAS的资源整合起来，帮助我们的用户在他们的服务和整个应用的层面可以做跨云的迁移，包括可以做跨云的容灾和高可用。比如说一家IAAS平台如果出了故障的话，在我们平台上的客户可以比较容易的把他的服务迁移到另外一家IAAS平台上。

   

5. 嗯，好的。那么讲讲刚才您分享的内容。您的分享里头提到有一个点我觉得比较有意思，就是他介绍了三种，可以说是应用架构部署的不同的状态。比如说一开始，我们把应用放在VM就是虚拟机里头。然后第二个状态，就是加了一层Docker在里头，第三个就是微服务的架构，那么你是觉得它是一个应用架构的演进过程吗？后面的为什么就是Docker、微服务会比较好呢？

陈恺：刚才在演讲的时候，围绕展开的一个话题就是容器在云里面到底应该怎么用，先简单的讲一下Docker的好处，这个其实大家都已经非常了解了。不过简单的说的话，可以把整个开发运维的流程想象成有两段，当中由Docker作为开发和运维之间的一个标准的接口。这样子的好处是开发的人员可以去自由的选择使用各种语言、框架、技术栈之类的，只要最后生成的是一个Docker的镜像。而运维这一边不再需要去关心开发到底用了什么，因为最后都是一个Docker，在不同的环境里面部署和运行的方式是一模一样的。如果一个应用是部署在云端的话，在当前情况下比较常见的是这个应用可能采用的是一个分层架构，一个传统的单块架构，他是直接部署在一个云主机里面。可能是有两个实例，每个实例各自部署在一个云主机里边，前面可能是一个负载均衡器，后边可能用到的是一个数据服务。那么第一步最简单的把这个Docker化的方式，就是使用Docker来将这个应用做一个打包，把Docker作为这个应用的一个交付件。这样做完之后的好处，首先从测试上面讲，应用放在Docker的镜像里面，可以做到多个环境下测试运行的一致性。比如开发的人在自己的laptop上面运行一个Docker的容器，和最后跑在生产环境的云主机里面跑的效果是一模一样的。从部署的角度来讲，它的好处是我们可以得到repeatable deployment，什么意思？就是它对于应用环境的配置的过程，在构建的时候已经完成了，生成这个镜像之后，接下来在每一个环境，部署的效果是一模一样的。最后在运维的角度来说的话，它可以得到的一个好处，就是所谓的immutable infrastructure，一旦生产环境里面云主机和它的环境生成之后，我们就不再去改它，可以保证整个基础设施的一致性和初始化环境的一致性。如果需要去改动的话，我们可以生成一个新的主机。在Docker下面镜像本身就是immutable，而且你真的需要对它做改动的话，去生成一个新的镜像，然后做一个部署也是非常方便的事情。其实我们灵雀云自己也是这么做的。一开始的时候我们有一些服务采用的是django这样的框架，也是单块的架构下的一个服务，然后它直接跑在一个云主机里面。如果这样的服务要做部署的话，我们会比如说采用ansible脚本去写一下，一开始是调用底层IAAS的API来获取云主机的资源，然后在上面做一些配置，把我们应用所需要的所有的环境都装在这个云主机上，最后再把应用Copy到这个云主机的环境里面，把这个应用跑起来，是比较长的一个脚本。我们有几个这样的服务，每个服务部署的方式都不一样，我们也有不同的环境，比如说我们有中国区、有美国区，我们的测试环境，我们的集成环境，每个环境部署的方式也不太一样，最后导致我们就有一大堆的非常复杂的部署的脚本需要去管理和维护，比较麻烦。到有一天我们把开发停下来，把所有的服务做了一个Docker化以后，就感觉世界一下清净了，所有的服务我们是用jenkins做的持续集成，生成之后就是一个Docker的镜像，这个镜像在不管什么样服务里面部署的方式非常简单，我们还是ansible脚本来做，这个脚本非常简单，就是获取一个主机装上Docker以后，直接docker run，我的东西就跑起来，而且还能确保在每个环境里跑的方式一模一样。我觉得别的团队如果是要简单的做一下Docker化，就可以从这一步开始；另外一个好处就是其实在生产环境里面，它和之前相比，它的改动非常小，只不过是在应用外面包了一层Docker，所以对生产环境的风险相对来说比较低。但是我后来有提到微服务架构，那是因为像Docker这样一种革命性的技术，它其实一般有几个好处，第一个好处，就是用起来非常容易，所以它会受欢迎。但是它也绝对不会停留在这样一个表面的使用的方法，会有一些其他的作用力，来让他可以对应用的架构设计，还有开发、运维的方式有些更深层次的影响。和它密切相关的微服务架构就是其中的一个例子。微服务架构通常大家说起来觉得它是一个很美好的东西。其实真的使用起来要小心，我是觉得微服务是一个没有办法的办法。在一个项目一开始的话，我绝对不会事先去考虑怎么样设计一个非常漂亮的微服务架构。单块架构比分布式的更容易理解，容易上手，又有很好的工具支持。可以从那里开始生成一个原形，然后去不断的试错，但问题是如果这个应用成功的话，到了一定的时候，它的体积会变得很大。因为业务的不断扩展，还有功能的不断累积。到了这个阶段之后，它的复杂度会变得非常高，它的可维护性会变得很低，就导致整个迭代的速度会变得很慢。现在互联网时代，我们知道市场需求变化又特别快，所以就导致单块架构很难适应这样快速变化的市场需求。在这样的场景下，我们不得不把它拆分成一个个细小的服务，然后每一个服务可以独立的做构建、测试，还有发布。总的来说是为了把迭代的速度加快，微服务是在这样的场景下诞生的。但是微服务架构也会带来一些它自己的挑战。比如说你把一个服务拆成很多个细小的服务之后，运维的工作量就很大了。像刚才说的这样一个云环境的话，如果有很多个服务，然后要手动的把这些服务部署到你的VM或者云主机上去的话，其实是很大的一个工作量。在这一点上其实也是灵雀云诞生的一个初衷，就是在使用微服务的时候，我们更希望的是可以把对于应用的管理和对于基础设施的管理完全的分离开来，作为开发者的话，只去关注微服务架构下应用的管理。而底层的基础设施，就把它想象成一个虚拟的资源池，然后直接在上面部署应用就可以了。灵雀云其实做的就是这一点，它把底层的云主机还有基础设施完全屏蔽起来，从开发者的角度来说，其实是做到了基础设施的免运维。

   

6. 像您刚才介绍的说，如果只是做简单的Docker的话，好像开发的工作没有特别大的变化，而运维的工作变得简单了很多。之后到微服务，这个变化好像就比较复杂一些，听起来。这个过程中，原来开发的人，还有运维的人，他们的工作会产生什么变化？这个过程有什么需要注意的地方呢？

陈恺：在真的实践的时候，刚才我已经提到，不是很建议在一开始的时候，就花太多的时间去思考微服务或者是分布式架构的设计。一开始的时候，对于大多数的团队来说，先把服务做出来上线是比较重要的事情。随后也不太会突然有一天，大家就把这整个单块架构的东西一下子变成一个微服务架构，这也是比较少见的。实际情况下比较可能发生的是，到了一定时候我们意识到，之前的单块架构下的应用，它的体积变得太大了，复杂度太高了，团队可能跟不上，可能开始没有人可以了解整个应用全局性的设计，然后开发的速度、测试的速度变得越来越慢，甚至于在生产环境会出现一些regression。到了这个时候开始，第一件可以做的事情就是新的一些服务的组件，就可以不再往这单块架构里面放，而是独立的做成一个微服务的样子。然后如果在对现有的组件需要做一些改动的时候，可以找机会把现有的组件逐步的分离出来，变成一个微服务的架构。从开发团队的角度来说，我会建议这样一个做法。从运维的角度来说的话，如果运维的工具链和平台不产生变化的话，当然需要部署和运维管理的组件越多，运维的工作量就越大，这是没办法的事情。所以在这个时候可以考虑使用一些工具，像Mysos之类的，或者使用像灵雀云这样的平台来完全的把基础设施，包括云主机的集群管理起来。然后运维唯一需要做的事情就是专注于上层的应用，把它部署在下面被管理的集群上。

   

7. 最后想请您介绍一下接下来的一些工作计划也好，目标也好？

陈恺：接下来我们，特别是在A轮融资做完之后比较大的要做的一件事，就是开始开拓海外的市场，也想尽快的把我们在美国的团队，发挥我们这方面的优势，包括在那边有一些本土的团队，可以去做美国那边的市场，这是一个方面；另外一方面的话，还是更多的和我们实际的用户接触，因为在一开始的阶段，我们做得是一样非常新的东西。在这种情况下，需求都是不可能有客户来告诉你的，就好像是在18世纪的时候，如果你问一个骑马的人说，你想要什么样的交通工具？他不可能想出来说：我要一辆车子，他会说我要快一点的马，对吧。一开始的时候可以根据我们自己的想象，往一个方向走一些。但到现在的话，就需要去和这些用户更加紧密的接触，然后寻找真实的痛点，看一下我们的产品需要做什么样的调整。还有是下一个阶段哪一些服务可以更好的服务于这些用户。

   

8. 好的，那就这样，十分感谢您今天接受我们的采访。

陈恺：好，谢谢。