【archsummit 回顾】阿里云章文嵩：构建大型云计算平台分布式技术的实践

演讲人：章文嵩博士，阿里集团的高级研究员与副总裁，主要负责基础核心软件研发和云计算产品研发、推进网络软硬件方面的性能优化、搭建下一代高可扩展低碳低成本电子商务基础设施。他也是开放源码及 Linux内核的开发者，著名的Linux集群项目--LVS (Linux Virtual Server)的创始人和主要开发人员， LVS集群代码已在Linux 2.4和 2.6的官方内核中，保守估计全世界有几万套 LVS集群系统在运行着，创造了近十亿美金的价值。加入阿里前，他是TelTel的首席科学家与联合创始人，曾为国防科技大学计算机学院副教授。他在设计和架构大型系统、 Linux操作系统、系统软件开发、系统安全和软件开发管理上有着丰富的经验。
演讲资料下载：

本演讲主要分为五个部分：

云计算的挑战与需求
ECS的分布式存储设计
SLB、RDS与OCS的设计
全链路监控与分析系统
未来工作展望

云计算的挑战与需求

    我们的团队核心系统最早是在淘宝，包括我微博上也是淘宝正明，我们从淘宝的基础平台的研发开始做起，变成阿里集团的基础平台研发，去年11月份我们被合并到阿里里面做技术研发，平台的研发也继续承担。过去也做过一些事情让我感觉比较好的，是LVS的项目，LVS1998年我还是学生的时候做的，这个项目到现在还活着，它的生命周期已经16年了，而且到现在还在用。
    回到今天讲的云计算平台的一些实践。我大概分为五个部分来讲，第一部分是云计算面临的挑战和需求，就跟原来做淘宝的时候是不一样的。再讲我们最主要的产品，ECS里面的分布式存储设计，这是我们最关键的一个产品，云服务器，云服务器不是全部，我们会讲我们做的SLB、RDS、OCS的几个部分，第四部分是全殓路监控与分析系统，最后会展望一下未来工作。
先简要讲一下云计算跟原来的不一样。原来我们在做淘宝，我们淘宝、天猫大概有4000多个应用。其实1、2个应用当掉，其实我们可以按部就班的去修，因为整体来说，我们在淘宝、天猫的时候只要交易曲线不下降10%以上，因为平时都比较平缓，只要交易额不掉下来，我们都不会算成PE，只要交易额掉了10%、20%，我们就开始算全占的可用时间，我们就最紧张，知道系统出问题，只要掉1、2个对交易不影响，我们都按部就班的来修。本来淘宝的应用架构都是分布式系统的设计，几个当掉也没关系，很多应用都是可用的。

    比如说我们的云客户上来把他们的系统嫁接在我们的系统上面，他们不会考虑到很多背后机器的问题，如果一台云服务器当掉了，对客户来说就不可用了，把关键系统托在我们的系统上面。有时候客户跟我们讲，他把身家性命都托付在我们平台上面，我们平台一定要稳定可靠。这里面要求不一样了，对于云客户来说，我们任何系统当掉对他来说就是全部，对大规模的网站来说，有可能因为本身的架构设计好了，很多功能有可能节奏就不一样了。就像我们最近碰到的一些网络问题，导致云平台的一些时间对客户的影响，我们过去也遇到，但是这些问题都被上升的架构屏蔽掉了。
    所以说，对架构云计算的平台来说，可靠性要求是非常高的，一方面数据不能丢，另外系统怎么可靠，对用户的时间越低越好。总体的性能，要比用户自己买机器的性能至少不差，我们还需要快速定位问题，就是当十几万的客户，有些客户找我们的时候，我们能快速定位到问题所在，如果找我们，最理想的状况就是用户找我们之前，我们先发现问题。另外云平台的安全性也是非常高的，让云的客户迁到我们平台，比自己拥有机器的成本还要低，而且要低得多。

