转载

视频访谈：汪源：蜂巢是网易云自然的选择

汪源： 这个问题可能要从两方面来回答，一个是从蜂巢这个名字开始出现到上线，这个是我们去年年中的时候构思新一代容器云平台，然后起了蜂巢这个名字，开始做容器相关的开发。上线的话最后对外公测是去年年底，所以用了大概小半年时间。但是从蜂巢项目的开发来讲，蜂巢项目的很多基础平台在很早之前就开始做了，比如我们12年开始就基于openstack研发自己的私有云平台，这是蜂巢后端的IAAS服务，从这个开始的话，可以说蜂巢这个项目的开发大量工作从2012年就开始做了。

汪源： 我们从2012年开始做了第一代云计算平台，那时候云计算平台跟现在市面上传统的平台比较相近，也是基于openstack、基于虚拟化的技术。到去年年中的时候网易的典型互联网产品，除了端游之外，我们经过统计，95%已经跑在内部的云平台上面。

我们2012年开始做这个平台时候，对这个云计算平台有比较多的期望，希望这个云计算平台不但能解决资源快速交付的问题，这个问题得到了相对比较好的解决，在没有实施云计算前，一个应用上线物理服务器，要经过两三周的采购周期，做了云计算之后只需要几分钟的创建就可以，所以资源交付的问题得到了比较好的解决。但是我们一开始希望云计算平台能够简化研发流程，提高研发效率，这个问题我们发现并没有得到很好的解决。因为在现有的传统云计算模式下，通过虚机的方式交付的是一个操作系统、是一个运行的环境，但是我们业务需要的是打包好的运行环境。这两者之间差距还是非常大的，这个差距就需要通过专职的运维人员去弥补。我们在开发时还会发现，把代码写完后的部署要做非常多的配置，牵制效率提升和研发流程简化的这个因素并没有很好的解决。我们就探索解决方案，发现容器这个技术可以很好解决的这个问题，尤其是Docker能够用源代码的方式描述环境构建的过程，这就使得开发团队里面不同角色间环境交付和流转可以做到非常高效。比如我配置了一个很好的运行环境，通过Dockerfile去固化这个环境，团队的其他所有角色，包括开发、测试、运维人员拿到这个dockerfile以后，都可以在他的环境里面快速的build起来，并且deploy你的环境。我们觉得Docker恰好就是我们在做了三年云计算之后对于老一代云计算平台没有解决的问题提供了一个非常好的解决方案。现在市面上典型的公有云服务也提供虚拟机的解决方案，所以网易作为容器云这个方向来切入会有比较好的市场空间。

3. 方便透露蜂巢的团队规模和主要构成吗？

汪源： 蜂巢团队还算比较庞大，除了核心的像Docker产品这一块，底层需要有非常完善的IAAS平台支撑，这是两块团队，另外，在蜂巢我们也提供数据库的服务，我们提供高性能高可靠的RDS数据库，同时也提供低成本轻量级的MySQL的镜像数据库服务，这个月还刚刚上线提供像缓存服务等等，这都是PaaS的服务。接下来我们还会提供像对象存储这样的服务。

4. 整个团队和其他云计算同事是复用的？

汪源： 网易云原来相当于是公司内部使用的一个私有云，人才是复用的。包括蜂巢底层一代的IAAS、PaaS跟网易内部使用的平台也是复用的。

5. 能简单介绍一下蜂巢的架构吗？

汪源： 蜂巢的架构可以从两个方面来讲，一个是软件的架构，一个是硬件的架构，无论是软件的架构还是硬件的架构，我们当时设计蜂巢架构的时候始终围绕一个核心目标，就是怎么样给一个互联网产品的研发以及后续的测试、运维提供一个非常好用、方便、体验流畅的工具。基于这个目标，从软件架构上有几大模块，最核心的当然是容器本身的管理，这个我们是采取Docker最主流的容器云的工具，这里面Docker所比较欠缺的是怎么样基于Docker的工具跟底层的IaaS平台相结合，提供很好的容器的网络化的解决方案。这一块相当于是把Docker工具跟openstack里面SDN网络neutron架构做了很好的定制开发，使得蜂巢里面每个容器有很好的网络连通性。

第二块，牵涉到容器的编排服务，这个从架构上我们主要选取主流开源的kubernetes项目。

