构建大型云计算平台分布式技术的实践

本文基于章文嵩博士在 2014 年 7 月 18 日的全球架构师峰会 ArchSummit 上的主题演讲《构建大型云计算平台分布式技术的实践》整理而成。演讲 slides 可从 ArchSummit 官网下载。

演讲者简介

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

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

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

云计算的挑战与需求

云计算跟淘宝在业务特点上有较大的不同，其中最大的不同就在于：淘宝、天猫是由四千多个小应用去支持的，都是分布式设计，很多情况下即使一两个应用宕机了，也不影响整体的服务，可以按部就班的修复。对于淘宝而言，只有交易量下降了 10% 以上的情况会算做是 P1 故障，开始计算全站不可用的时间。

而对于云计算的场景而言，一个云主机宕机了，对这个客户来说就是 100% 的不可用，而这可能是这个客户的全部“身家性命”。所以，云计算平台对可靠性、稳定性的需求是非常高的。以前我们可能网络遇到问题，但是上层应用设计得好，就把这个问题隐蔽掉了；而对于云平台，要求是更高的可靠性，而且数据不能丢，系统稳定，性能还要好——目前尽量跟用户自己买物理机的性能差不多，另外要能够快速定位问题，最好在用户发现问题之前就先把问题解决了，让用户感知不到。还有就是成本要低，比用户自己买服务器便宜是底线。

ECS 的分布式存储设计

ECS 是阿里云的云服务器产品线，也是我们销量最大的产品。其背后是分布式文件存储，支持快照制作、快照回滚、自定义镜像、故障迁移、网络组隔离、防攻击、动态升级等功能。ECS 的管理基于一个庞大的控制系统，目前一个控制系统可以控制 3600 台物理机的规模，未来计划要做到 5000 台到两万台。

这其中，数据可靠性是极为关键的。阿里云以前的做法是数据写入的时候同步写三份到分布式存储上的 chunk server 上之后才算成功，这种实现的开销大，延时长，造成当时阿里云的用户抱怨性能不好。后来，我们做了 2-3 异步，即同步写 2 份确保成功，异步写第三份，IO 性能上得到一定的改善。我们现在对这个过程再做优化：读写性能优化的关键在于返回成功的时间，因为吞吐率是时间的倒数，延时缩短性能就会提升。缩短延时的思路之一就是将原本过长的路程截断以进行缩短，同时保证数据的可靠性。其具体思路为：

• SSD+SATA 的混合存储方案，在 chunk server 上做二级存储。这个方案目前在 vm 上做到的 randwrite-4K-128 可达 5500 IOPS 左右
• cache 机制
• 以多线程事件驱动架构重构 TDC 和 Chunk Server 的实现，做到一个 IO 请求在物理机上只用一个线程完成所有工作，避免锁和上下文切换

下面详细介绍一下这几个机制的设计。

IO 路径上的各层 cache 与写 IO 的几种模式探索

从应用发出请求到数据写入磁盘的路径上有三层 cache，依次是应用程序的 user cache（如 MySQL buffer pool）、操作系统的缓存（如 Linux page cache）、以及存储硬件的 cache（如磁盘的缓存）。

由此可以引申出如下几种写 IO 的模式：

• buffer write，写入目标是 guest OS 的 page cache，通过 writeback 刷到硬盘的缓存，然后再通过自动刷或者 sync 命令触发的方式刷到持久化存储介质上。这种写方案的速度很快，缺点是数据完整性无法得到严密保证（取决于回写的策略），而且回写有可能引起阻塞而影响服务质量
• direct write ，从应用直接写到硬件上的缓存，绕过操作系统的 page cache。比如 MySQL 引擎自己有缓存机制，就可以使用 direct write 写到硬盘缓存然后再通过 sync 命令刷到下面的存储介质。绕过 page cache 的好处是避开了回写的影响，但数据仍然不是绝对可靠，sync 完毕之前数据仍然是不安全的
• write+sync，写入 page cache 的同时即调用 sync/fsync 直接写到存储介质，sync 返回算成功。此方式的好处是数据足够安全，缺点是慢，具体等待时间随着操作系统内存使用情况的不同而不同
• O_SYNC，加了此标签的写入操作会在数据写入硬盘缓存时同步刷到碟片上