ECS的分布式存储设计

    我们讲我们最核心的，我们目前最多的云服务器ECS的存储设计。云服务器是我们最大的一个产品，我们为了考虑数据的可靠性，背后是用分布式存储来做的，分布式存储的文件系统，包括快照的制作，快照的滚回，故障迁移，在线迁移必须要做，网络组隔离这些功能在里面。我们有很大的一个控制系统，至少3600台可以撑下来，规模比如说未来要做到5000台或者2万台这样的规模。这里面最关键的就是数据的可靠性，我们实际上把数据都是一次放三份，是保证数据可靠性，当然过去我们也碰到IO性的问题，业界说我们IO性能不太好，以往我们是三份全部写，后来写的时间太长，改了一个2—3异步，但是里面写的具体操作还是有一些问题，就是我们对任何写都要写到背后CHUNK SERVER上去去，路径长，延时大，里面实现的复杂度大，开销系统也大，就导致我们过去IO系统不是那么理想，但是数据绝对可靠。

    这里面的优化思路，我们是拿SSD跟SATA做混合存储，我们目前在CHUNK SERVER做混合存储，两块硬盘做读写保存，我们RANDWRITE-4K-128可达到5500IOPS左右，这里面的路径比较长。这里面一来一回，它的吞吐率就是这个时间的倒数，所以这里面我们有没有可能把这个时间缩短，那它的IO性能更快。这方面我们有很多这样的想法，也做了很多的游说工作，就是我们这么做一样保证数据可靠性，等下会讲为什么还可以保证数据的可靠性。在里面的线程上面，我们重构了我们的TDC的客户端，包括CHUNK SERVER，我们已经做到一个IO请求只要一个线程完成，不对有上下文切换和锁的同步开销。

IO路径上的各层cache与写IO的几种模式探索
    我们回到IO路径，怎么样把它切断。IO在整个系统里面路径还是蛮长的，比如用户有自己的CACHE，有16K的CACHE，我们自己背后的存储系统有自己的CACHE，包括硬盘里面，我们都是高规格的硬盘，说不定CACHE更大，有的4兆，有的128兆，在硬盘牒片上面都有CACH。我们有很多写，我们看到系统里面写有的是BUFFER WRITE，我可以直接写到那个PAGE CACHE里面去，然后发现装备多了会刷下去，我就往存储介质里面去，硬盘当然也采取一定的策略会把它刷下去，才把硬盘上面这个CACHE的内容刷下去。

    这里面BUFFER WRITE写的速度非常快，但这个数据的无法保证，就当然也受这个操作系统比如PAGE CACHE什么时候刷，实现时间都不可控的，都是由操作系统控制的，但是刷的时候会导致操作系统有一点点阻塞的时候。另外一个就是DIRECT WRITE，就是直接写，我们写程序的时候，像MUSCLE就不用自己，这样可以直接刷到硬盘的CACHE里面，但是CACHE不一定刷到牒片里面去。这个时候就绕过了PAGE CACHE的作用，也不是做到数据绝对可靠，绝对可靠就等下面的WRITE加SYNC，这样才把所有东西从INCK的介质刷下去。

    这样我们做一个的时候就有把所有的刷下去，这样保持持久，也不会掉的。另外一种方式是通过SYNC来写，那所有的东西都会同步写，如果没有直接写，会写到PAGE CACHE，一直往下面写，一直写到一个持久的介质上去。我们实际上自己看到，从系统上观察到，DIRECT WRITE在我们上只有3%大概是同步写。我们实际上可以对不同的写的方式，拿本地机器做一些测试，比如拿DD来说，我们一开始直接的写BEFFER WRITE就可以写到210兆的速度，如果我们用DIRECT WRITE写这个速度也比较快，因为它写到下面牒片上面去68兆速度每秒钟，如果我们加DIRECT WRITE加SYNC同步写速度就比较慢了，就257KB每秒。

    我们虚拟化的环境，前面的PV前端，包括我们的PV后端，我们如果一个虚拟化的环境肯定存到本地的硬盘上，硬盘本身也有CACHE，如果我们把这个拓展一下不存在本地硬盘，我们就可以在云环境下放在一个分布式存储上面。我们大概可以引入一个CACHE的机制，就是在系统上，在我们一个物理机器上引入一个CACHE的机器。我打个比方，就像我们硬盘上有个牒片，牒片上有一个CACHE，一般DIRECT WRITE，BUFFER WRITE都会被硬盘缓存住，那同样对我们的分布式存储一样，我们背后的分布式存储相当于牒片一样持久保存，我们在前端做一个CACHE，我们也是尊重来的，就是你如果让我SYNC，会把所有的CACHE写到背后的IF的分布式指出上去，这两步几乎是同步的。

