本文轉載自開源中國。

推薦閱讀：
《重磅 | Dragonfly 晉升成為 CNCF 孵化項目》

4 月 10 日，由雲原生計算基金會（CNCF）技術監督委員會投票決議，來自中國的開源項目 Dragonfly 正式晉升為 CNCF 孵化級別的託管項目，成為繼 Harbor、TiKV 之後，第三個進入 CNCF 孵化階段的中國項目。

CNCF 成立於 2015 年 7 月，是 Linux 基金會旗下的重要開源組織之一，圍繞微服務、DevOps、持續交付、容器化四大特性，致力於維護和集成雲原生相關開源技術，以支持編排容器化微服務架構應用。

目前，CNCF 有會員公司超過 300 家，其中包括 AWS、Azure、Google、阿里雲等全球主流的雲計算廠商。CNCF 的技術監督委員會由 11 位具有豐富技術知識和行業背景的代表組成，為雲原生社區提供技術領導。 

在“雲”已經成為大眾基礎設施的今天，雲原生被認為是雲計算技術的 2.0 標準，而 CNCF 正是引領雲原生技術發展的風向標，在業內具有舉足輕重的地位。那麼 Dragonfly 項目究竟憑何能夠躋身 CNCF 孵化項目？其在雲原生的技術生態中又扮演著怎樣的角色呢？為深入瞭解 Dragonfly 項目的特性，以及雲原生技術在國內的發展現狀，我們邀請到了 CNCF 首位華人技術監督委員會委員（TOC）、阿里雲資深技術專家李響先生，請他分享了 CNCF 與 Dragonfly 的相關情況。

關於 CNCF 與 TOC

CNCF 是如今最有影響力的開源組織之一，作為 CNCF 僅有的 11 名 TOC 之一，我們對於李響平時的工作十分好奇。據李響介紹，CNCF 基金會本質上是以項目為中心進行運作的，目標是為了讓 CNCF 吸納更好的項目，進而通過這些項目吸引更多最終的客戶群體。有了更多的客戶群體使用 CNCF 的項目之後，廠商會把這些開源項目組合成產品或者雲服務，以更低的成本和更高的效率供客戶使用，助推整個雲原生生態形成一個健康發展的產業閉環。

所以，CNCF 是希望通過項目來連接基金會、開發者和廠商。因此，作為 TOC 的核心目標就是收集最好、最適合基金會雲原生理念的項目，而李響個人的主要工作也是尋找最好的項目，就像一名“星探”一樣。

李響還給我們介紹了 CNCF 內部的項目晉升機制。進入 CNCF 的每個項目會被分為沙箱階段（ sandbox）、孵化（incubation） 和畢業（graduation）這三個階段。

沙箱階段都是處於早期發展階段的項目，TOC 們會去尋找一些有潛力的項目，為他們提供建議，促使其進入沙箱階段。CNCF 基金會本身並不像 Linux 基金會已有十幾年發展歷程，它現在仍然還需要定義一些東西，比如沙箱階段的項目到底意味著什麼？進入沙箱階段的流程又是如何？從沙箱階段進入孵化該怎麼做？它的標準是什麼？定義這些也是 TOC 的責任，李響自己也在這方面投入了比較大的精力。

還有，如何分配 CNCF 有限的資源來保證基金會能夠以項目為中心運作，如何能讓 CNCF 既有創新能力，又能在吸納進大量項目的同時保持它的先進性、中立性以及雲原生理念，這些也都是 TOC 需要關心的問題。

Dragonfly 是什麼？

官方資料顯示，Dragonfly 項目主要解決以 Kubernetes 為核心的分佈式應用編排系統的鏡像分發難題。Dragonfly 的架構主要解決了大規模鏡像下載、遠距離傳輸、帶寬成本控制、安全傳輸這四大難題。

1. 大規模鏡像下載

圖注：

• PouchContainer：阿里巴巴集團開源的高效、輕量級企業級富容器引擎技術；
• Registry：容器鏡像的存儲倉庫，每個鏡像由多個鏡像層組成，而每個鏡像層又表現為一個普通文件；
• SuperNode：Dragonfly的服務端，它主要負責種子塊的生命週期管理以及構造 P2P 網絡並調度客戶端互傳指定分塊；
• Block：當通過 Dragonfly下載某層鏡像文件時，SuperNode 會把整個文件拆分成一個個的塊，SuperNode 中的分塊稱為種子塊，種子塊由若干初始客戶端下載並迅速在所有客戶端之間傳播，其中分塊大小通過動態計算而來；
• 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 技術，Dragonfly 可以徹底解決鏡像倉庫的帶寬瓶頸問題，充分利用各個 Peer 的硬件資源和網絡傳輸能力，達到規模越大傳輸越快的效果。值得一提的是，Dragonfly 的系統架構不涉及對容器技術體系的任何改動，完全可以無縫支持容器使其擁有 P2P 鏡像分發能力，以大幅提升文件分發效率。

