深度解讀阿里巴巴雲原生鏡像分發系統 Dragonfly

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

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

原文連接