所以我们想通过CACHE来加速我们所有的至少目前是写请求，当然将来也可以把读写请求都做成。我们实际上就是其它人问我或者挑战我这个数据的完整性是怎么保证的，那我们实际上是在里面遵循所有的来，因为这个路径很长，上面告诉我SYNC我一定会SYNC，上面不告诉我SYNC我会尽量缓存，比如按照这个刷新做法继续刷下去。那怎么证明我跟原来一样可靠？就是上面数据库随你开关机都跟你原来都一样，你原来是写到持久介质里面去，但是现在是写到缓存下面去，你如果要刷新的话我帮你刷新，数据库一样可靠，证明这个可靠性是一样的。
但另一方面，一些用户直接不发SYNC，都是直接的BUFFER WRITE，比如写100份数据，那是刷了10份下去还是100份下去我们是不知道的。所以对用户来说怎么恢复，恢复数据是在持久介质里面还是什么用户是不知道的，所以即便用户不做SYNC状态数据处于什么状态是不知道的，恢复也不知从什么讲起。所以这里面我们实际上是对我们引入了缓存的功能，是对DIRECI IO都是非常有效的。我们拿一些测试来说，我们用FIO来做，比如我们测这个是唯一的，DIRECT是16的大小，30G的硬盘我们来测的话，就是我们可以看到，就我们是存SATA的分布式存储的集群，那IOPS可以做到227，这是不带缓存的情况下，就是全部所有东西都写到这个介质里面去，那这个AVG TIME是8秒钟左右。但这个里面的测试是在我们集群上面测的，集群上面本身的全路径的IO优化，多线程事件驱动的架构已经是优化的，这个是不打开的。如果把CACHE打开以后，这个里面我们第一版本实现的策略还不是那么好，但还不够高，609个，延时就低很多了，包括里面的标准差也低很多。

    如果我们按IO这个并发度IODEPTH以8的并发度来测，我们看到过去如果并发度足够高，我们这个IOPS也可以到2100多个，如果加上缓存就可以更高，变成2903，这背后还有很多优化空间值得去做，它的LINT更低的，包括响应的波度也是更低，包括标准差也更低。实际上我们把波度变成对上层的应用，响应程度更低，谷歌也有很多在线应用，在线应用讲究的响应时间，就是怎么把尾巴缩减，他们也用了一定的策略，包括他们最近在CACM（谐音）又讲了一遍。如果一个请求要分成100个作业，其中有1%的概率请求超过1秒钟，那回来的可能性有63%的响应时间都会超过1秒，所以我们对上面响应时间的整体预期是非常大的。

    即便拿分布式指出来说，本身这个存储也有很多选择，就是我们用纯SATA的存储集群，数据是一次放三份，如果机器发生故障会自动做CACHE，这个数据是非常可靠，IO能力也十足，你说让它高到什么程度要看我们优化的程度，可以让它高下去。如果一台物理机器当掉了，可以在另外一台机器上用很快的速度起来。另外我们用了混合存储，就是SATA和SSD的集群，后面的分布式存储全按SSD来。我们目前直接做到，这个产品我们大概在今年11月份或者12月份推出来，目前我们在物理机器上，我们的CHUNK SERVER上已经可以写到18万的IO，因为它本来FLASH本身有刷新影响，在物理机器上，不是在主命名上面。

    我们在前端物理机器上跟前端的，我们已经做到9万IOPS，那9万的IOPS按 4K来写另外要写三份，那大家有兴趣可以乘一下，乘一下就把万兆网卡用爆了，但这里面对目前的实现还有优化空间，如果我们按这9万的IOPS来写，会把6颗的逻辑核用了，当然这消耗的CPU蛮多，我们要在这方面做进一步的优化。另放得也有云的客户找我们做，就是我们能不能跑量或者做批量的读写，这些应用本身已经考虑这个数据就是放三份了，那我们背后的云磁盘的系统已经又放三份，等于数据放九份了，那这个数据的冗余度非常大，也会增加成本，浪费了很多存储空间，所以针对这样的需求，我们有SATA本地盘的存储。但因为数据是事先说好了，如果这个硬盘介质坏了，那么这个数据也没有了，当然上层的应用是分布式系统本身要考虑的，下面的步骤是硬盘可能会坏，对这样的分布式应用或者对数据量批量导入，批量读出可以适用，因为上层的应用已经考虑多份数据，来实现这个数据的可靠性。

    那我们本地磁盘也由SSD来存，当然单份的可靠性要差一些，但是比SATA要高一些，IOPS也高，像MONGODB这样的用，比如说短请求、小请求的HBASE的应用，可以用这样的存储的系统。所以就拿一个云服务器来说，我们实际上针对不同的需求我们会选择不同的存储方式。

    云服务器虽然逻辑上变成一台服务器了，但理论上干什么事都行，就像你买一台机器一样，但是我们是不是拿云服务器能够解决所有问题，实际上从架构的选择来说，至少没有把取舍做到极致。我下面举几个例子，比如说SLB的例子，那SLB我们的案例有由好几台SLB组成的，包括跨台机容的。比如我们SLB排成一排的话，前面通过路由器做一个本架路由的方式，比如说100台SLB，核心的等价路由下来都是可以屏蔽的。另外通过ANCUST可以做等价的容，那样你到一个机房也没关系。OSPF就是做负载军，来调度这些LVS的迹象。

    这里面实际上是我们把SLB的性能不断的深入挖掘，比如说12核的物理核的一个机器，我们正常转发已经可以做到1200万个PPS以上的，这个怎么做的？我们实际上用的是英特尔万兆网卡，我们都是用COLIN来解决，然后再把COLIN上面的请求，怎么保证我们在NEMAN这个架构，让整个CPU的L1、L2、L3的缓存不要断层，只要复杂的业务，短路进来的全部跑起来，对失效的时候复杂的场景判断，那些长路径丢到专门的核上做，这样的话整个的就能跑起来，已经能做到1200万的PPS上了。对于对SIN FLY的功绩，我们已经能做到万兆线速了。然后在ECS上，一台机器，如果是千兆网络，大概我们最大只能做到70、80万的PPS，你说我是不是可以架到CPS上？可以，但是它的性能很糟糕，甚至一台机器可以做到1200万的PPS，那边只有70、80的PPS。我们跟前面的云盾联动起来做七层防攻击。这里面至少从SLB来说，我们肯定不会拿ECS来解决负载均衡的问题，包括功能性的实现，这里面太差了。

    再拿我们第二大产品，就是RDS，就是关系数据库。我们本身能不能把MYSQL能不能跑到ECS上，当然可以跑，主要从RDS本身来说，其它的组建不是RDS团队开发的，我们基本上是三层架构。那SLD，然后再做SYNC等级的负载均衡也好，或者做安全审计也好，到后端的DB，这是数据路径来做。当然我们背后有一套控制系统，我们还有相关的工具，比如说精卫做分步分表，数据库做REC CATION到不同的地方去。这里面整体比如上面有网络监控、业务监控、SIQ监控，搭建这一套我们有庞大的控制系统，我们有原数据服务器，包括我们背后做过滤分析，背后当然以消息中间为中心，背后有性能的数据，我们有一些数据会收集到BPS里面，有一些会存到我们的数据服务里面去，我们会把备份打到OSS里面去，有些性能比较冷会转到我们的备份系统里面去。

    那这里面我们的数据库从一个机房自动复制到另一个机房里面去，本身无状态设计。中间做安全防护，做业务层面流量均衡，包括分布分表的表里面，我们可能里面创造一个数据库的实力里面的数据比较多，整个组织无状态可以做到热线升级。我们要管理到10万以上的MYSQL的一套控制系统，那我们当然也有用户把自己的CACHE弄到自己的ECS上。我们用RDS背后直接调动跑到物理机器上，性能我们自己做TPS的测试大概高两倍到三倍，就是比同等介质的MYSQL的机器上，我们背后也是SSD，这边也是SSD，我们都跑到SSD上，大概快两到三倍这样的量级，这是直接在ECS上跑达不到的效果。

    我们再比如说做OCS同样这样一个架构，我们用阿里开元的那个搭建的，前面可以做安全访问控制，那包括里面的QS的一些工作，留控都在失眠做。用OCS的一些特点，目前我们是在一个机房，是很大规模的一个集群，你要扩容随时扩，监控图都有，不用自己答的，99%请求都在2MS以内响应的，我们去年双十一用到6000万的这样一个量级。跟自建相比，成本就是一半，目前我们很多产品6个月免费，大家可以去看一下。所以说，我们实际上在设计上我们都是不是一个云服务器解决了，我们有很多产品做到极致。

