4 月 10 日，由云原生计算基金会（CNCF）技术监督委员会投票决议，来自中国的开源项目 Dragonfly 正式晋升为 CNCF 孵化级别的托管项目，成为继 Harbor、TiKV 之后，第三个进入 CNCF 孵化阶段的中国项目。

CNCF 成立于 2015 年 7 月，是 Linux 基金会旗下的重要开源组织之一，围绕微服务、DevOps、持续交付、容器化四大特性，致力于维护和集成云原生相关开源技术，以支持编排容器化微服务架构应用。目前，CNCF 有会员公司超过 300 家，其中包括 AWS、Azure、Google、阿里云等全球主流的云计算厂商。CNCF 的技术监督委员会由 11 位具有丰富技术知识和行业背景的代表组成，为云原生社区提供技术领导。 

在“云”已经成为大众基础设施的今天，云原生被认为是云计算技术的 2.0 标准，而 CNCF 正是引领云原生技术发展的风向标，在业内具有举足轻重的地位。那么 Dragonfly 项目究竟凭何能够跻身 CNCF 孵化项目？其在云原生的技术生态中又扮演着怎样的角色呢？为深入了解 Dragonfly 项目的特性，以及云原生技术在国内的发展现状，我们邀请到了 CNCF 首位华人技术监督委员会委员（TOC）、阿里云资深技术专家李响先生，请他分享了 CNCF 与 Dragonfly 的相关情况。

关于 CNCF 与 TOC

CNCF 是如今最有影响力的开源组织之一，作为 CNCF 仅有的 11 名 TOC 之一，我们对于李响平时的工作十分好奇。据李响介绍，CNCF 基金会本质上是以项目为中心进行运作的，目标是为了让 CNCF 吸纳更好的项目，进而通过这些项目吸引更多最终的客户群体。有了更多的客户群体使用 CNCF 的项目之后，厂商会把这些开源项目组合成产品或者云服务，以更低的成本和更高的效率供客户使用，助推整个云原生生态形成一个健康发展的产业闭环。

所以，CNCF 是希望通过项目来连接基金会、开发者和厂商。因此，作为 TOC 的核心目标就是收集最好、最适合基金会云原生理念的项目，而李响个人的主要工作也是寻找最好的项目，就像一名“星探”一样。

李响还给我们介绍了 CNCF 内部的项目晋升机制。进入 CNCF 的每个项目会被分为沙箱阶段（ sandbox）、孵化（incubation） 和毕业（graduation）这三个阶段。沙箱阶段都是处于早期发展阶段的项目，TOC 们会去寻找一些有潜力的项目，为他们提供建议，促使其进入沙箱阶段。CNCF 基金会本身并不像 Linux 基金会已有十几年发展历程，它现在仍然还需要定义一些东西，比如沙箱阶段的项目到底意味着什么？进入沙箱阶段的流程又是如何？从沙箱阶段进入孵化该怎么做？它的标准是什么？定义这些也是 TOC 的责任，李响自己也在这方面投入了比较大的精力。

还有，如何分配 CNCF 有限的资源来保证基金会能够以项目为中心运作，如何能让 CNCF 既有创新能力，又能在吸纳进大量项目的同时保持它的先进性、中立性以及云原生理念，这些也都是 TOC 需要关心的问题。

Dragonfly 是什么？

官方资料显示，Dragonfly 项目主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发难题。Dragonfly 的架构主要解决了大规模镜像下载、远距离传输、带宽成本控制、安全传输这四大难题。

大规模镜像下载

