阿里云计算资深总监唐洪：飞天大规模分布式计算系统解析

CSDN首页>云计算

发表于2012-05-25 11:11| 5566次阅读| 来源CSDN| 0 条评论| 作者杨爽

分布式应用云计算分布式计算阿里云飞天

摘要：阿里云计算资深总监唐洪带来了《飞天大规模分布式计算系统》主题演讲，他和大家分享了飞天的架构设计，以及阿里云在三年多的应用实践过程中的一些领悟。他指出大规模分布式系统面临日益严峻的挑战，我们的平台和应用要符合发展规律，例如平台应该支持多少应用？应用对平台如何包容？

【CSDN现场报道】第四届中国云计算大会于2012年5月23-25日在北京国家会议中心隆重举行。本次大会由中国电子学会主办，北京市经济和信息化委员会协办，中国云计算技术与产业联盟、中国电子学会云计算专家委员会承办，CSDN与《程序员》杂志协办。在2012国内公共云全面开花、云计算实践元年之际，本次大会云集云计算核心专家，就国内外云计算核心技术以及行业应用创新实践进行了深入探讨。

阿里云计算资深总监 唐洪

阿里云计算资深总监唐洪带来了《飞天大规模分布式计算系统》主题演讲，他和大家分享了飞天的架构设计，以及阿里云在三年多的应用实践过程中的一些领悟。他指出大规模分布式系统面临日益严峻的挑战，我们的平台和应用要符合发展规律，例如平台应该支持多少应用？应用对平台如何包容？

文字实录如下：

大家好！先向大家做个自我介绍，我叫唐洪，之前在Yahoo的Hadoop工作了两年半，目前在阿里云负责飞天大规模分布式计算系统的开发工作。飞天是阿里云OS核心的组件，阿里云开发飞天已经大概有三年多的时间了，我想在今天跟大家分享一下我们三年半来积累的一些经验和体会。

关于“飞天”，百度百科有三个解释：我看了一下，和我们做的飞天还多少都有点关系。第一个是飞向天空，大家是做云计算的，云是在天上的，要驾驭云的话肯定要飞上天。第二个意思是飞龙在天，听上去有点霸道，但是从某个意义上说，要做好云计算，必须要有一个高效可扩展的大规模分布式系统，也就是说大规模分布式系统是云计算的核心。第三个意思是在空中飞舞的神，正好在飞天的架构中，我们的各个模块都是以神的名字命名的。有句老话说一个好的名字是成功的一半，可能有些夸张，但是我想至少可以说是一个成功的开始。

在我切入正题之前，我想先回顾一下阿里云OS，它有两部分组成，一个是数据中心部分，另外一个是移动设备部分。在数据中心部分，它的底层是大规模的Linux集群系统，在这上面是我们飞天大规模分布式计算系统。飞天在这里承担两个作用，一个是集中管理集群系统里面所有的资源，另外一个是用来控制集群上跑的分布式应用的运行状况。在这之上，我们的云OS提供门类很齐全的开放服务。举几个例子，开放存储服务是针对无结构数据的存储，比如说图片、音乐、视频。还有一个是OTS，开放结构化数据服务，这是对海量的结构化数据提供存储和实时查询功能。还有一个是开放数据处理服务，是对离线数据大规模批量处理，大家都知道hadoop是做大规模数据处理的，和Hadoop相比，ODPS就是把离线处理能力当作一个公共服务提供给大家。最上面的ACE是云服务引擎，也就是说是一个廉价高效的Web应用的执行环境，我们支持Node.js和php。最上面是应用层，阿里云自己提供地图、邮箱等互联网的基本服务，我们之所以提供这些服务的原因，一个是基本上所有互联网应用都需要这些服务，另外是这些服务的研发成本和维护成本很高，我们把这些服务提供给大家，降低很多个人开发者进行创新时候的门槛。说简单一点，云市场就是云应用和服务的App Store。云市场上面的应用是写在我们的云服务上面的，并且是放在我们aliyun.com的网站上运营。 当然还有第三方其他的服务。

