阿里双11超级工程：PB级文件分发重器蜻蜓

有图有介绍见： http://tech.it168.com/a2017/1114/3179/000003179630.shtml

蜻蜓开源地址：https://github.com/alibaba/dragonfly

2017天猫双11， 交易峰值32.5万/秒，支付峰值25.6万/秒，数据库处理峰值4200万次／秒，成交额1682亿数字的背后是50+神秘技术！其中，阿里集团基础设施蜻蜓，在双11期间，对上万台服务器同时下发5GB的数据文件，让大规模文件分发靠蜻蜓系统完美渡过。

 

蜻蜓，经过解决大规模文件下载以及跨网络隔离等场景下各类难题，大幅提升数据预热、大规模容器镜像分发等业务能力。月均分发次数突破20亿次，分发数据量3.4PB。其中容器镜像分发比natvie方式提速可高达57倍，registry网络出口流量下降99.5%以上。今天，阿里巴巴集团基础架构事业群运维中台负责人，亲历者如柏，将为咱们详述蜻蜓从文件分发到镜像传输的技术之路。

 

 

毛茂德（如柏）  阿里巴巴集团基础架构事业群运维中台负责人

 

做者简介：毛茂德（花名：如柏）：阿里巴巴集团基础架构事业群运维中台负责人，亲历者。主导架构设计高可靠、高并发、大规模的基础运维平台和应用运维平台, 十余年来坚持不懈的追求研发、测试、运维效率提高，推进DevOps实施落地。目前正致力于打造基于混合云的应用运维无人值守解决方案以及自动化、数据化、智能化应用运维解决方案。曾任职于IONA，RedHat，eBay，也是 Apache 顶级项目CXF 初创成员之一。

 

问题的起源

蜻蜓是阿里自研的P2P文件分发系统，是阿里基础运维平台重要组成部分，是云效-智能运维平台的核心竞争力，也是阿里云容器服务的关键组件。

 

蜻蜓的诞生倒是要从15年开始讲起了。

 

随着阿里业务爆炸式增加，15年时发布系统日均的发布量突破两万，不少应用的规模开始破万，发布失败率开始增高，而根因就是发布过程须要大量的文件拉取，文件服务器扛不住大量的请求，固然很容易想到服务器扩容，但是扩容后又发现后端存储成为瓶颈。此外， 大量来自不一样IDC的客户端请求消耗了巨大的网络带宽，形成网络拥堵。

 

同时，不少业务走向国际化，大量的应用部署在海外，海外服务器下载要回源国内，浪费了大量的国际带宽，并且还很慢；若是传输大文件，网络环境差，失败的话又得重来一遍，效率极低。

 

因而很天然的就想到了P2P技术，由于P2P技术并不新鲜， 当时也调研了不少国内外的系统，可是调研的结论是这些系统的规模和稳定性都没法达到咱们的指望。因此就有了蜻蜓这个产品。

设计目标

 

针对这些痛点，蜻蜓在设计之初定了几个目标：

 

1.    解决文件源被打爆的问题，在Host之间组P2P网，缓解文件服务器压力，节约跨IDC之间的网络带宽资源。

2.    加速文件分发速度，而且保证上万服务器同时下载跟一台服务器下载没有太大的波动。

3.    解决跨国下载加速和带宽节约。

4.    解决大文件下载问题，同时必需要支持断点续传。

5.    Host上的磁盘IO，网络IO必须能够被控制，以免对业务形成影响

系统架构

 

▲图1. 蜻蜓总体架构

 

总体架构分三层，第一层是Config Service， 他管理全部的Cluster Manager，Cluster Manager又管理全部的Host， Host就是终端，dfget就是相似wget同样的一个客户端程序。

 

Config Service 主要负责Cluster Manager的管理、客户端节点路由、系统配置管理以及预热服务等等。简单的说，就是负责告诉Host，离他最近的一组Cluster Manager的地址列表，并按期维护和更新这份列表，使的Host老是能找到离他最近的Cluster Manager。

 