全链路监控与分析系统
    第四部分，我们是做一个全链路的监控系统。过去我们在RDS上碰到一堆问题，包括断链接这些问题，这些问题比如说背后的一些机器故障或者是MYSQL的实力要迁移到另外一台机器。那客户端的MYSQL机器理论上做的好一点是要重叠的，那有些是不会重叠的，那如果背后我们发生任何物理机器的故障，那这个链接就断掉了，访问数据库就失败了。我们过去跟在我们磨面的一些游戏厂商碰到一堆这些问题，对于他们来说改程序也很困难，我们怎么样把后端的链接扛住，后面怎么变动都没关系，无论你机器断掉也不会有问题。这些问题我们做了全链路的监控和分析系统，我们收集的东西很多，包括SYNC的日志，包括网络的状态，用户的行为，我们用JSTORM做数据的及时转换，然后再做离线分析，就是批量的ODPS的分析，这里面以免我们能够尽快抓到问题所在，包括对我们运维也有很好的帮助。

    这里面我们这一套系统，我们在RDS上先得到应用。在RDS每天收到的SYNC的日志，SYNC的采集量都是几十个T了这样的规模，我们都是及时的处理它。当发现用户请求慢了，我们会给用户一个建议，比如说哪个表上是不是忘了建缩影，你建了缩影可能请求会快很多。如果网络异常，对SYNC来说链接突然中断我们也会报警，实际上我们要把异常的行为分析出来，然后报上去，我们会尽量的发现它。目前在SLB也有初步应用，会不正常的网络链接会自动报警。