图注：
PouchContainer：阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术。
Registry：容器镜像的存储仓库，每个镜像由多个镜像层组成，而每个镜像层又表现为一个普通文件。
SuperNode：Dragonfly 的服务端，它主要负责种子块的生命周期管理以及构造 P2P 网络并调度客户端互传指定分块。
Block：当通过 Dragonfly下载某层镜像文件时，SuperNode 会把整个文件拆分成一个个的块，SuperNode 中的分块称
为种子块，种子块由若干初始客户端下载并迅速在所有客户端之间传播，其中分块大小通过动态计算而来。
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 技术，Dragonfly 可以彻底解决镜像仓库的带宽瓶颈问题，充分利用各个 Peer 的硬件资源和网络传输能力，达到规模越大传输越快的效果。值得一提的是，Dragonfly 的系统架构不涉及对容器技术体系的任何改动，完全可以无缝支持容器使其拥有 P2P 镜像分发能力，以大幅提升文件分发效率。

远距离传输

Dragonfly 通过 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 能够进入 CNCF 的孵化阶段，说明项目本身确实有能够让 TOC 眼前一亮的地方。李响介绍，Dragonfly 主要解决的是大规模场景下的容器镜像分发的问题，它与传统的解决方式有很大的不同。传统的解决方式是中央式的存储以及分发，好处是实现比较简单，管控起来也比较方便，但是这种方式在大规模场景会遇到一些挑战，主要是由于难以更灵活的水平扩展处理突发的流量。

“举一个例子，在阿里内部一些场景和阿里云容器服务客户场景下，尤其是一些批量计算型的业务，都有可能在一分钟内有千级别的容器创建的吞吐，对于镜像分发也会产生相应的吞吐压力。应对这个高突发性且大规模的流量，最好的办法就是利用 P2P 的特性来做分布式的分发。Dragonfly 正是基于这个理念构建的一套系统，帮助用户和企业应对大规模容器场景，让容器生态能覆盖更多、更复杂的场景。Dragonfly 的理念在容器这个特定的领域还是比较领先的，应该是第一个尝试，也算是比较成功的探索和实践。” 

谈到 Dragonfly 为什么能够从沙箱阶段晋升至孵化项目，李响向我们介绍了 CNCF 内部的评判标准。CNCF 对孵化项目有一些基础的要求，比如项目的成熟度、使用普及度、贡献者的分布等等，而 Dragonfly 从这些相对客观的指标看是完全符合孵化要求的。从另外一方面看，CNCF 也会考虑到项目是否能帮助到云原生领域的技术和社区发展，是否能帮助到 CNCF 作为基金会自身的发展。这部分内容相对来讲比较主观，因此也是要 TOC 这个 11 人的组织进行投票的。从投票结果看，大部分人认可 Dragonfly 对于云原生领域和基金会的价值，因此被接受为孵化项目。 

在沙箱阶段时，Dragonfly 就在一些实际生产环境中展现了它的价值，包括电子商务、电信、金融和互联网等在内的各个行业场景下的应用。用户包括阿里巴巴、中国移动、Shopee、Bilibili、蚂蚁金服、虎牙、滴滴和 iFLYTEK 等。比如中国移动浙江分公司在生产环境中采用 Dragonfly 已有 3 年以上的历史，涉及超过  1000 台物理计算机，目前在 Dragonfly 上运行 200 多个业务系统和 1700 多个应用程序模块；新加坡电子商务平台 Shopee 也在生产环境中采用 Dragonfly 已有 1 年以上的历史，涉及 10K+ 台物理机器；国内视频弹幕网站 Bilibili 已在超过 3900 台机器的测试和生产环境中采用了 Dragonfly。来自 Bilibili 的工程师在注册表验证、稳定性等方面与 Dragonfly 社区合作并做出了积极贡献。

当然，作为 TOC 的李响，同时也是阿里云的资深工程师，其在推动 Dragonfly 项目晋升的过程中，也给项目团队提供了很多技术、生态方面的指导建议，比如和 Harbor 生态的连接、与阿里云产品的互动以更好地普及 Dragonfly 到终端用户等。

有什么意义？

我们了解到，李响本身也是 CNCF 另一个孵化阶段开源项目 Etcd 的作者，那么进入孵化阶段对于项目维护者们来说意味着什么呢？ 