Cluster Manager 主要的职责有两个：1、以被动CDN方式从文件源下载文件并生成一组种子分块数据；2、构造P2P网络并调度每一个peer之间互传指定的分块数据。

 

Host上就存放着dfget，dfget的语法跟wget很是相似。主要功能包括文件下载和P2P共享等。

 

在阿里内部咱们能够用StarAgent来下发dfget指令让一组机器同时下载文件，在某种场景下一组机器可能就是阿里全部的服务器。因此使用起来很是高效。除了客户端外， 蜻蜓还有Java SDK，可让你将文件“PUSH”到一组服务器上。

 

下面这个图阐述了两个终端同时调用dfget下载同一个文件时系统的交互示意图：

 

▲图2. 蜻蜓P2P组网逻辑示意图

 

两个Host和CM会组成一个P2P网络，首先CM会查看本地是否有缓存，若是没有，就会回源下载，文件固然会被分片，CM会多线程下载这些分片， 同时会将下载的分片提供给Host们下载， Host下载完一个分片后， 同时会提供出来给peer下载，如此类推， 直到全部的Host所有下载完。

 

本地下载的时候会将下载分片的状况记录在metadata里， 若是忽然中断了下载，再次执行dfget命令， 会断点续传。

 

下载结束后， 还会比对MD5，以确保下载的文件和源文件是彻底一致的。蜻蜓经过HTTP cache协议来控制CM端对文件的缓存时长，CM端固然也有本身按期清理磁盘的能力， 确保有足够的空间支撑长久的服务。

 

在阿里还有不少文件预热的场景，须要提早把文件推送到CM端， 包括容器镜像、索引文件、业务优化的cache文件等等。

在初版上线后，咱们进行了一轮测试， 结果以下图：

 

▲图3. 传统下载和蜻蜓P2P下载测试结果对比图

 

X轴是客户端数量， Y轴是下载时长，

文件源：测试目标文件200MB，（网卡：千兆bit/s）

Host端：百兆bit/s网卡

CM端：2台服务器（24核 64G，网卡：千兆bit/s)

 

从这个图能够看出两个问题：

1.    传统模式随着客户端的增长， 下载时长跟着增长，而dfget能够支撑到7000客户端依然没变好

2.    传统模式到了1200客户端之后就没有数据了，由于数据源被打爆了

 

每一年双11以前都是发布高峰期，15年双11就是靠蜻蜓完美渡过了。

从发布系统走向基础设施

 

15年双11后，蜻蜓的下载次数就达到了12万/月，分发量4TB。当时在阿里还有用别的下载工具，如wget， curl，scp， ftp 等等，也有自建的小规模文件分发系统。咱们除了全面覆盖自身发布系统外， 也作了小规模的推广。到16年双11左右，咱们的下载量就达到了1.4亿/月，分发量708TB。业务增加了近千倍。

 

16年双11后咱们提出了一个更高的目标， 咱们但愿阿里大规模文件分发和大文件分发90%的业务由蜻蜓来承担。咱们但愿蜻蜓成为全集团的基础设施。

 

我但愿经过这个目标锤炼出最好的P2P文件分发系统。此外也能够统一集团内全部的文件分发系统。统一可让更多的用户受益，但统一历来不是终极目标，统一的目的是：

1.    减小重复建设

2.    全局优化

只要优化蜻蜓一个系统， 全集团都能受益。好比咱们发现系统文件是天天全网分发的， 而光这一个文件压缩的话就能给公司天天节省9TB网络流量。跨国带宽资源尤为宝贵。而若是你们各用各的分发系统， 相似这样的全局优化就无从谈起。

因此统一势在必行！

在大量数据分析基础上，咱们得出全集团文件分发的量大概是3.5亿次/周， 而咱们当时的占比只有10%不到。

 

通过半年努力，在17年4月份，咱们终于实现了这个目标， 90%+的业务占有率。业务量增加到3亿次/周（跟咱们以前分析的数据基本吻合），分发量977TB，这个数字比半年前一个月的量还大。

固然这里不得不说跟阿里容器化也是密不可分的，镜像分发流量大约占了一半。下面咱们就来介绍下蜻蜓是如何支持镜像分发的。在说镜像分发以前固然要先说下阿里的容器技术。