未来工作展望
    当然这不是全部，之前也有一些规划，但是很多东西都是昨晚写的。我们在ECS上，我们肯定是IO持续优化，我们怎么做到比如说在国内最好或者在全世界最好，那实际上我们很有机会，像UBS它的读的速度还是远远快于写的速度，就是我们看到它的规格，实际上它里面很多地方做的不好，至少很多写做的好的话会比读还要快。当然我们在里面怎么样在代码上面全路径的优化，前面我们讲我们LPS已经挖的非常高了，当然还有挖掘的空间，怎么样把CPU降下来。还有我们CACHE的策略，现在为了快速，基本上来一个很快就往下面了，就跟一个卡车运到仓库里面去，不是轿车运到仓库里面去，就是大批量卡车运到背后的仓库里面去，这些CACHE是很值得优化的，包括我们的缓存目前几十个集群，很多的存储已经步出去了，将来我们能不能用两块SSD做读写缓存，这样做对读有需要，对写有需要，那这样大概90%是落地本地的SSD硬盘上，我们能不能把计算跟存储分离掉，因为计算的需求跟存储量的需求是不一样的，究竟他们是按什么比例发展我们是不知道的。

    所以说有可能以后是跑一个由物理集群的分布式的集群，可能按照各自的需求来发展，那我们存量的集群，包括动态迁移技术，我们在线的迁移技术可以做到对用户无感的迁移，那最后的大概就是一秒钟把所有的数据同步过去，那我们一般机器在云计算本质来说，会资源复用，就是我们一台机器会超配，一般一个用户同一台机器概率很低的，但是如果用到我们怎么来做？我们要把热点迁移到别的机器上去，包括CPU的支持，我们也考虑云服务器上支持的这些，我们在淘宝上面，在天猫平台，所有的客户都在我们的于平台上，我们有可能会把淘宝原来的核心业务也贴上来，最关键的一块也在我们云平台上。这些都值得去做。

    IDS的这个产品，我们目前支持MUCSYCL是占了大部分，但我们会把这个PUSR（谐音）做上来，这样对一些用户相对迁移MUCSYCL（谐音）更方便一些。因为我们现在用户支付的成本也有一些，如果用户能够容忍一定的切换时间，比如说MUCSYCL重启这个时间，比如说几十秒的量级可以容忍，那容忍我们可以做到更低成本，就把这个数据放到存储里面去，如果这个物理机器当掉会迁到另外一个机器上，那数据我们用分布式存储来做。那我们分布式存储不能让RDS下降，那写读速度最重要，我们用软硬一体的方式专门来写，它需要的容量更大，确保分布式写入速度非常快，背后的那个刷下来，可以刷到背后的分布式存储上去，我们目标是做到这个性能更高，但是需要从一个物理机器当掉，几十秒中把另一个数据加载完毕。这里面就是做一些取舍，用户想要什么，可以放弃什么，他想得到什么，我们可以推相关的服务。我们全链路的监控和分析系统会应用到全线产品，我们真正最理想就是先比用户发现产品，当然我们会有更多的云产品会发布出来，在阿里的所有无线客户端都是拿SDK这种方式来加速的，包括我们通过UDP的方式来加速，实际上我们内部在用，包括阿里测，我们内部用的也会推出来，然后我们OCR的识别，然后我们内部的机器学习这些，基本上比一般的英特尔机器快几十倍以上，我们大概都会把它变成云产品的一部分。
