深度解讀阿里巴巴雲原生映象分發系統 Dragonfly

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. 智慧化方面進行更多探索和改進。