阿里的容器技术

容器技术的优势天然不须要多介绍了，全球来看， 容器技术以Docker为主占了大部分市场，固然除此以外还有其余解决方案，好比rkt，Mesos Uni Container， LXC等，而阿里的容器技术命名为Pouch。早在2011年，阿里就自主研发了基于LXC的容器技术T4，只是当时咱们没有创造镜像这个概念， T4仍是当作虚拟机来用， 固然比虚拟机要轻量的多。

2016年阿里在T4基础上作了重大升级，演变为今天的Pouch，而且已经开源。目前Pouch容器技术已经覆盖阿里巴巴集团几乎全部的事业部，在线业务100%容器化，规模高达数十万。镜像技术的价值扩大了容器技术的应用边界，而在阿里如此庞大的应用场景下，如何实现高效“镜像分发”成为一个重大命题。

回到镜像层面。宏观上，阿里巴巴有规模庞大的容器应用场景；微观上，每一个应用镜像在镜像化时，质量也存在良莠不齐的状况。

理论上讲用镜像或者用传统“基线”模式，在应用大小上不该该有很是大的区别。但事实上这彻底取决于Dockerfile写的好坏，也取决于镜像分层是否合理。阿里内部其实有最佳实践，可是每一个团队理解接受程度不一样， 确定会有用的好坏的之分。尤为在一开始，你们打出来的镜像有3～4GB这都是很是常见的。

 

因此做为P2P文件分发系统，蜻蜓就有了用武之地，不管是多大的镜像，不管是分发到多少机器， 即便你的镜像打的很是糟糕， 咱们都提供很是高效的分发，都不会成瓶颈。这样就给咱们快速推广容器技术，让你们接受容器运维模式，给予了充分消化的时间。

容器镜像

在讲镜像分发以前先简单介绍下容器镜像，咱们先看下Ubuntu系统的镜像：咱们能够经过命令 docker history ubuntu:14.04 查看 ubuntu:14.04，结果以下：

须要额外注意的是：镜像层 d2a0ecffe6fa 中没有任何内容，也就是所谓的空镜像。

镜像是分层的，每层都有本身的ID和尺寸，这里有4个Layer，最终这个镜像是由这些Layer组成。

 

Docker镜像是经过Dockerfile来构建，看一个简单的Dockerfile：

镜像构建过程以下图所示：

 

能够看到，新镜像是从 base 镜像一层一层叠加生成的。每安装一个软件，就在现有镜像的基础上增长一层。

 

当容器启动时，一个可写层会被加载到镜像的顶层，这个可读可写层也被称为“容器层”，容器层之下都是“镜像层”，都是只读的。

若是镜像层内容为空，相应的信息会在镜像json文件中描述，若是镜像层内容不为空，则会以文件的形式存储在OSS中。

镜像分发

▲图4. Docker 镜像下载流程图

 

以阿里云容器服务为例， 传统的镜像传输如上图所示，固然这是最简化的一种架构模式， 实际的部署状况会复杂的多， 还会考虑鉴权、安全、高可用等等。

 

从上图能够看出来，镜像传输跟文件分发有相似的问题， 当有一万个Host同时向Registry请求时， Registry就会成为瓶颈，还有海外的Host访问国内Registry时候也会存在带宽浪费、延时变长、成功率降低等问题。

 

下面介绍下Docker Pull的执行过程：

▲图5. Docker 镜像分层下载图

 

Docker Daemon调用Registry API获得镜像的Manifest，从Manifest中能算出每层的URL，Daemon随后把全部镜像层从Registry并行下载到Host本地仓库。

 

因此最终，镜像传输的问题变成了各镜像层文件的并行下载的问题。而蜻蜓擅长的正是将每层镜像文件从Registry用P2P模式传输到本地仓库中。

 

那么具体又是如何作到的呢？

 

事实上咱们会在Host上启动dfGetproxy，Docker/Pouch Engine的全部命令请求都会经过这个proxy，咱们看下图：

 