移动设备端的底层也是Linux的内核。我们包装了WebKit，OpenGL，SQLite等比较常用的开源库，我们还自己写了JAVAVM，阿里云VM，专门为移动终端打造的。和aliyun lib一起，这几个东西提供了手机端或者Pad端的系统服务。本地框架应用提供阿里云OS的UI框架和本地设施，为了便于开发者向云OS过渡，本地应用框架兼容Android，Android上的App可以通过字节码的转换，跑在Aliuun OS上。境云应用引擎就是一个HTML5和JavaScript的运行环。和云端的云服务引擎合在一起叫云应用框架，它整合了云端和终端的资源，用云应用框架写的App，既可以得到和本地应用一样的体验，又可以访问云端的资源。

我想在整张大图里面着重讲几点，一个是大家看到各种各样的应用跑在同一个集群，也可以同一个应用跑到多个集群上，也就是说我们想做的是资源共享，但带来相应的挑战是要和在这个集群里面各个应用进行隔离。另外，我们底层是飞天大规模分布式系统，这两个结合起来，大家知道和Google的架构比较接近。中间的云服务，我们基本上所有的资源、计算、存储，数据处理的资源都是以一种公共服务的方式为大家提供的，这个方式也就跟亚马逊现在的Web Service模式比较接近。最后大家也看到了，在我们的手机端，我们云应用框架已经把云端和终端连接在一起，也就是说我们把云作为了移动终端的标配。这个和苹果的iOS设备加iCloud的理念也比较接近。开个玩笑的话，我们搭载第一款云OS的手机是去年7月28号发布的，这个比苹果还早了两个多月。。

切入正题，到底我们飞天是干什么的？用一句话来讲，飞天就是把几千台廉价的服务器整合成一台超级计算机。如果再展开一下的话，你可以想象存储的是有10PB级别的硬盘 ，可以存放100亿的网页，或者对几十万的用户，每人提供上百G的存储。另外，你也拥有了一台万核以上的计算机。比如说我举个例子怎么理解万核以上的计算机？一个月需要完成的渲染作业在我们这个计算机上基本上40分钟就可以完成了。

反过来讲，我们的运行环境是多租户的，我们想在不同应用、不同用户之间对资源使用的波峰波谷进行削峰添谷，同时我们要对不同应用进行安全和隔离。当你有了这么大的计算机以后，故障是你比较头疼的问题。飞天很大程度上要做的事情是要规避故障，并且对数据进行冗余。简单的理解，就是说服务“永远”不中断，数据“永远”不丢失。当然，这里“永远”是打引号的，但是这一台超级计算机一定要比单个服务器的可用性和可靠性要高得多才行。

做这样一个大规模分布式系统有很大的挑战，而且很多的挑战是我们在做的过程才理解的。第一个挑战，小概率的事情变成了常态，因为这个系统里面有很多组件，所以故障率被放大。比如一块硬盘的年故障率是4%，当一个集群有5万块硬盘 ，出现的日故障率是99.6%。也就是说每天我们几乎必然就会有一块硬盘损坏。另外，很的故障是我们在设计时候不知道的，比如说一个网卡，大家都知道TCP包中的校验码在网卡中计算的，但是网卡是有可能算错而且查不出来的，或者说一个网线的故障会导致带宽减少90％，这些都是人为因素和硬件故障造成的。相应的，软件的一些Bug，在很多边界条件下才会触发，所以最好的测试团队都没有办法找出来，唯一能够发现的情况就是在线上，因为只要你跑得足够 久、跑得规模足够大，它一定会发生。

第二个事情是全局同步的代价非常大，Jim Gray在1996 SIGMOD的paper里面，当然他讲的上下文是分布式事务处理，规模增长10倍的时候同步竞争代价涨了1000倍，也就是规模增长和竞争代价是三次方的关系。所以说，一个10台机器集群变成1000台机器，同步的代价有可能放大100万倍。这就意味着两点，一个是在性能的关键路径上我们规避全局同步。另外一个，我们不太可能知道很精准的全局状态，所以我们要在架构设计里面对不精准的全局 状态达到一个妥协。

