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

Dragonfly 目前承載了阿里全集團 90%以上的檔案下載任務、日分發峰值達到 1 億次，100%成功支撐雙十一營銷活動資料抵達數萬臺機器，github Star 數已達到 2500+。2018 年 11 月 14 日已正式進入 CNCF，成為 CNCF 沙箱級別專案（Sandbox Level Project）。

Dragonfly 的由來

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

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

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

Dragonfly 能解決哪些問題

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

1. 大規模下載問題：應用釋出過程中需要下載軟體包或者映象檔案，如果同時有大量機器需要釋出，比如 1000臺，按照 500MB 大小的映象檔案計算，如果直接從映象倉庫下載，假設映象倉庫的頻寬是 10000Mbps，那麼理想狀態下至少需要 10 分鐘，而且實際情況很可能是倉庫早已被打掛。
2. 遠距離傳輸問題：針對跨地域跨國際的應用，比如阿里速賣通，它既要在國內部署，又要在美國和俄羅斯部署，而儲存軟體包的源一般只在一個地域，比如國內上海，那麼在美國或者俄羅斯的機器當要下載軟體包的時候就要通過國際網路傳輸，但是國際網路不僅延時高而且極不穩定，嚴重影響傳輸效率，進而導致業務不能及時上線新功能或者問題補丁，由此甚至會產生業務故障。
3. 頻寬成本問題：除了傳輸效率問題，高昂的頻寬成本也是一個非常嚴重的問題，很多網際網路公司尤其是視訊相關的公司，頻寬成本往往可以佔據其總體成本的很大一部分。
4. 安全傳輸問題：據統計，每年因為網路安全問題導致的經濟損失高達 4500 億美元，所以安全必須是第一生命線，檔案傳輸過程中如果不加入任何安全機制，檔案內容很容易被嗅探到，假設檔案中包含賬號或者祕鑰之類的資料，一旦被截獲，後果將不堪設想。

Dragonfly 是如何解決這些問題的

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

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

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