2. 遠距離傳輸

Dragonfly 通過 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 中的緩存文件，自然而然也就沒有遠距離傳輸的問題了。

3. 降低帶寬成本

通過動態壓縮，可以在不影響 SuperNode 和 Peer 正常運行的情況下，對文件中最值得壓縮的部分實施相應的壓縮策略，從而可以節約大量的網絡帶寬資源，同時還能進一步提升分發速率，相比於傳統的 HTTP 原生壓縮方式，動態壓縮主要有以下幾個方面的優勢：

動態壓縮的優勢首先自然是動態性，它可以保證只有在 SuperNode 和 Peer 負載正常的情況下才會開啟壓縮，同時只會對文件中最值得壓縮的分塊進行壓縮且壓縮策略也是動態確定的；此外，通過多線程壓縮方式可以大幅提升壓縮速率，而且藉助 SuperNode 的緩存能力，整個下載過程只需要壓縮一次即可，壓縮收益比相對於 HTTP 原生方式至少提升 10 倍。

除了動態壓縮外，通過 SuperNode 強大的任務調度能力，可以儘量使在同一個網絡設備下的 Peer 互傳分塊，減少跨網絡設備、跨機房的流量，從而進一步降低網絡帶寬成本。

4. 安全傳輸

在下載某些敏感類文件（比如祕鑰文件或者賬號數據之類的文件）時，傳輸的安全性必須要得到有效保障。在這方面，Dragonfly 主要做了以下幾個方面的工作：

1.支持 HTTP Header 傳輸，以滿足那些需要通過 Header 來進行權限驗證的下載請求；
2.通過自研的數據存儲協議對數據塊進行包裝傳輸，後續還會對包裝的數據進行再加密；
3.即將支持安全加密功能插件化；
4.通過多重校驗機制，可以嚴格防止數據被篡改。

Dragonfly 是如何晉升的？

Dragonfly 能夠進入 CNCF 的孵化階段，說明項目本身確實有能夠讓 TOC 眼前一亮的地方。李響介紹，Dragonfly 主要解決的是大規模場景下的容器鏡像分發的問題，它與傳統的解決方式有很大的不同。

傳統的解決方式是中央式的存儲以及分發，好處是實現比較簡單，管控起來也比較方便，但是這種方式在大規模場景會遇到一些挑戰，主要是由於難以更靈活的水平擴展處理突發的流量。

“舉一個例子，在阿里內部一些場景和阿里雲容器服務客戶場景下，尤其是一些批量計算型的業務，都有可能在一分鐘內有千級別的容器創建的吞吐，對於鏡像分發也會產生相應的吞吐壓力。應對這個高突發性且大規模的流量，最好的辦法就是利用 P2P 的特性來做分佈式的分發。Dragonfly 正是基於這個理念構建的一套系統，幫助用戶和企業應對大規模容器場景，讓容器生態能覆蓋更多、更復雜的場景。Dragonfly 的理念在容器這個特定的領域還是比較領先的，應該是第一個嘗試，也算是比較成功的探索和實踐。” 

談到 Dragonfly 為什麼能夠從沙箱階段晉升至孵化項目，李響向我們介紹了 CNCF 內部的評判標準。CNCF 對孵化項目有一些基礎的要求，比如項目的成熟度、使用普及度、貢獻者的分佈等等，而 Dragonfly 從這些相對客觀的指標看是完全符合孵化要求的。

從另外一方面看，CNCF 也會考慮到項目是否能幫助到雲原生領域的技術和社區發展，是否能幫助到 CNCF 作為基金會自身的發展。這部分內容相對來講比較主觀，因此也是要 TOC 這個 11 人的組織進行投票的。從投票結果看，大部分人認可 Dragonfly 對於雲原生領域和基金會的價值，因此被接受為孵化項目。

在沙箱階段時，Dragonfly 就在一些實際生產環境中展現了它的價值，包括電子商務、電信、金融和互聯網等在內的各個行業場景下的應用。用戶包括阿里巴巴、中國移動、Shopee、Bilibili、螞蟻金服、虎牙、滴滴和 iFLYTEK 等。

比如中國移動浙江分公司在生產環境中採用 Dragonfly 已有 3 年以上的歷史，涉及超過  1000 臺物理計算機，目前在 Dragonfly 上運行 200 多個業務系統和 1700 多個應用程序模塊；新加坡電子商務平臺 Shopee 也在生產環境中採用 Dragonfly 已有 1 年以上的歷史，涉及 10K+ 臺物理機器；國內視頻彈幕網站 Bilibili 已在超過 3900 臺機器的測試和生產環境中採用了 Dragonfly。來自 Bilibili 的工程師在註冊表驗證、穩定性等方面與 Dragonfly 社區合作並做出了積極貢獻。

