Dragonfly 成爲 CNCF 孵化項目，咱們與基金會首位華人 TOC 聊了聊

本文轉載自開源中國。

推薦閱讀： 《重磅 | 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」