▲图6. 蜻蜓P2P容器镜像分发示意图

首先docker pull命令，会被dfget proxy截获，而后由dfget proxy向CM发送调度请求，CM在收到请求后会检查对应的下载文件是否已经被缓存到本地，若是没有被缓存，则会从Registry中下载对应的文件并生成种子分块数据（种子分块数据一旦生成就能够当即被使用），若是已经被缓存，则直接生成分块任务，请求者解析相应的分块任务并从其余peer或者supernode中下载分块数据，当某个Layer的全部分块下载完成后，一个Layer也就下载完毕了，一样，当全部的Layer下载完成后，整个镜像也就下载完成了。

 

蜻蜓支持容器镜像分发，也有几个设计目标：

1. 大规模并发：必须能支持十万级规模同时Pull镜像

 

2. 不侵入容器技术内核（Docker Daemon， Registry），也就是说不能改动容器服务任何代码。

 

3. 支持Docker， Pouch， Rocket ，Hyper等全部容器/虚拟机技术

 

4. 支持镜像预热（构建时就推送到蜻蜓集群CM）

 

5. 支持大镜像文件 （至少30GB）

 

6. 安全

Native Docker V.S 蜻蜓

咱们一共作了两组实验：

 

实验一：1个客户端

1.    测试镜像大小：50MB、200MB、500MB、1GB、5GB

2.    镜像仓库带宽：15Gbps

3.    客户端带宽：双百兆bit/s网络环境

4.    测试规模：单次下载

 

▲图7. 单客户端不一样模式对比图

 

Native和蜻蜓（关闭智能压缩特性）平均耗时基本接近，蜻蜓稍高一点，由于蜻蜓在下载过程当中会校验每一个分块数据的MD5值，同时在下载以后还会校验整个文件的MD5，以保证下载的文件跟源是一致的；而开启了智能压缩的模式下，其耗时比Native模式还低！

 

实验二：多客户端并发

 

1.    测试镜像大小：50MB、200MB、500MB、1GB、5GB

2.    镜像仓库带宽：15Gbps

3.    客户端带宽：双百兆bit/s网络环境

4.    多并发：10并发、200并发、1000并发   

▲图8.不一样镜像大小和并发数的对比图

 

上图能够看出，随着下载规模的扩大，蜻蜓与Native模式耗时差别显著扩大，最高可提速能够达20倍。在测试环境中源的带宽也相当重要，若是源的带宽是2Gbps，提速可达57倍。

 

下图是下载文件的总流量（并发数 * 文件大小）和回源流量（去Registry下载的流量）的一个对比，

 

▲图9. 蜻蜓镜像分发出流量对比图

 

向200个节点分发500M的镜像，比docker原生模式使用更低的网络流量，实验数据代表采用蜻蜓后，Registry的出流量下降了99.5%以上；而在1000并发规模下，Registry的出流量更能够下降到99.9%左右。

 

在阿里的效果

 

蜻蜓在阿里投入使用大概已有两年， 两年来业务发展迅速，从分发的次数来统计目前一个月接近20亿次，分发3.4PB数据。其中容器镜像的分发量接近一半。

▲图10. 蜻蜓在阿里文件vs镜像分发流量趋势图

 

在阿里最大的一次分发应该就是今年双11期间， 要对上万台服务器同时下发5GB的数据文件。

走向智能化

 

阿里在AIOps起步虽然不是最先， 可是咱们近年来投入巨大，并在不少产品上有所应用。蜻蜓这个产品中有如下应用：

 

智能流控

 

流控在道路交通中很常见，好比中国道路限速规定，没有中心线的公路，限速为40千米/小时；同方向只有1条机动车道的公路，限速为70千米/小时；快速道路80千米；高速公路最高限速为120千米/小时等等。这种限速对每辆车都同样，显然不够灵活，因此在道路很是空闲的状况下道路资源实际上是很是浪费的，总体效率很是低下。

 

