腾讯云平台与技术实践(zz)

from：http://www.webguo.com/2011/05/23/tencent_arch.html

[第三届中国云计算大会]2011年最受瞩目的IT业界盛会——第三届中国云计算大会于2011年5月18-20日在北京国家会议中心隆重举行。本次大会由中国电子学会主办，中国电子学会云计算专家委员会、中国云计算技术与产业联盟承办，CSDN网站、《程序员》杂志和电子工业出版社协办。

5月20日，在第三节云计算大会分论坛二“云计算平台与应用实践”中，腾讯网络平台部技术总监陈军带来了主题为《腾讯云平台与技术实践》精彩演讲。



更多精彩演讲，即将为您播报，敬请关注。

以下是陈军的演讲实录：

    我是腾讯的陈军，我加入腾讯之前在硅谷工作了十几年，我要讲的就是开发平台与腾讯海量业务面对的挑战，重点讲几个比较有意思的话题，网络方面，集群任务调度、分布式同步，还有云存储和数据中心运维，因为腾讯做的东西很多。时间关系，就挑一些重点来讲。

    去年12月份腾讯和360事件之后，腾讯就做了一个策略的转变，就是要打造开放平台。目前朋友社区和Qzone平台已经向第三方开放。目的就是营造一个良好的互联网生态圈，带动互联网产业链的发展。这样就可以让一些小公司、创业公司可以借助腾讯这个平台来服务亿万用户。

    这里有一个比较成功的例子，昆仑这家公司游戏放在Qzone运行，目前可以做到一个月收入分成超过800万。这有两个例子，这个注册数字是900多万，日活跃数字是800多万，openpl的日调用达到700多万。

    腾讯海量业务带来了很大的挑战，涵盖了几乎所有互联网业务，有几亿用户，有海量的相片、博客，每天以亿计划的相片上传，就需要腾讯提供PB级的存储，存储方面每天增量都达到TB级。

    这些需求有突发性，每次长的假期，五一、国情黄金周之后，网友大量的上传，比如说在深圳上传的照片，怎么让他在北京的朋友及时看到，这带来很大的挑战，中国三网之间互联互通也是一个瓶颈。电信内部可能带宽够，电信到网通之间可能带宽不够了，这都需要腾讯有一个比较好的基础架构来解决。

    云计算在腾讯来讲，业务部门对外提供的就是SaaS的模式，当客户提供QQ邮箱和Qzone的时候，他们用的就是一个软件服务形式提供。腾讯内部的基础架构部门会开发PaaS和IaaS的架构提供给业务部门，现在有了这个开放平台之后，IaaS和PaaS也向第三方提供的，他们在朋友社区和Qzone的应用也用了腾讯提供的IaaS和PaaS的架构。

    面对这些挑战，腾讯就是持续不断的扩容，因为需求不断的增加。扩容有两条思路，一是Scale Up，升级到更强大的机器，甚至小型机；二是Scale Out，使用更多的服务器，腾讯用的绝大部分服务器，还是普通的PC服务器，小型机用的非常少。这就要求我们软件设计方面需要比较好的扩展性。以Google、Facebook的实践来看，云计算基本上是廉价的硬件开发功能强大，比较智能、比较复杂的软件来实现可靠性和高可用性。不是说通过购买更加昂贵的小型机来实现高可靠高可用。目前腾讯服务器数量达到6位数。

    下面讲一下云网络，这个是传统数据中心网络拓扑，思科以前一直提倡这样的网络拓扑，三层，最下面是接入层，中间是分布层，上面是核心层。这样做的问题就是可能有很多接入层的交换机接到分布层，很多的分布层接到核心层。如果服务器连到同一接入层有1G的带宽，如果连接到不同接入层交换机的及其带宽小于1G。这种架构造成的问题是什么呢，程序员写程序的时候要考虑这个服务器在的是连接同一个接入层，还是不同层的交换机。如果程序在一个机架上运行，带宽可以1G，如果跨机架就会跨不同层的交换机，带宽就是只有几十兆了，写程序的时候要考虑到哪些不同的接入层，这些开发出来的程序不容易自由迁移，动态部署，因为网络拓扑已经反映里面。如果不能做动态部署，资源利用率就比较低。因为它的应用不可能一天24小时都可以有很高的请求。

    我们要做的就是扁平化的网络拓扑，用CLOS Network来部署。50年代就有一个计算机科学家提出来，第一级128台，每台下行40个1G端口，上行40个。第二级4台，每台下行128个10G端口与1级相连。集群内5120台服务器，任何两台都有1G带宽。这样程序员在写分布式应用的时候就不需要考虑这个程序在哪些层运行，因为任何通讯都有1G的带宽。

    腾讯很多应用之间都有交互，不谈动态部署，就算是静态部署，这个应用固定在某台服务器运行，不会做自动迁移，腾讯有很多不同的业务，很多业务都有手机的版本，微博和Qzone，游戏等等，还有服务器端的，在线的。很多应用都涉及到QQ好友关系链，不同应用之间交互很多。当他们有很多交互的时候，采用这种拓扑，都要提供足够的带宽给他们，提供交互。在上面运行的结果就会避免拥塞。

    这种拓扑结构是Google是2008年做的，三级CLOS Network。

    第一级，512台，每台下行40个1G端口，下行40个，每64台一个分区。总共会有8个分区。

    第二级，这个核心交换机往下至少有128个10G端口，下行为64个10G，上行64个，每四台一个分区。

    第三级，16台，每台下行32个10G端口。

    集群内20480台服务器，任何两台都有1G带宽。

    为什么把集群做的那么大，腾讯以前做的非常碎片化，几百台服务器，集群互相之间不能互相利用，利用率高的没有办法利用利用率低的服务器，有的吃不饱，有的没有资源给他，做成这样就希望做一个比较大的资源池。资源池做的大了，应用跑的多了，波峰波谷的机会就比较大了，把他们放在一起就通过消峰填谷来解决。

    集群任务调度系统，它有两个作用。一是任务与资源匹配，提高资源利用率，静态部署的业务都有生命周期，比如说开心农场，前两年很火，现在下坡了，前两年给几千台服务器都不够，下坡的时候只要给几百台服务器就可以了。下坡的时候怎么把这些资源收回来，最好不需要人工，让它自动调度，它负载低的时候，自动把服务器分给其他应用。可以提高资源利用率，我们目标是把资源利用率提高到80%。二是调度系统要监控任务的执行，执行自动容错，进程崩溃的时候，它可以自动把这个进程拉起，宕机的时候，重新找一台机器，把宕机上面的应用在新的机器上重新运行。除了高端容错，还要实现自动化运维，让运维人员压力降低很多。

    开发这样一个系统之后，这个任务就不是静态部署了，写分布式应用的程序员，写的时候不需要考虑这个程序在哪些机器上运行，这些机器上带宽有多少，这个模式就变成他写的应用是提供给集群，至于这个应用在哪个集群上应用，是集群调度器的任务。做到这个，就可以做到服务器符用，提高资源利用率。

    Hadoop，很多互联网公司都用到Hadoop，Hadoop有的数据挖掘跑几十分钟，有的跑几分钟就完成了，你可能还要等几十分钟跑完那个，然后再提交你几分钟的任务，目前Hadoop还是类似于50年代批处理的模式，还不是分时共享的系统。我们开发这个集群任务调度系统，希望能够调度多个Hadoop的实例，有的是短时间完成的，有的是长时间完成的，他们混合在一起，然后同时跑。还希望Hadoop的计算能够跟其他的应用在一个集群里面共享资源。

    采用这个模式之后，任务之间的通讯就不能通过IP地址和端口通讯了，开发人员写程序的时候，都不知道这些程序在哪些机器上运行，所以对IP地址提前写入，就希望有一个名字解析，任务间通讯可以通过名字服务系统进行。后面会讲到我们用一个开源软件来实现名字服务。

    提高资源利用率关键是服务器复用，一个服务器跑多个应用，而不是一个应用。多个应用的问题他们之间互相干扰，用很多CPU，用不了CPU，或者某一个用了很多内存，导致别人没有多少内存可用，复用的时候需要有一定隔离保护的措施，应用互相不受干扰。