當然，作為 TOC 的李響，同時也是阿里雲的資深工程師，其在推動 Dragonfly 項目晉升的過程中，也給項目團隊提供了很多技術、生態方面的指導建議，比如和 Harbor 生態的連接、與阿里雲產品的互動以更好地普及 Dragonfly 到終端用戶等。

有什麼意義？

我們瞭解到，李響本身也是 CNCF 另一個孵化階段開源項目 Etcd 的作者，那麼進入孵化階段對於項目維護者們來說意味著什麼呢？ 

“主要意味著有更大的責任去服務好雲原生的用戶和更好的連接相關生態，Dragonfly 後續的工作也會圍繞這兩個目標進行。在開源上要簡化安裝、升級流程，提高易用性、安全性等基礎能力，讓用戶更容易的在企業級場景下開箱即用的使用 Dragonfly 項目。另外，我們也會推動 Dragonfly 與 CNCF 生態的和諧發展，提高集成能力，與 Harbor 、Quay、Clair 等項目更好配合，並且能夠推動 OCI 在 Distribution 相關的標準化建設。”李響說。

而對於 CNCF 組織本身來說，新的項目從沙箱階段晉升至孵化階段，也意味著雲原生生態版圖得到了進一步的完善。李響透露，其實沙箱階段的項目從某種意義上來講並不屬於正式的 CNCF 項目，因此 CNCF 並不會給沙箱階段的項目投入非常多的資源，包括運營、市場、技術指導等。“孵化項目是 CNCF 正式項目的第一個階段，基金會會投入更多資源協助和支持項目的發展，在技術上給予更多的指導和支持，幫助 Dragonfly 能夠順利從基金會畢業，成為雲原生領域中的重要一環。” 

談到 CNCF 項目的最後一個階段（畢業），李響表示，能否畢業的主要考量還是項目的生態整體健康度以及項目成熟的情況，CNCF 希望畢業的項目能夠做到生產可用，並且符合大部分企業的訴求。

雲原生的發展前景

如今，全球雲原生建設正如火如荼地進行中，國內很多一線大廠也都開始積極擁抱雲原生。李響介紹，雲原生技術上主要的發展趨勢主要有以下兩點：

• 標準化：越來越多的雲原生技術湧現，使得對這些技術的統一描述、管理和打通的需求成為剛需；
• 嚮應用層上浮：雲原生起步於基礎設施層，但是正逐步向離用戶更近的應用層邁進，最終實現軟件天然生於雲上長於雲上的願景。目前的主要障礙是基礎設施與應用層之間的鏈接還沒有完全建立起來，這一部分碎片化也非常嚴重，沒有在離用戶更進的層次把雲原生的價值發揮到最佳程度。目前，阿里在積極參與這個工作，幫助 CNCF Landscape 補齊應用定義和應用交付領域，這也是 CNCF SIG App Delivery 目前正在推進的工作。

目前，整個雲原生的生態建設可以說是以容器編排系統 Kubernetes 為核心的，有個說法是：Kubernetes 是雲原生時代的 Linux，同時有另一個更為寬泛的說法：雲原生是開源的一大根基。李響表達了自己對於這兩句話的理解：“ Kubernetes 的成功實際上歸功於其實現了對雲基礎設施（計算、網絡、存儲等）的標準化抽象，這其實跟 Linux 這樣一個標準化操作系統為我們屏蔽掉底層硬件細節的價值是完全一樣的。正是有了這樣的標準化基礎設施抽象，整個雲計算生態才能夠在之上逐層定義更多的應用層能力，高效的實現雲原生連接‘應用’與‘雲’的核心價值。”

採訪的最後，李響還給想要接觸和學習雲原生相關技術的開發者一些建議：目前國外雲原生的發展主要集中在資源基礎設施管理，應用基礎設施（例如服務網格、可觀察性等），以及應用運維與交付技術這三個領域當中。國內的雲原生關注點當前還主要集中在基礎設施管理，但是也正在迅速上浮到跟面向開發者的應用這一層。對於年輕的開發者，CNCF 官方社區、博客等，都是入門雲原生技術一個比較好的渠道。

嘉賓介紹

李響，擁有浙江大學本科和卡耐基梅隆大學碩士學位，是 CoreOS 創始人之一，參與創建了 etcd、operator framework、rkt 等開源項目。而在開源社區中，李響作為 etcd 作者被開發者所熟知。該項目目前吸納超過 400 名貢獻者、14000 個提交，發佈超過 150 個版本，廣受開發者認可。於 2019 年 1 月成為 CNCF 首位華人 TOC 。

在加入阿里雲後，李響主要負責阿里巴巴大規模集群調度與管理系統，幫助阿里巴巴通過雲原生技術初步完成了基礎架構的轉型，實現了資源利用率與軟件的開發和部署效率的大幅提升，並同步支撐了雲產品的技術演進。

課程推薦

為了更多開發者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”