第三个是我们的运行环境是非常动态的，首先是因为我们是支持互联网应用的环境，也就是意味着互联网本身发展的环境是爆炸式的。譬如美国Slashdot是大家很关注的发帖子网站 ，大家很关注一个帖子时候会使帖子引用的网站崩溃。另外一个例子是Draw Something，一个在两个人之间你画画我猜画什么的应用，他被Zynga收购的时候，流量大大增加了。还有一件事情是系统里面的热点任何时候都存在，而且不是持续性的，有可能这个时间点是这台机器，另外一个时间点是另外一台机器。第三个是服务负载周期性变化，工作日大家使用搜索服务多一点，周末大家在休息用得少一点，白天可能是波谷，晚上是波峰。

今天我不能说我把所有分布式系统挑战都解决了，但是我还是想和大家分享一下我们做到今天的一些东西。首先讲一下飞天大规模分布式系统的架构。飞天底层是架构分布式计算系统最基本的服务，比如说远程过程调用，支持点到点之间的通信，我们的远程过程调用还支持校验，也是因为刚才说的TCP校验码会出错。还有安全管理，我们是多租户的环境，我们需要安全，大家都知道，安全一般分两个部分：一个是认证和一个是授权，我们的认证基于Kerberos，授权基于Capability，也就是权能。第三个是分布式的协同服务。如果写过分布式系统一定知道这是最基本的东西。我们的分布式协同提供了分布式锁，配置管理、提供了分布式状态同步等这样一些基本的服务。最后一个是资源管理，这里的资源管理主要是指CPU和内存的资源管理，资源管理模块的功能是管理每台机器上运行任务的生命周期，并且控制它的资源使用。

在这上面有两个东西，一个是分布式文件系统，我们的分布式文件系统提供了类似POSIX API的接口。你可以想象它有一个统一的地址空间、命名空间，一个树状的结构，它这里边大概有上亿的文件。然后我们分布式的文件系统是支持权限的控制、支持额度的控制，我们的额度控制是在目录级别的。还有一个是任务调度，飞天提供了比MapReduce更加灵活的任务调度编程模型，这个我后面还会讲。除此之外，我们还有两个，一个是集群的部署，集群部署控制应用和飞天在集群上的部署工作，因为我们同时支持一些离线的应用和在线的应用。在线的应用一个很大需求是在线扩容，也就是说你加100台机器是不需要停集群，停服务的。还有一件事情是在线升级，也就是说在线服务是不能停的，你需要把新版本的服务和老版本的服务通过轮转升级的方式升到新版上去。集群监控提供了集群的运行状况和性能监控，它提供系统运行状态的仪表盘，还能支持用户定义的监控和报警，很重要的一点，它提供包括离线和在线在内的故障的诊断和性能分析。在这之上就是我们的一些云服务。

整个这张图我不可能在短短的三十分钟里面讲清楚，所以我会重点介绍分布式系统、任务调度和资源管理这三个部分。刚才我讲过，我们的组件是拿神的名字命名，分布式文件系统我们名字叫盘古，调度和资源管理我们叫伏羲。盘古是开天辟地 ，大地是承载所有东西的基础。分布式文件系统是把我们的状态存储下来，所以我觉得这是很好的命名。伏羲是卜卦和预测的，所以资源管理和任务调度我们用伏羲来命名。

这是盘古的架构，和Google的GFS类似，盘古的架构是Master-Slave主从架构，Master负责元数据管理，Sliave，叫做Chunk Server，负责读写请求。其中Master是基于Paxos的多Master架构，一个Master死了之后，另外一个Master可以很快接过去，基本能够做到故障恢复在一分钟以内 。文件是按照分片存放，每个会分三个副本，放在不同的机架上。最后，我们提供端到端的数据校验。

