Dragonfly 是一个由阿里巴巴开源的云原生镜像分发系统，主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发难题。随着企业数字化大潮的席卷，行业应用纷纷朝微服务架构演进，并通过云化平台优化业务管理。Dragonfly 源于阿里巴巴，从实际落地场景出发，前瞻性地解决了云原生镜像分发的效率、流控与安全三大难题。
2018 年 11 月 14 日已正式进入 CNCF，成为 CNCF 沙箱级别项目（Sandbox Level Project）。
随着阿里集团业务爆炸式增长，2015 年时发布系统日均发布量突破两万，很多应用的机器规模开始破万，发布失败率开始增高，而根本原因则是发布过程需要大量的文件拉取，文件服务器扛不住大量的请求，当然第一时间会想到服务器扩容，可是扩容后又发现后端存储成为瓶颈且扩容成本也非常巨大（按照我们的计算，为了满足业务需求，不阻碍业务的发展，后续至少需要 2000 台高配物理机且上不封顶）。此外，大量来自不同 IDC 的客户端请求消耗了巨大的网络带宽，造成网络拥堵。
同时，阿里巴巴很多业务走向国际化，大量的应用部署在海外，海外服务器下载要回源国内，浪费了大量的国际带宽，而且还很慢；如果传输大文件，网络环境差，失败的话又得重来一遍，效率极低。
于是我们很自然的就想到了 P2P 技术，P2P 技术并不新鲜，当时也调研了很多国内外的系统，但是调研的结论是这些系统的规模和稳定性都无法达到我们的期望，因此就有了 Dragonfly 这个产品的诞生。
作为一款通用文件分发系统，Dragonfly 主要能够解决以下几个方面的问题：
大规模下载问题：应用发布过程中需要下载软件包或者镜像文件，如果同时有大量机器需要发布，比如 1000 台，按照 500MB 大小的镜像文件计算，如果直接从镜像仓库下载，假设镜像仓库的带宽是 10000Mbps，那么理想状态下至少需要 10 分钟，而且实际情况很可能是仓库早已被打挂。
远距离传输问题：针对跨地域跨国际的应用，比如阿里速卖通，它既要在国内部署，又要在美国和俄罗斯部署，而存储软件包的源一般只在一个地域，比如国内上海，那么在美国或者俄罗斯的机器当要下载软件包的时候就要通过国际网络传输，但是国际网络不仅延时高而且极不稳定，严重影响传输效率，进而导致业务不能及时上线新功能或者问题补丁，由此甚至会产生业务故障。
带宽成本问题：除了传输效率问题，高昂的带宽成本也是一个非常严重的问题，很多互联网公司尤其是视频相关的公司，带宽成本往往可以占据其总体成本的很大一部分。
安全传输问题：据统计，每年因为网络安全问题导致的经济损失高达 4500 亿美元，所以安全必须是第一生命线，文件传输过程中如果不加入任何安全机制，文件内容很容易被嗅探到，假设文件中包含账号或者秘钥之类的数据，一旦被截获，后果将不堪设想。
通过 P2P 技术解决大规模镜像下载问题，原理如下：
针对上图有几个概念需要先解释：
PouchContainer：阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术。
Registry：容器镜像的存储仓库，每个镜像由多个镜像层组成，而每个镜像层又表现为一个普通文件。
Block：当通过 Dragonfly 下载某层镜像文件时，Dragonfly 的SuperNode会把整个文件拆分成一个个的块，SuperNode 中的分块称为种子块，种子块由若干初始客户端下载并迅速在所有客户端之间传播，其中分块大小通过动态计算而来。
SuperNode：Dragonfly 的服务端，它主要负责种子块的生命周期管理以及构造 P2P 网络并调度客户端互传指定分块。
DFget：Dragonfly 的客户端，安装在每台主机上，主要负责分块的上传与下载以及与容器 Daemon 的命令交互
Peer：下载同一个文件的 Host 彼此之间称为 Peer。
主要下载过程如下：
首先由 PouchContainer 发起 Pull 镜像命令，该命令会被 DFget 代理截获。
然后由 DFget 向 SuperNode 发送调度请求。
SuperNode 在收到请求后会检查对应的文件是否已经被缓存到本地，如果没有被缓存，则会从 Registry 中下载对应的文件并生成种子块数据（种子块一旦生成就可以立即传播，而并不需要等到 SuperNode 下载完成整个文件后才开始分发），如果已经被缓存，则直接生成分块任务。
客户端解析相应的任务并从其他 Peer 或者 SuperNode 中下载分块数据，当某个 Layer 的所有分块下载完成后，一个 Layer 也就下载完毕，此时会传递给容器引擎使用，而当所有的 Layer 下载完成后，整个镜像也就下载完成了。
通过上述 P2P 技术，可以彻底解决镜像仓库的带宽瓶颈问题，充分利用各个 Peer 的硬件资源和网络传输能力，达到规模越大传输越快的效果。
Dragonfly 的系统架构不涉及对容器技术体系的任何改动，完全可以无缝支持容器使其拥有 P2P 镜像分发能力，以大幅提升文件分发效率！
结合 CDN 与预热技术解决远距离传输问题
通过 CDN 缓存技术，每个客户端可以就近从 SuperNode 中下载种子块，而无需跨地域进行网络传输，CDN 缓存原理大致如下：
通过 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 主要做了以下几个方面的工作：
支持 HTTP Header 传输，以满足那些需要通过 Header 来进行权限验证的下载请求
通过自研的数据存储协议对数据块进行包装传输，后续还会对包装的数据进行再加密
即将支持安全加密功能插件化
通过多重校验机制，可以严格防止数据被篡改
在阿里巴巴集团内部，Dragonfly 作为全集团基础技术构件，目前已经承载了全集团 90%以上的文件下载任务，包括镜像文件、应用软件包、算法数据文件、静态资源文件以及索引文件等等，日分发峰值目前可以达到 1 亿次，为集团业务提供了高效稳定的文件分发能力；同时，每年双十一大家买买买的过程中，其中最为关键的营销活动数据（数 GB 大小）也是在将近零点的时候通过 Dragonfly 来成功（100%成功）抵达数万台机器上的，万一在这个过程中有一点点问题，双十一会如何，你懂的……
目前 Dragonfly 也已经开源，在开源社区中， 目前 Star 数 2500+，同时有非常多的外部用户对 Dragonfly 表现出浓厚的兴趣，也有很多外部公司正在使用 Dragonfly 来解决他们在镜像或者文件分发方面遇到的各种问题，比如中国移动、滴滴、科大讯飞等；此外，Dragonfly 已成为全中国第三个进入CNCF Sandbox 级别的项目，后续我们还会继续加油努力，争取尽快毕业！
CNCF 总裁宣布 Dragonfly 加入 CNCF
通过以上介绍，我相信针对 Dragonfly 是否足够成熟，大家心里应该也有杆秤了吧，当然，Dragonfly 还有很多事情需要不断完善和改进，在这里诚邀各路人才，一起把 Dragonfly 打造成一款世界级的产品！
成为CNCF毕业项目，为云原生应用提供更加丰富和强大的文件分发能力。
开源版与集团内部版融合，给社区开放出更多的高级特性。
智能化方面进行更多探索和改进。
原文链接：https://mp.weixin.qq.com/s/UUZDIGopz5UruRpnxcOZ8Q