容器相关的第三个服务是镜像服务，像蜂巢提供的公有镜像，包括官方镜像在国内的加速，第二块镜像是蜂巢团队跟网易运维团队一起合作打造的一系列蜂巢的官方镜像，这些官方镜像把网易运维团队的很多运维经验打包放在镜像里面。这里面有个背景，在网易绝大多数互联网应用的运维都是由杭州研究院运维部来承担，因为网易有很多类型的互联网应用，有社交，音乐，在线教育等等，不同的应用都是由我们研究院这边的运维部来提供，他对各种不同的场景下怎么样做比较好的镜像来实现比较好的系统安全性、系统可运维性有比较多的经验。我们的目的是给研发提供一整套好用的工具，这里面除了容器和镜像之外还要考虑研发后续的运维过程怎么做到自助运维，在自助运维方面蜂巢在架构上做了很多工作，一块是性能管理，业界称为APM，在蜂巢里我们就集成了APM功能。

6. 这个功能是你们自己开发的还是接入第三方的apm？

汪源： 自己开发的，而且是针对容器云的特色开发的。因为容器云里有很多容器，会带来管控的复杂度，还有依赖和调用关系。我们的应用性能管理的APM服务可以在一个页面上很好的展示业务状态的健康度。我们在APM的交互设计上做了非常多的探讨和思考，希望能够让客户通过非常少的交互快速的定位应用有没有问题，如果有问题的话会出现在哪一个组件上面。所以在蜂巢里面可以看到我们把APM这个模块作为蜂巢服务非常关键的一个模块。

在运维方面，绝大多数应用都会遇到数据库的运维，数据库的运维可能需要专职dba来解决问题，这是传统的思路。在10年前，大家用oracle和db2，这些数据库是非常复杂的，确实需要专业的dba来解决运维问题。但是在现在有两个原因，第一个，现在我们大量使用轻量级像MySQL数据库，它的管理会相对比较简单，第二个是基于容器云，大家倾向于不会做非常大的、重的单一应用，会倾向于把模块拆分成很多比较小的单一化功能的应用，这时候对数据库的复杂度会得到比较多的下降。基于这两点原因，我们觉得在蜂巢里面是有机会做到让数据库的运维能够自助化，让一般的程序员也能够管控好数据库服务。关于这一点我们在蜂巢里面提供了一个“数据库助手”的工具，它可以给你的数据库做全面的健康检查，就像给人做体检一样，然后告诉你哪些指标不正常。比如安全性方面的配置有些指标不正常，可能性能方面有些指标不正常，然后提供一个一键解决方案，相当于把药方给你开出来，你只要照着这个药方治疗就可以了。

硬件架构方面比较简单，蜂巢为了给大家提供一个使用顺畅的环境，所以在硬件上面采取了比较优质的硬件，所用的都是bgp五星级的机房，所有的存储都是高性能的SSD，所以大家用的时候不太会碰到操作的时候存储比较卡。所有的服务器之间的互联都是用万兆的网络来互联，所以容器跟容器间网络的连通性能也是很高的。

8. 是网络那边花的时间比较多，还是存储这边？

汪源： 跟架构对应来讲，架构里最核心的是容器的管理、编排这一块，这一块面临的第一个问题是网络，大家用Docker的时候首先遇到的是网络的问题怎么解决，因为网络的问题并不是Docker这个项目自身就能解决的问题。

汪源： 也不是它应该解决的，它也没法解决，因为网络的能力是要IAAS提供支持，但是现在在IAAS并没有业界的标准，怎么样提供一个网络的能力开放给像Docker这样的容器管理的软件，现在并没有这个标准。

10. 对，尤其在南北向的接口方面。

汪源： 网络问题的解决，每一家厂商可能都采取定制化的方案。对蜂巢来讲，比较有优势的是我们底层的IAAS是基于openstack做深度的定制开发，所以在网络层面我觉得蜂巢在市面上所有支持容器云的厂商里面，我们是提供了一个最简洁、方便的网络化解决方案。

这个解决方案的特色大致有这么几点：第一点，它有很好的安全性，在蜂巢里每一个租户可以拿到一个跟别的租户网络层隔离的二层的扁平网络。第二点，它的便利性，很方便使用，每个容器在蜂巢里面都可以拿到一个外网的IP和一个内网的IP，所以你在蜂巢里面使用容器的时候也不会碰到需要做端口映射，因为端口映射带来的是你没法自由选择端口，这样的问题在蜂巢里不会存在。所以在网络这个层面的解决方案上我们是花了比较多的精力。最终提供给客户的是既安全又好用的网络的解决方案。