关于盘古，下面讲它三个架构设计上的点。

第一个是盘古 IO的处理，这张图画的是多级事件驱动IO，整张图画的一个Chunk Server的内部结构，接受请求的线程会分发到不同的队列里面，每个队列由一个线程控制，这个线程专门负责一个IO硬盘 的读写 。这个线程做完之后会放在这个队列里面，下面有一个线程池把它发回去。另外一个事情是我们会对发到同一磁盘上的请求进行排序 ，第一个事情是因为我们是支持优先级的，另外，当同优先级请求来的时候我们会按照它在磁盘上排列的顺序 重新排列 ，来降低磁盘寻道的开销 。

第二个是我们的冗余恢复，冗余恢复就是指当一个chunk的复本数少于指定值时，要对这个chunk创建新的复本。之所以要对这个冗余恢复进行一些很精准的控制，也是因为我们的系统上有在线和离线的一些应用，你不希望当你在线系统冗余恢复的时候影响在线应用。也就是说我们会对冗余恢复所占用的带宽进行监控，减少对正常请求的影响。还有一件事情是我们后来才发现的，这个流控不能影响到只有一个副本的chunk的复制，否则会导致这个chunk丢失。我们现在大概能得到的性能数据是在一个50台机器的规模下，如果你有一个1T磁盘损坏 ，在20分钟内就可以完成恢复。

第三个事情是我们有一个数据聚簇模式，这边我画了一个在线服务，很多互联网应用用Partition方式达到它的可扩展性，这里我们有三个Partition，每个框代表一个Partition，跑在不同的机器上。这三个线程（音译）也好、进程也好，它们访问的数据是不同的。比如Partition1要访问的是圈圈状的数据，Partition2要访问三角状的数据，Partition3要访问菱形状的数据。如果我们不对Partition的placement进行控制，我们发现我们每个进程都要访问三个机器上的资源。理想状态是这样的，就是我们希望把同一个Partition想要访问的数据放在尽量接近本地的硬盘 。我们是怎么样做到这一点的？我们允许一个服务对它要访问 的数据打标签<app, part> , 对于相同<app, part>标签的文件，我们会把他们放在一台机器上。

再下面我们要讲伏羲，在讲之前我要讲一下关于资源管理的挑战。那么资源管理可以想象成一个什么问题？它是上万个资源和数十万任务之间的动态匹配问题，就是你有上万个资源，并且有数十万个任务等待要去执行。分开来讲，这个动态性有多动态？每秒有上千资源请求、供需状态变化，并且每个请求都是多维度的，有CPU，有内存，还有虚拟资源，因为我们有一些机器和别的不一样，就可以用虚拟资源来标示。任务调度还会有很多限制，首先我们支持任务的优先级，还有资源抢占。另外，为了保证用户之间不打架，我们要进行资源额度控制。第三个是跟刚才一张PPT所说的类似，就是我们要尽量把运算接近数据，所以任务在这台机器上跑和那台机器上跑代价不一样。最后，有的机器上有坏掉的现象，但是没坏死，还通，但是跑不完，所以对这样半死状态的机器，以及系统的热点进行一些负载的均衡。

我讲大概三点我们在实现福伏羲资源管理、资源调度上的经验。

第一个，我简单通俗地把它叫做批发＋零售，就是说因为我们有这么频繁的资源请求需要处理，单点肯定是处理不了的，所以我们就批发。批发是什么意思？有一个单点把资源批量发给应用，零售再把批量资源分发给下面每个具体的进程。

还有一点，我叫做计划经济＋市场经济，当我们对上万个资源和数十万个任务进行匹配的时候，而且每一次匹配都那么复杂，做一次全量的调度是要秒级或者几百毫秒才能做完的，也就是说你不可能对每个资源变化都做全局的调配，所以我们就定期异步地进行全量调度。但是带来地问题是我们全量信息是不准的，所以我们做市场经济，就是在你真正做到调度决定的时候，你分析一下到底有多少本地可以调度的事情，然后再做一下权衡 。

