随着阿裡集團業務爆炸式增長，2015 年時釋出系統日均釋出量突破兩萬，很多應用的機器規模開始破萬，釋出失敗率開始增高，而根本原因則是釋出過程需要大量的檔案拉取，檔案伺服器扛不住大量的請求，當然第一時間會想到伺服器擴容，可是擴容後又發現後端存儲成為瓶頸且擴容成本也非常巨大（按照我們的計算，為了滿足業務需求，不阻礙業務的發展，後續至少需要 2000 台高配實體機且上不封頂）。此外，大量來自不同 IDC 的用戶端請求消耗了巨大的網絡帶寬，造成網絡擁堵。
同時，阿裡巴巴很多業務走向國際化，大量的應用部署在海外，海外伺服器下載下傳要回源國内，浪費了大量的國際帶寬，而且還很慢；如果傳輸大檔案，網絡環境差，失敗的話又得重來一遍，效率極低。
于是我們很自然的就想到了 P2P 技術，P2P 技術并不新鮮，當時也調研了很多國内外的系統，但是調研的結論是這些系統的規模和穩定性都無法達到我們的期望，是以就有了 Dragonfly 這個産品的誕生。
Dragonfly 能解決哪些問題作為一款通用檔案分發系統，Dragonfly 主要能夠解決以下幾個方面的問題：
● 大規模下載下傳問題：應用釋出過程中需要下載下傳軟體包或者鏡像檔案，如果同時有大量機器需要釋出，比如 1000 台，按照 500MB 大小的鏡像檔案計算，如果直接從鏡像倉庫下載下傳，假設鏡像倉庫的帶寬是 10000Mbps，那麼理想狀态下至少需要 10 分鐘，而且實際情況很可能是倉庫早已被打挂。
● 遠距離傳輸問題：針對跨地域跨國際的應用，比如阿裡速賣通，它既要在國内部署，又要在美國和俄羅斯部署，而存儲軟體包的源一般隻在一個地域，比如國内上海，那麼在美國或者俄羅斯的機器當要下載下傳軟體包的時候就要通過國際網絡傳輸，但是國際網絡不僅延時高而且極不穩定，嚴重影響傳輸效率，進而導緻業務不能及時上線新功能或者問題更新檔，由此甚至會産生業務故障。
● 帶寬成本問題：除了傳輸效率問題，高昂的帶寬成本也是一個非常嚴重的問題，很多網際網路公司尤其是視訊相關的公司，帶寬成本往往可以占據其總體成本的很大一部分。
● 安全傳輸問題：據統計，每年因為網絡安全問題導緻的經濟損失高達 4500 億美元，是以安全必須是第一生命線，檔案傳輸過程中如果不加入任何安全機制，檔案内容很容易被嗅探到，假設檔案中包含賬号或者秘鑰之類的資料，一旦被截獲，後果将不堪設想。
Dragonfly 是如何解決這些問題的通過 P2P 技術解決大規模鏡像下載下傳問題，原理如下：
針對上圖有幾個概念需要先解釋：
● PouchContainer：阿裡巴巴集團開源的高效、輕量級企業級富容器引擎技術。
● Registry：容器鏡像的存儲倉庫，每個鏡像由多個鏡像層組成，而每個鏡像層又表現為一個普通檔案。
● Block：當通過 Dragonfly 下載下傳某層鏡像檔案時，Dragonfly 的SuperNode會把整個檔案拆分成一個個的塊，SuperNode 中的分塊稱為種子塊，種子塊由若幹初始用戶端下載下傳并迅速在所有用戶端之間傳播，其中分塊大小通過動态計算而來。
● SuperNode：Dragonfly 的服務端，它主要負責種子塊的生命周期管理以及構造 P2P 網絡并排程用戶端互傳指定分塊。
● DFget：Dragonfly 的用戶端，安裝在每台主機上，主要負責分塊的上傳與下載下傳以及與容器 Daemon 的指令互動
● Peer：下載下傳同一個檔案的 Host 彼此之間稱為 Peer。
主要下載下傳過程如下：
● 首先由 PouchContainer 發起 Pull 鏡像指令，該指令會被 DFget 代理截獲。
● 然後由 DFget 向 SuperNode 發送排程請求。
● SuperNode 在收到請求後會檢查對應的檔案是否已經被緩存到本地，如果沒有被緩存，則會從 Registry 中下載下傳對應的檔案并生成種子塊資料（種子塊一旦生成就可以立即傳播，而并不需要等到 SuperNode 下載下傳完成整個檔案後才開始分發），如果已經被緩存，則直接生成分塊任務。
● 用戶端解析相應的任務并從其他 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 主要做了以下幾個方面的工作：
● 支援 HTTP Header 傳輸，以滿足那些需要通過 Header 來進行權限驗證的下載下傳請求
● 通過自研的資料存儲協定對資料塊進行包裝傳輸，後續還會對包裝的資料進行再加密
● 即将支援安全加密功能插件化
● 通過多重校驗機制，可以嚴格防止資料被篡改
Dragonfly 目前的成熟度如何在阿裡巴巴集團内部，Dragonfly 作為全集團基礎技術構件，目前已經承載了全集團 90%以上的檔案下載下傳任務，包括鏡像檔案、應用軟體包、算法資料檔案、靜态資源檔案以及索引檔案等等，日分發峰值目前可以達到 1 億次，為集團業務提供了高效穩定的檔案分發能力；同時，每年雙十一大家買買買的過程中，其中最為關鍵的營銷活動資料（數 GB 大小）也是在将近零點的時候通過 Dragonfly 來成功（100%成功）抵達數萬台機器上的，萬一在這個過程中有一點點問題，雙十一會如何，你懂的……
目前 Dragonfly 也已經開源，在開源社群中， 目前 Star 數 2500+，同時有非常多的外部使用者對 Dragonfly 表現出濃厚的興趣，也有很多外部公司正在使用 Dragonfly 來解決他們在鏡像或者檔案分發方面遇到的各種問題，比如中國移動、滴滴、科大訊飛等；此外，Dragonfly 已成為全中國第三個進入CNCF Sandbox 級别的項目，後續我們還會繼續加油努力，争取盡快畢業！
CNCF 總裁宣布 Dragonfly 加入 CNCF
通過以上介紹，我相信針對 Dragonfly 是否足夠成熟，大家心裡應該也有杆秤了吧，當然，Dragonfly 還有很多事情需要不斷完善和改進，在這裡誠邀各路人才，一起把 Dragonfly 打造成一款世界級的産品！
未來展望● 成為CNCF畢業項目，為雲原生應用提供更加豐富和強大的檔案分發能力。
● 開源版與集團内部版融合，給社群開放出更多的進階特性。
● 智能化方面進行更多探索和改進。
原文釋出時間為：2018-11-15
本文作者：胡作政(正希)
本文來自雲栖社群合作夥伴“
阿裡系統軟體技術”，了解相關資訊可以關注“
”。