好，差不多控制时间比较好，那大家有没有什么问题？

主持人：章老师的演讲比较充实，用满45分钟，我们可以有两个提问题的机会。

提问：您好，我是金山软件的一个普通开发员，我想问跨机房容载，一旦一个机房大了以后，另一个机房怎么做？就是平时是处于50%、50%的工作状态，还是一个是工作，一个是零负荷？
章文嵩：这涉及到核心的路由器的功能比如说VIP1在一个机房工作，那VIP2在另外一个机房工作，但VIP1会备份到这边来，VIP2也会备份到另一个数据上去，前面的核心的路由器，比如说我们用的比较简单的方式，一个IP地址在一个地方有效，如果这个机房当掉了，可以配到另外一个机房。但前面的新路由器可以根据同一个链接送到同一个机房去，两边都可以送，哪怕一个IP地址也可以用这个ACTIVY（谐音）的方式。

提问：我想问一下这套系统的可用性是怎么定义的？一般是怎么来说这个可用性？
章文嵩：一方面就是它的影响度，就是我们大概有两种指标，我们对多少比例的客户造成影响了，就定成一个不可用，从用户的角度联谊不可用的时间。另外我们会从整个产品的角度定义一个不可用时间，这方面就是我们会全区的加成，就是以用户感知定义可用的时间，就是多少比例的用户受可用，那这个不可用的时间，比如说我们的SEOB要求4个9、1个5，但我们自己内部是要求，我们过去有些系统要求是5个9，SLB目前做法是4个9、1个5，比如拿CDN来说，CDN的流量跟我们的组建流量差不多，如果流量下降20%，我们开始计不可用的时间。另外CDN对影响的用户有多少，如果影响到一定比例，我们从用户角度计不可用时间。

主持人：由于时间关系，提问时间到此结束！我们再次用掌声感谢章老师的分享！