第三点，资源的重用，很多时候在集群资源全部占满的时候，当一个作业释放出一个资源的时候，它可能再去请求另外 一个资源，然后调度做的工作是把刚才拿到的资源再回给它。这种状况下，你可以做的事情是在作业调度层可以把资源复用，也就是说把这个资源拿来多次调用不同的任务。

下面我切换一下话题，讲另外一个部分，就是伏羲作业的编程模型，这张图展示我们伏羲作业的模型。

一个作业可以看成一个有向无环图，里面每一个节点是Task，然后每个Task是按照数据分片在并行执行，然后Task是有边的，这个边是数据流，而且每个Task有多路的输入 和多路的输出。这两个Task之间的边表示数据cross shuffle。如果大家熟悉MapReduce的话，就知道他是这个模型的一个特例，只有一个输入，一个输出，并且只有两个Task，一个Map，一个Reduce。

我下面会用一个简单的例子说明为什么这是比MapReduce好的编程模型。阿里巴巴是电子商务企业，所以拿这个例子比较贴切。我们想统计畅销的商品，这是一张订单表，有四个字段，也可能有更多的。一个是订单的编号，一个是产品编号，一个是单价，还有是你买了多少东西。最后我们想要知道不同的产品从卖得最畅销到最不畅销的做个排序 。这里显示地是做这件事情的SQL语句，这个是最简单的SQL语句了。

我们看伏羲生成的作业是这样的，Map Task把输入中的prod_id和count字段抽取出来，然后按照prod id做Hash发给R1，R1对prod_id进行聚合，并且对count求和，得到quantity字段。R1按照range partition把数据发给R2,并且R2对数据按照quantity降序排列，得到我们想要的结果。再看MapReduce，它比伏羲多了一个Task M2,是个identity map，就是把数据从输入拷贝到输出。除了它要多加一次多余的IO之外，它还是两个MapReduce作业，这里我用两个框来示意。注意在第一个作业完成之前，第二个作业是没法开始的。

我们还可以从执行层面来比较伏羲和MapReduce。可以看到不仅MapReduce增加了一个M2的Task，而且伏羲下面有一个M、R1、R2，它们之间可以重叠，而MapReduce下面R1和M2之间没有重叠。这只是一个示意图，但是大家可以看到，伏羲会比MapReduce快大约四分之一的时间。

最后，我想回顾飞天三年半的历程，2008年10月24日我们开始系统的设计，2009年2月4号大家写下第一行代码 ，2009年底有第一个飞天的应用，是一个大规模数据分析方面的应用。2010年8月27号，我们支持了四个很大的应用，一个是搜索，一个是邮箱， 一个是弹性计算和存储服务，还有就是大规模数据处理。到了2011年10月24号，也就是我们成立3年的时候，阿里云开了首届开发者大会，在这个大会上我们开放服务产品体系全面亮相。我昨天统计了一下，我们有76万行开发代码 和75万行的测试代码。

最后说一下我的体会。一个是做大规模分布式系统非常难，第二个是平台和应用的发展规律，刚开始做飞天的时候是一个平台做多个应用，如果我们不是一开始就支持多个应用，是做不成平台的。在开发过程中需要应用对平台有很多包容 ，也就是说应用不跑在这个不太成熟的平台上可能比不跑在这个平台上累一点，但是当你这个平台成型的时候你会有更大的爆发力。最后一点，和第一张slide呼应一下，到底飞天是什么含义？可能我的讲法比较带一点个人感情色彩。我觉得是首先代表的是浪漫主义，也就是说做云计算要有很多的想象力。敦煌飞天是浪漫的事，所以做飞天是很浪漫的一件事情。还有一个是革命乐观主义，云计算是会对行业带来很多变革的事情，所以我认为我们是在做一次革命，这个革命非常艰苦，这件事情需要很多乐观主义精神。

这就是我今天的分享，谢谢大家！