以上就是系统提供的几种机制。以本地 SAS 盘作为参考，在虚拟机中以 4k 的块大小做 dd 的写入速度，buffer write 平均在 212MB/s，direct write 平均在 68MB/s，而 direct+sync 则平均在 257kB/s。实际应用中可以根据不同情况、不同应用选择不同的方式，一般来说 buffer write 和 direct write 是主流，两者加起来占据了 97% 的写操作。

云计算环境中的 IO

以上分析的是本地的情况，写入的目标是本地的硬盘缓存与存储介质。那么在云计算环境中，我们不仅可以选择本地，还可以有分布式存储。分布式存储相当于本地的存储介质，我们目前的思路是在其上加一层分布式缓存系统作为本地硬盘缓存的替代。相当于整个写 IO 路径在云计算环境中变成了：

VM SYNC->PV 前端 FLUSH-> 后端 ->host->cache 系统 -> 分布式存储系统

为了确保数据完整性，我们的语义全部符合 POSIX，将语义由以上路径从 VM 透传 IO 全链路。

cache 系统的效果

我们用以下指令对 ECS 的写性能进行测试：

 ./fio -direct=1 -iodepth=1 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G
 

在 iodepth=1 的状态，纯 SATA 分布式存储只有 200 左右的 iops，平均延时在 8ms，抖动幅度（标准方差）达到 7ms。

加入 SSD cache 系统之后，iops 提升到 600 左右，平均延时降低到 3ms，抖动幅度降低至 2ms 左右。

 ./fio -direct=1 -iodepth=8 -rw=randwrite -ioengine=libaio -bs=16k -numjobs=2 -runtime=30 -group_reporting -size=30G -name=/mnt/test30G
 

增加 iodepth 到 8 的状态，纯 SATA 分布式存储的 iops 提升至 2100 左右，平均延时在 7ms，抖动幅度依然是 7ms 左右。

加入 SSD cache 之后，iops 提升到 2900 左右，平均延时在 5ms 左右，抖动幅度约为 1ms。

以上是 cache 方案的两点好处：

1. 加速写请求。未来我们也会加入对读请求的加速
2. 降低分布式存储系统的抖动对上层应用的影响。这种抖动在高并发的情况对延时的影响相当大，Google 的 Jeff Dean 于 2013 年 2 月发表于 CACM 上的 The Tail at Scale 一文详细描述了这个影响：“如果有 1% 的概率请求延迟超过 1S，并发 100 个请求，然后等待所有请求返回，延时超过 1S 的概率为 63%”

ECS 不同的存储选择

目前在 ECS 上可以有几种实例选择：背后是纯 SATA 存储集群的实例，适合大部分应用；对于 IO 性能要求更高的应用可以选择混合存储集群；我们未来还会推出性能更高的纯 SSD 集群，预计将在 11 月 /12 月推出，目前的测试数据是物理机 chunk server 可以做到最高 18 万的 iops，虚机上可以把万兆跑满，iops 在 9 万左右，目前的问题就是跑满的状态需要消耗 6 颗 HT CPU，这一部分还有待优化。

另外，对于 Hadoop、HBase、MongoDB 这样本身已经考虑了 3 副本的系统，阿里云还提供了 SATA 本地磁盘和 SSD 本地磁盘的 ECS，减少不必要的冗余以降低成本。

以上就是我们对云服务器产品 ECS 的一些优化工作。云服务器理论上可以用来跑任何东西，但是通用的方案不适合做所有的事情。因此，阿里云同时提供了一些细分产品，在特定应用场景下将取舍做到极致——

SLB、RDS 与 OCS

SLB 是阿里云的负载均衡产品，提供了 4 层的（基于 LVS）和 7 层的（基于 Tengine），支持等价路由和 Anycast 跨机房容灾，同时具备防攻击的特性。一台 12 物理核机器的 SLB 的正常转发性能在 1200 万左右的 pps，心跳可以做几千台；而同等配置的 ECS（千兆网络）的转发性能只有 70 万左右的 pps，心跳也只能做两台。