第二块说到编排，我们是基于Kubernetes这个项目，这个项目是有Google的背景，我们非常看好它的发展前景，所以选用Kubernetes来做编排的服务。但是现阶段Kubernetes的成熟度不太够，所以这里面会踩很多坑，要解决很多问题，最主要的问题是性能的问题。因为我们作为公有云厂商提供出来，这里面有上万的客户，有十万以上的容器，这时候官方社区、开源社区提供的解决方案是有很多技术方面的限制，这里我们做了一些定制的增强。这两块是本身容器相关的核心的服务，我们做了技术问题的解决。上层的服务也做了很多工作。

汪源： 我比较看好Kubernetes、Mesos的前景，但是它俩的定位不一样，Kubernetes是完全为了做容器管理，或者为了管理微服务的架构去设计的一套框架，最适合用来做容器云的编排。而且它的背景方面完全没有问题，有Google很强的支持，包括社区也发展得非常好。

Mesos现在业界很多会把它称作dcos，它是一种更加通用的底层的管理框架，Mesos我认为是一个管理框架的框架，在上面你可以跑很多框架，你可以跑yarn去管Hadoop的大数据集群，可以在mesos上加上marathon去管理容器，所以我认为Mesos是更加底层的一个框架。未来有可能出现容器的管理框架跟底层的资源的Mesos管理框架共存，一个架在另一个上面的局面。

Cloud Foundry我个人不太看好，它是比较传统思维的PaaS平台的体系，从目前来看，这种类型的PaaS平台发展并不好，最主要的原因是它做了规范的定义，你的应用架构一定要符合这样的规范才可以。但是现实世界比较复杂，理想很丰满，但是现实是会有各种各样的应用架构，不会都按照你预想的，所以它的通用性会受到比较大的限制，但我觉得Cloud Foundry可能在一些局部领域会获得比较好的发展。但我不认为它会成为一个非常通用化的，取得非常大成功的技术。

汪源： 安全问题确实是大家对容器第一担心的问题，Docker公司做了很多像镜像签名这样的工作，我们一直紧密跟踪Docker社区的发展，但这还是不够的，容器安全问题短期内还会存在。蜂巢采取的方案是这样，我们会把容器包在hypervisor里面，在蜂巢你拿到的是一个容器，但是每个容器都是用虚拟化技术加以保护的，加了一层壳，所以这个安全性自然就没有问题。第二个就是刚刚说的网络层面。

这时候可能很多人会问一个问题，原来容器是很轻量级，放到VM里面感觉又重了。但是我感觉这是不大一样的，因为这时候你的VM是一种标准的、单一化的VM，它的作用就是用来跑那个容器，用来跑Docker这些工具，所以VM可以不断的精简、优化，我们正在不断的精简优化这个功能。比如现在在普通的云计算平台上建一个虚机可能要3分钟、5分钟，现阶段我们把这个创建的时间缩短到1分钟以内。我们做了一些性能测试，预计可能再过一两个月，这个创建时间就包括VM，包括容器，包括网络的配置等等，这个总共的创建时间可以优化到20秒以内。如果是针对企业级的客户，我可以给它划定一个单独的资源池，这个时候只要三五秒就可以给他创建出一个容器，它能够接近原生用容器的性能。

其实安全跟性能有一个取舍，我们觉得安全一定要保证，因为安全问题风险是无法预估的，但是性能的话可能每家有不同的性能需求。比如你如果希望一个容器0.1秒创建出来，网易蜂巢做不到，但是我可以告诉你在秒级之内可以创建出来。

汪源： 不只是RDS，蜂巢里所有的容器包括RDS全部都是SSD。这个解决方案从硬件上全部是SSD，从软件方面我们有两套解决方案，分别针对不同的存储，一套是开源的Ceph，普通的容器用ceph做存储，这个可以做到比较好的容器的迁移，快速的failover。但对于像RDS这样对性能要求非常高的应用，我们是自研了一套网络化的存储系统，这个系统也是原来从2012年开始在网易的内部平台里面已经使用过很长时间。

14. 你们的分布式数据库服务NDDB什么时候会上线？

汪源： 我们的大致规划是在下半年会启动分布式数据库整合到蜂巢的这个项目。

16.

汪源： 华东没有问题，我们正在马上着手去做的是北方的机房，针对华北的客户，现在没有推出，是下一步的计划。

18.

汪源： 下行这块我们现在综合使用多家第三方的CDN。自建的cdn现在在研发过程中，发布的时间还没有完全确定。

InfoQ： 好的，我的问题基本就这些，谢谢。

原文 http://www.infoq.com/cn/interviews/interview-with-wangyuan-talk-163-cloud

正文到此结束