Dragonfly 項目究竟憑何能夠跻身 CNCF 孵化項目？其在雲原生的技術生态中又扮演着怎樣的角色呢？為深入了解 Dragonfly 項目的特性，以及雲原生技術在國内的發展現狀，我們邀請到了 CNCF 首位華人技術監督委員會委員（TOC）、阿裡雲資深技術專家李響先生，請他分享了 CNCF 與 Dragonfly 的相關情況。
本文轉載自開源中國。
推薦閱讀：
《重磅 | 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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”