Dragonfly 是一個由阿里巴巴開源的云原生鏡像分發系統，主要解決以 Kubernetes 為核心的分布式應用編排系統的鏡像分發難題。隨著企業數字化大潮的席卷，行業應用紛紛朝微服務架構演進，并通過云化平臺優化業務管理。Dragonfly 源于阿里巴巴，從實際落地場景出發，前瞻性地解決了云原生鏡像分發的效率、流控與安全三大難題。

Dragonfly 的由來

隨著阿里集團業務爆炸式增長，2015 年時發布系統日均發布量突破兩萬，很多應用的機器規模開始破萬，發布失敗率開始增高，而根本原因則是發布過程需要大量的文件拉取，文件服務器扛不住大量的請求，當然第一時間會想到服務器擴容，可是擴容后又發現后端存儲成為瓶頸且擴容成本也非常巨大（按照我們的計算，為了滿足業務需求，不阻礙業務的發展，后續至少需要 2000 臺高配物理機且上不封頂）。此外，大量來自不同 IDC 的客戶端請求消耗了巨大的網絡帶寬，造成網絡擁堵。

同時，阿里巴巴很多業務走向國際化，大量的應用部署在海外，海外服務器下載要回源國內，浪費了大量的國際帶寬，而且還很慢；如果傳輸大文件，網絡環境差，失敗的話又得重來一遍，效率極低。

于是我們很自然的就想到了 P2P 技術，P2P 技術并不新鮮，當時也調研了很多國內外的系統，但是調研的結論是這些系統的規模和穩定性都無法達到我們的期望，因此就有了 Dragonfly 這個產品的誕生。

Dragonfly 能解決哪些問題

作為一款通用文件分發系統，Dragonfly 主要能夠解決以下幾個方面的問題：

1. 大規模下載問題：應用發布過程中需要下載軟件包或者鏡像文件，如果同時有大量機器需要發布，比如 1000 臺，按照 500MB 大小的鏡像文件計算，如果直接從鏡像倉庫下載，假設鏡像倉庫的帶寬是 10000Mbps，那么理想狀態下至少需要 10 分鐘，而且實際情況很可能是倉庫早已被打掛。

2. 遠距離傳輸問題：針對跨地域跨國際的應用，比如阿里速賣通，它既要在國內部署，又要在美國和俄羅斯部署，而存儲軟件包的源一般只在一個地域，比如國內上海，那么在美國或者俄羅斯的機器當要下載軟件包的時候就要通過國際網絡傳輸，但是國際網絡不僅延時高而且極不穩定，嚴重影響傳輸效率，進而導致業務不能及時上線新功能或者問題補丁，由此甚至會產生業務故障。

3. 帶寬成本問題：除了傳輸效率問題，高昂的帶寬成本也是一個非常嚴重的問題，很多互聯網公司尤其是視頻相關的公司，帶寬成本往往可以占據其總體成本的很大一部分。

4. 安全傳輸問題：據統計，每年因為網絡安全問題導致的經濟損失高達 4500 億美元，所以安全必須是第一生命線，文件傳輸過程中如果不加入任何安全機制，文件內容很容易被嗅探到，假設文件中包含賬號或者秘鑰之類的數據，一旦被截獲，后果將不堪設想。

Dragonfly 是如何解決這些問題的

通過 P2P 技術解決大規模鏡像下載問題，原理如下：

針對上圖有幾個概念需要先解釋：

• PouchContainer：阿里巴巴集團開源的高效、輕量級企業級富容器引擎技術。

• Registry：容器鏡像的存儲倉庫，每個鏡像由多個鏡像層組成，而每個鏡像層又表現為一個普通文件。

• Block：當通過 Dragonfly 下載某層鏡像文件時，Dragonfly 的SuperNode會把整個文件拆分成一個個的塊，SuperNode 中的分塊稱為種子塊，種子塊由若干初始客戶端下載并迅速在所有客戶端之間傳播，其中分塊大小通過動態計算而來。

• SuperNode：Dragonfly 的服務端，它主要負責種子塊的生命周期管理以及構造 P2P 網絡并調度客戶端互傳指定分塊。

• DFget：Dragonfly 的客戶端，安裝在每臺主機上，主要負責分塊的上傳與下載以及與容器 Daemon 的命令交互

• Peer：下載同一個文件的 Host 彼此之間稱為 Peer。

主要下載過程如下：

1. 首先由 PouchContainer 發起 Pull 鏡像命令，該命令會被 DFget 代理截獲。

2. 然后由 DFget 向 SuperNode 發送調度請求。

3. SuperNode 在收到請求后會檢查對應的文件是否已經被緩存到本地，如果沒有被緩存，則會從 Registry 中下載對應的文件并生成種子塊數據（種子塊一旦生成就可以立即傳播，而并不需要等到 SuperNode 下載完成整個文件后才開始分發），如果已經被緩存，則直接生成分塊任務。

4. 客戶端解析相應的任務并從其他 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 主要做了以下幾個方面的工作：

1. 支持 HTTP Header 傳輸，以滿足那些需要通過 Header 來進行權限驗證的下載請求

2. 通過自研的數據存儲協議對數據塊進行包裝傳輸，后續還會對包裝的數據進行再加密

3. 即將支持安全加密功能插件化

4. 通過多重校驗機制，可以嚴格防止數據被篡改

Dragonfly 目前的成熟度如何

在阿里巴巴集團內部，Dragonfly 作為全集團基礎技術構件，目前已經承載了全集團 90%以上的文件下載任務，包括鏡像文件、應用軟件包、算法數據文件、靜態資源文件以及索引文件等等，日分發峰值目前可以達到 1 億次，為集團業務提供了高效穩定的文件分發能力；同時，每年雙十一大家買買買的過程中，其中最為關鍵的營銷活動數據（數 GB 大小）也是在將近零點的時候通過 Dragonfly 來成功（100%成功）抵達數萬臺機器上的，萬一在這個過程中有一點點問題，雙十一會如何，你懂的……

目前 Dragonfly 也已經開源，在開源社區中， 目前 Star 數 2500+，同時有非常多的外部用戶對 Dragonfly 表現出濃厚的興趣，也有很多外部公司正在使用 Dragonfly 來解決他們在鏡像或者文件分發方面遇到的各種問題，比如中國移動、滴滴、科大訊飛等；此外，Dragonfly 已成為全中國第三個進入CNCF Sandbox 級別的項目，后續我們還會繼續加油努力，爭取盡快畢業！

CNCF 總裁宣布 Dragonfly 加入 CNCF

通過以上介紹，我相信針對 Dragonfly 是否足夠成熟，大家心里應該也有桿秤了吧，當然，Dragonfly 還有很多事情需要不斷完善和改進，在這里誠邀各路人才，一起把 Dragonfly 打造成一款世界級的產品！

未來展望

1. 成為CNCF畢業項目，為云原生應用提供更加豐富和強大的文件分發能力。

2. 開源版與集團內部版融合，給社區開放出更多的高級特性。

3. 智能化方面進行更多探索和改進。