目前的应用就是虚拟机技术，一讲到云计算，就会讲到虚拟机，KVM、VMWare。实际上还有资源容器，在不同操作系统都有实现。

    比较一下，虚拟机技术，就是应进上面跑虚拟机的监视器，然后分割成每个虚拟机，每个虚拟机上  跑自己的操作系统，操作系统上再跑应用，这个层次很多，开销也比较大。但它的好处就是非常彻底的隔离保护，每个应用上面都有自己的操作系统，就算这个应用能够把操作系统弄崩溃了，也只是弄崩溃这个虚拟机的操作系统，不涉及到另外一个虚拟机的操作系统。有些应用对虚拟机操作系统有版本的要求，这个可以每个虚拟机操作系统版本不同。比如说腾讯的游戏，有些游戏可能有跑Windows的，可能有跑Linux，第三方应用有要求的，都可以采用这个模式。这个坏处就是开销更大，通常有百分之几的开销。另外在线扩容，要做到动态伸缩，就需要操作系统对CPU、内存、硬盘有热插拔的支持。

    操作系统层面的虚拟化，刚才提到了资源容器的技术，它只跑一个操作系统，在这个操作系统创造出不同的资源容器，每个应用就在放一个资源容器里面，他们之间互相基本上没有什么影响，每个资源容器都看不到对方的进程ID和系统，每个资源容器里面的进程ID都是独立的，也看不到对方的文件系统。内存开销比较小，只跑了一个系统，基本开销1%以下，简化操作系统的管理，只需要一台机器，只需要一个操作系统就好了，多个操作系统版本管理也是一个问题。它还可以做到在线资源伸缩，每个资源容器是可以实时的收缩。

    现在互联网公司google一直在用这种技术，腾讯现在也开始，雅虎和Facebook也在做Hadoop，一个集群里面跑多个Hadoop，Hadoop和其他应用共用资源，他们也是用资源容器来隔离。

    刚才讲到集群任务调度系统需要一个名字服务，他们直接不能用IP地址通讯，这个任务可能是迁移的，可以动态部署的，名字服务通过一个分布式的同步系统实现。分布式  系统里面，同步协调需求还是很多的，除了名字服务，还有配铺同步，分布式选举，当我做配置更改的时候，怎么能够迅速通知到所有的服务器，让他们直接把这个配置拉取下来，配置同步也是一个需求。

    另外还有一个分布式选举的需求，做高可用的时候，以前一些做法，一主一备，都是比较静态制订，主的宕了，备的上，有的是一主多备，或者一组服务器，  不指定哪个主的，一个宕掉了，另外自动补上。

    还有群组成员管理，一个组里面有几百台和几千台节点，它是动态的，怎么进行组员的管理。

    另外就是分布式锁，分布式计算可能有一个同样的需求，需要共享资源，就是需要分布式锁。用统一的平台，各个业务就会自己做这个东西，这个东西是很复杂的，后面真正要实现分布式协调是要用到一个Paxos协议，这个协议非常复杂，一不小心就做错，把它开发成一个平台提供给大家应用。google比较早做了这个步，他们开发了Chubby提供服务。

    雅虎也做了一个开源版的Chubby，ZooKeeper，它有五台服务器，三台或者五台、七台都可以，Paxos比较复杂，所以他们发明了一个ZooKeeper  Atomic Broadcast实现信息同步。这五台有两台宕还是可用的，这些客户就连接到某一台服务器，读的时候只从这台服务器就可以了，写的时候，这台服务器需要把写的信息转发给Leader，然后实现同步。Client写了数据，另外一个是读了，这两个也要同步，它有一个同时机制，Client写的时候是五台服务器都写了才是成功，而且数据在内存里面，速度相对比较快。数据发生改变之后，服务器会通知对这个数据感兴趣的Client，有通知机制。它每秒可以实现几万个请求。

    云存储，存储方面比较成熟了，几年前Google发表了System，之后还有Big Table，都是PB级。

    最后讲一下数据中心自动化运维和监控，腾讯服务器达到六位数之后，效率就非常重要，到底多少人来运维，我们做的就是自动化运维，提高效率，降低成本。上个月底亚马逊云计算发生了比较大的事故，就是人工失误造成的，造成服务中断12个效果。如果自动化运维就会有效减少这些失误。我们一个运维人员管几千台服务器，希望实现自动容错，一台机器实现精简故障，服务器可以自动找出好的服务器，运维人员只是在工作时间换掉这个服务器就可以了，不需要半夜去做，这也有一个全面准确及时告警系统。