红绿灯其实也是流控的手段，如今的红绿灯都是固定时间，不会根据现实的流量来作智能的判断，因此去年10月召开的云栖大会上，王坚博士曾感慨，世界上最遥远的距离不是从南极到北极，而是从红绿灯到交通摄像头，它们在同一根杆上，但历来没有经过数据被链接过，摄像头看到的东西永远不会变成红绿灯的行动。这既浪费了城市的数据资源，也加大了城市运营发展的成本。

 

蜻蜓其中一个参数就是控制磁盘和网络带宽利用率的， 用户能够经过参数设定使用多少网络IO/磁盘IO。如上所述，这种方法是很是僵化的。因此目前咱们智能化方面的主要思想之一是但愿相似的参数不要再人为来设定，而是根据业务的状况结合系统运行的状况，智能的决定这些参数的配置。最一开始可能不是最优解，可是通过一段时间运行和训练后自动达到最优化的状态。保证业务稳定运行同时又尽量的充分利用网络和磁盘带宽，避免资源浪费。

 

智能调度

 

分块任务调度是决定整个文件分发效率高低与否的关键因素，若是只是经过简单的调度策略，好比随机调度或者其余固定优先级的调度，这种作法每每会引发下载速率的频繁抖动，很容易致使下载毛刺过多，同时总体下载效率也会不好；为了最优化任务调度，咱们经历了无数次的尝试和探索，最终经过多维度（好比机器硬件配置、地理位置、网络环境、历史下载结果和速率等等维度的数据）的数据分析（主要利用了梯度降低算法，后续还会尝试其余算法）智能动态决定当前请求者最优的后续分块任务列表。

 

智能压缩

 

智能压缩会对文件中最值得压缩的部分实施相应的压缩策略，从而能够节约大量的网络带宽资源。

 

对容器镜像目前的实际平均数据来看，压缩率(Compression Ration)是40%，也就是说100MB镜像能够压缩到40MB。针对1000并发规模，经过智能压缩能够减小60%的流量。

 

 

安全

在下载某些敏感的文件（好比秘钥文件或者帐号数据文件等）时，传输的安全性必需要获得有效的保证，在这方面，蜻蜓主要作了两个工做：

1、支持携带HTTP的Header数据，以知足那些须要经过header来进行权限验证的文件源；

2、利用对称加密算法，对文件内容进行传输加密。

 

开源

 

随着容器技术的流行，容器镜像这类大文件分发成为一个重要问题，为了更好的支持容器技术的发展，数据中心大规模文件的分发，阿里决定开源蜻蜓来更好的推动技术的发展。阿里将持续支持开源社区，并把本身通过实战检验的技术贡献给社区。敬请期待。

 

商业化

 

蜻蜓除了用于阿里集团内部容器化，也彻底兼容社区版Docker，能够和[阿里云容器服务](https://www.aliyun.com/product/containerservice)和飞天专有云敏捷版(https://yq.aliyun.com/articles/224507)无缝结合在一块儿，在公共云和专有云环境下支撑大规模的容器镜像分发。

总结

 

蜻蜓经过使用P2P技术同时结合智能压缩、智能流控等多种创新技术，解决大规模文件下载以及跨网络隔离等场景下各类文件分发难题，大幅提升数据预热、大规模容器镜像分发等业务能力。

蜻蜓支持多种容器技术，对容器自己无需作任何改造，镜像分发比natvie方式提速可高达57倍，Registry网络出流量下降99.5%以上。承载着PB级的流量的蜻蜓，在阿里已然成为重要的基础设施之一，为业务的极速扩张和双11大促保驾护航。

 

Reference

 

【1】Docker Overview：

https://docs.docker.com/engine/docker-overview/

【2】Where are docker images stored：

http://blog.thoward37.me/articles/where-are-docker-images-stored/

【3】Image Spec：

https://github.com/moby/moby/blob/master/image/spec/v1.md

【4】Pouch开源地址：

https://github.com/alibaba/pouch

【5】蜻蜓开源地址：

https://github.com/alibaba/dragonfly

【6】阿里云容器服务：

https://www.aliyun.com/product/containerservice

【7】飞天专有云敏捷版：

https://yq.aliyun.com/articles/224507

【8】云效：

https://www.aliyun.com/product/yunxiao