“主要意味着有更大的责任去服务好云原生的用户和更好的连接相关生态，Dragonfly 后续的工作也会围绕这两个目标进行。在开源上要简化安装、升级流程，提高易用性、安全性等基础能力，让用户更容易的在企业级场景下开箱即用的使用 Dragonfly 项目。另外，我们也会推动 Dragonfly 与 CNCF 生态的和谐发展，提高集成能力，与 Harbor 、Quay、Clair 等项目更好配合，并且能够推动 OCI 在 Distribution 相关的标准化建设。”李响说。

而对于 CNCF 组织本身来说，新的项目从沙箱阶段晋升至孵化阶段，也意味着云原生生态版图得到了进一步的完善。李响透露，其实沙箱阶段的项目从某种意义上来讲并不属于正式的 CNCF 项目，因此 CNCF 并不会给沙箱阶段的项目投入非常多的资源，包括运营、市场、技术指导等。“孵化项目是 CNCF 正式项目的第一个阶段，基金会会投入更多资源协助和支持项目的发展，在技术上给予更多的指导和支持，帮助 Dragonfly 能够顺利从基金会毕业，成为云原生领域中的重要一环。” 

谈到 CNCF 项目的最后一个阶段（毕业），李响表示，能否毕业的主要考量还是项目的生态整体健康度以及项目成熟的情况，CNCF 希望毕业的项目能够做到生产可用，并且符合大部分企业的诉求。 

云原生的发展前景

如今，全球云原生建设正如火如荼地进行中，国内很多一线大厂也都开始积极拥抱云原生。李响介绍，云原生技术上主要的发展趋势主要有以下两点：

1. 标准化：越来越多的云原生技术涌现，使得对这些技术的统一描述、管理和打通的需求成为刚需 。
2. 向应用层上浮：云原生起步于基础设施层，但是正逐步向离用户更近的应用层迈进，最终实现软件天然生于云上长于云上的愿景。目前的主要障碍是基础设施与应用层之间的链接还没有完全建立起来，这一部分碎片化也非常严重，没有在离用户更进的层次把云原生的价值发挥到最佳程度。目前，阿里在积极参与这个工作，帮助 CNCF Landscape 补齐应用定义和应用交付领域，这也是 CNCF SIG App Delivery 目前正在推进的工作。 

目前，整个云原生的生态建设可以说是以容器编排系统 Kubernetes 为核心的，有个说法是：Kubernetes 是云原生时代的 Linux，同时有另一个更为宽泛的说法：云原生是开源的一大根基。李响表达了自己对于这两句话的理解：“ Kubernetes 的成功实际上归功于其实现了对云基础设施（计算、网络、存储等）的标准化抽象，这其实跟 Linux 这样一个标准化操作系统为我们屏蔽掉底层硬件细节的价值是完全一样的。正是有了这样的标准化基础设施抽象，整个云计算生态才能够在之上逐层定义更多的应用层能力，高效的实现云原生连接‘应用’与‘云’的核心价值。”

采访的最后，李响还给想要接触和学习云原生相关技术的开发者一些建议：目前国外云原生的发展主要集中在资源基础设施管理，应用基础设施（例如服务网格、可观察性等），以及应用运维与交付技术这三个领域当中。国内的云原生关注点当前还主要集中在基础设施管理，但是也正在迅速上浮到跟面向开发者的应用这一层。对于年轻的开发者，CNCF 官方社区、博客等，都是入门云原生技术一个比较好的渠道。

采访嘉宾介绍

李响，拥有浙江大学本科和卡耐基梅隆大学硕士学位，是 CoreOS 创始人之一，参与创建了 etcd、operator framework、rkt 等开源项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知。该项目目前吸纳超过 400 名贡献者、14000 个提交，发布超过 150 个版本，广受开发者认可。于 2019 年 1 月成为 CNCF 首位华人 TOC 。

在加入阿里云后，李响主要负责阿里巴巴大规模集群调度与管理系统，帮助阿里巴巴通过云原生技术初步完成了基础架构的转型，实现了资源利用率与软件的开发和部署效率的大幅提升，并同步支撑了云产品的技术演进。