RDS 是阿里云的数据库服务，跑在物理机上（而非虚拟机）。RDS 数据通道采用标准的三层架构，每层都做到机房和部件冗余，无状态设计；中间层提供了安全防护、流量调度和桥接的功能，管理通道以元数据库（MySQL）为中心，消息驱动，各组件异步通信，无状态支持热升级，一个控制系统下可以管理数万个 MySQL 实例。RDS 依赖于很多其他团队开发的组件，包括用 SLB 做负载均衡，接 ODPS 做过滤分析，SLS 做日志收集，OSS 做备份，OAS 做冷数据的备份，用精卫做分表，以及全链路的控制系统和组件监控。同等配置下，RDS 的 tps 要比 ECS 高两、三倍。

OCS 是阿里云的缓存服务，基于 Tair 搭建，前面的 Proxy 负责了安全访问控制、QoS、流控的工作。OCS 目前是一个集群都在一个机房，可随时扩容，对用户提供了全面的监控数据和图形展示。性能方面，OCS 上目前 99% 的请求都做到了 2ms 以内响应，去年双十一，整个 OCS 集群的能力做到了一秒内可处理一亿个请求。同等配置下，OCS 的成本要比 ECS 上自建 Memcached 便宜一半。

全链路监控与分析系统

监控分析系统目前在 RDS 上用的比较重。坦白讲去年 RDS 遇到很多问题，很大一部分问题就是闪断：背后的机器故障时，MySQL 实例会迁移，这时候如果客户端的应用做得好，应用会自动发起重连的请求，保持原先的连接，但很多应用做的时候并没有考虑这个问题。那时候很多游戏厂商遇到这个问题，让他们改程序也很困难，不可能一个一个帮助他们优化，所以就需要后端帮他们的实例做保持连接和重连的工作。

所以我们建立起全链路的监控，收集所有的 SQL 日志、网络行为和用户行为，注入到一个 Kafka 集群，然后用 JStorm 和 Spark 做实时分析，ODPS 做离线分析。目前每天的 SQL 日志语句的量级在几十个 T，可以在秒级发现问题，比如发现请求慢了，则会给用户提醒是否没有建索引，而网络异常、连接中断的情况则会及时报警。

目前这套系统先用在 RDS 上，未来各个云产品需要将自己的异常分析都抽象出来注入到这个系统当中，完成全产品线的全链路监控。

未来工作展望

首先，ECS 上全路径 IO 还需要持续优化，力求在全国、全球做到最好的性能。这涉及到 Cache 策略的优化，带 SSD 的读写缓存，存储与计算分离，万兆纯 SSD 集群，动态热点迁移技术，GPU 支持，LXC/cgroups 支持等。比如纯 SSD 的集群，iops 已经挖掘的很高的情况，如何降低 CPU 消耗？Cache 现在为了快速，往下刷的频率是比较高的，这方面的策略能否优化，做批量刷？以前部署的 SATA 集群，是否都加上 SSD 缓存？如果本地缓存的命中率在 90% 以上，是否可以做计算节点和存储节点分离，这样可以让计算和存储按自己的需求发展。未来实现动态的热点迁移，可以在云计算上要实现更高的超配，当一台物理机发生比较忙的情况下，系统能自动将一些实例迁移到比较闲的机器上。目前淘宝的聚石塔、阿里小贷都已经在阿里云，未来会将淘宝无缝迁移到云平台上并降低成本，这些都是 ECS 上未来需要做的工作。

RDS 方面，目前支持 MySQL 和 SQL Server，计划加入 PostgreSQL 以方便 Oracle 用户往这边迁移。容灾方面，目前是双机房容灾，成本还比较高，是否可以通过非常高速的非易失性网络存储来存储 redo log，容量不需要大，数据存储在分布式文件系统，做一个低成本的 RDS 方案，只是用户需要容忍几十秒的 MySQL 实例宕机重启的时间？这需要架构师做取舍，看我们要放弃一些什么以得到一些东西。

另外，全链路的监控与分析系统，我们也需要进一步应用到全线云产品之上。未来还会推出更多的云产品，包括无线网络加速、 AliBench 服务质量监测（目前在内部使用）、OCR 识别服务、深度学习的 CNN/DNN 计算服务等。

感谢杨赛对本文的整理。