阿里云开源镜像站搭建（深度解读阿里巴巴云原生镜像分发系统）

Dragonfly 是一个由阿里巴巴开源的云原生镜像分发系统，主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发难题。随着企业数字化大潮的席卷，行业应用纷纷朝微服务架构演进，并通过云化平台优化业务管理。Dragonfly 源于阿里巴巴，从实际落地场景出发，前瞻性地解决了云原生镜像分发的__效率、流控与安全__三大难题。

Dragonfly 目前承载了阿里全集团 90%以上的文件下载任务、日分发峰值达到 1 亿次，100%成功支撑双十一营销活动数据抵达数万台机器，github Star 数已达到 2500 。2018 年 11 月 14 日已正式进入 CNCF，成为 CNCF 沙箱级别项目（Sandbox Level Project）。

随着阿里集团业务爆炸式增长，2015 年时发布系统日均发布量突破两万，很多应用的机器规模开始破万，发布失败率开始增高，而根本原因则是发布过程需要大量的文件拉取，文件服务器扛不住大量的请求，当然第一时间会想到服务器扩容，可是扩容后又发现后端存储成为瓶颈且扩容成本也非常巨大（按照我们的计算，为了满足业务需求，不阻碍业务的发展，后续至少需要 2000 台高配物理机且上不封顶）。此外，大量来自不同 IDC 的客户端请求消耗了巨大的网络带宽，造成网络拥堵。

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

针对上图有几个概念需要先解释：

• PouchContainer：阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术。
• Registry：容器镜像的存储仓库，每个镜像由多个镜像层组成，而每个镜像层又表现为一个普通文件。
• Block：当通过Dragonfly下载某层镜像文件时，蜻蜓的SuperNode会把整个文件拆分成一个个的块，SuperNode 中的分块称为种子块，种子块由若干初始客户端下载并迅速在所有客户端之间传播，其中分块大小通过动态计算而来。
• SuperNode：Dragonfly的服务端，它主要负责种子块的生命周期管理以及构造 P2P 网络并调度客户端互传指定分块。
• DFget__：__Dragonfly的客户端，安装在每台主机上，主要负责分块的上传与下载以及与容器 Daemon 的命令交互
• Peer：下载同一个文件的 Host 彼此之间称为 Peer。

主要下载过程如下：

1. 首先由 Pouch Container 发起 Pull 镜像命令，该命令会被 DFget 代理截获。
2. 然后由 DFget 向 SuperNode 发送调度请求。
3. SuperNode 在收到请求后会检查对应的文件是否已经被缓存到本地，如果没有被缓存，则会从 Registry 中下载对应的文件并生成种子块数据（种子块一旦生成就可以立即传播，而并不需要等到 SuperNode 下载完成整个文件后才开始分发），如果已经被缓存，则直接生成分块任务。
4. 客户端解析相应的任务并从其他 Peer 或者 SuperNode 中下载分块数据，当某个 Layer 的所有分块下载完成后，一个 Layer 也就下载完毕，此时会传递给容器引擎使用，而当所有的 Layer 下载完成后，整个镜像也就下载完成了。

通过上述 P2P 技术，可以彻底解决镜像仓库的带宽瓶颈问题，充分利用各个 Peer 的硬件资源和网络传输能力，达到规模越大传输越快的效果。

Dragonfly的系统架构不涉及对容器技术体系的任何改动，完全可以无缝支持容器使其拥有 P2P 镜像分发能力，以大幅提升文件分发效率！

结合 CDN 与预热技术解决远距离传输问题

通过 CDN 缓存技术，每个客户端可以就近从 SuperNode 中下载种子块，而无需跨地域进行网络传输，CDN 缓存原理大致如下：

同一个文件的第一个请求者会触发检查机制，根据请求信息计算出缓存位置，如果缓存不存在，则触发回源同步操作生成种子块；否则向源站发送 HEAD 请求并带上 If-Modified-Since 字段，该字段的值为上次服务器返回的文件最后修改时间，如果响应码为 304，则表示源站中的文件目前还未被修改过，缓存文件是有效的，然后再根据缓存文件的元信息确定文件是否是完整的，如果完整，则缓存完全命中；否则需要通过断点续传方式把剩下的文件分段下载过来，断点续传的前提是源站必须支持分段下载，否则还是要同步整个文件。如果 HEAD 请求的响应码为200，则表示源站文件已被修改过，缓存无效，此时需要进行回源同步操作；如果响应码既不是 304 也不是 200，则表示源站异常或地址无效，下载任务直接失败。

