Dragonfly 成為第三個 CNCF 孵化國產開源專案，我們跟基金會首位華人 TOC 李響聊了聊

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 的架構主要解決了大規模映象下載、遠距離傳輸、頻寬成本控制、安全傳輸這四大難題。

大規模映象下載

圖注：
 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 映象分發能力，以大幅提升檔案分發效率。

遠距離傳輸

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 中的快取檔案，自然而然也就沒有遠距離傳輸的問題了。

降低頻寬成本

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

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

除了動態壓縮外，透過 SuperNode 強大的任務排程能力，可以儘量使在同一個網路裝置下的 Peer 互傳分塊，減少跨網路裝置、跨機房的流量，從而進一步降低網路頻寬成本。

安全傳輸

在下載某些敏感類檔案（比如祕鑰檔案或者賬號資料之類的檔案）時，傳輸的安全性必須要得到有效保障。在這方面，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 希望畢業的專案能夠做到生產可用，並且符合大部分企業的訴求。 

雲原生的發展前景

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

1. 標準化：越來越多的雲原生技術湧現，使得對這些技術的統一描述、管理和打通的需求成為剛需 。
2. 嚮應用層上浮：雲原生起步於基礎設施層，但是正逐步向離使用者更近的應用層邁進，最終實現軟體天然生於雲上長於雲上的願景。目前的主要障礙是基礎設施與應用層之間的連結還沒有完全建立起來，這一部分碎片化也非常嚴重，沒有在離使用者更進的層次把雲原生的價值發揮到最佳程度。目前，阿里在積極參與這個工作，幫助 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 。

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