通过 CDN 缓存技术可以解决客户端回源下载以及就近下载的问题，但是如果缓存不命中，针对跨域远距离传输的场景，SuperNode 回源同步的效率将会非常低，这会直接影响到整体的分发效率，为了解决该问题，Dragonfly采用了一种自动化层级预热机制来最大程度的提升缓存命中率，其大致原理如下：

通过 Push 命令把镜像文件推送到 Registry 的过程中，每推送完一层镜像就会立即触发 SuperNode 以 P2P 方式把该层镜像同步到 SuperNode 本地，通过这种方式，可以充分利用用户执行Push和Pull操作的时间间隙（大概10分钟左右），把镜像的各层文件同步到 SuperNode 中，这样当用户执行 Pull 命令时，就可以直接利用 SuperNode 中的缓存文件，自然而然也就没有远距离传输的问题了。

通过动态压缩和智能化调度解决带宽成本问题

通过动态压缩，可以在不影响 SuperNode 和 Peer 正常运行的情况下，对文件中最值得压缩的部分实施相应的压缩策略，从而可以节约大量的网络带宽资源，同时还能进一步提升分发速率，相比于传统的 HTTP 原生压缩方式，动态压缩主要有以下几个方面的优势：

动态压缩的优势首先自然是动态性，它可以保证只有在 SuperNode 和 Peer 负载正常的情况下才会开启压缩，同时只会对文件中最值得压缩的分块进行压缩且压缩策略也是动态确定的；此外，通过多线程压缩方式可以大幅提升压缩速率，而且借助 SuperNode 的缓存能力，整个下载过程只需要压缩一次即可，压缩收益比相对于 HTTP 原生方式至少提升 10 倍。

除了动态压缩外，通过 SuperNode 强大的任务调度能力，可以尽量使在同一个网络设备下的 Peer 互传分块，减少跨网络设备、跨机房的流量，从而进一步降低网络带宽成本。

通过加密插件解决安全传输问题

在下载某些敏感类文件（比如秘钥文件或者账号数据之类的文件）时，传输的安全性必须要得到有效保障，在这方面，Dragonfly主要做了以下几个方面的工作：

1. 支持 HTTP Header 传输，以满足那些需要通过 Header 来进行权限验证的下载请求
2. 通过自研的数据存储协议对数据块进行包装传输，后续还会对包装的数据进行再加密
3. 即将支持安全加密功能插件化
4. 通过多重校验机制，可以严格防止数据被篡改

Dragonfly目前的成熟度如何

在阿里巴巴集团内部，Dragonfly作为全集团基础技术构件，目前已经承载了全集团 90%以上的文件下载任务，包括镜像文件、应用软件包、算法数据文件、静态资源文件以及索引文件等等，日分发峰值目前可以达到 1 亿次，为集团业务提供了高效稳定的文件分发能力；同时，每年双十一大家买买买的过程中，其中最为关键的营销活动数据（数 GB 大小）也是在将近零点的时候通过Dragonfly来成功（100%成功）抵达数万台机器上的，万一在这个过程中有一点点问题，双十一会如何，你懂的......

目前 Dragonfly 也已经开源，在开源社区中， 目前 Star 数 2500 ，同时有非常多的外部用户对 Dragonfly 表现出浓厚的兴趣，也有很多外部公司正在使用 Dragonfly 来解决他们在镜像或者文件分发方面遇到的各种问题，比如中国移动、滴滴、科大讯飞等；此外，Dragonfly 已成为全中国第三个进入CNCF Sandbox 级别的项目，后续我们还会继续加油努力，争取尽快毕业！

通过以上介绍，我相信针对Dragonfly是否足够成熟，大家心里应该也有杆秤了吧，当然，Dragonfly还有很多事情需要不断完善和改进，在这里诚邀各路人才，一起把Dragonfly打造成一款世界级的产品！

1. 成为CNCF毕业项目，为云原生应用提供更加丰富和强大的文件分发能力。
2. 开源版与集团内部版融合，给社区开放出更多的高级特性。
3. 智能化方面进行更多探索和改进。

作者：amber涂南