蜻蜓，通過解決大規模檔案下載下傳以及跨網絡隔離等場景下各種難題，大幅提高資料預熱、大規模容器鏡像分發等業務能力。月均分發次數突破20億次，分發資料量3.4PB。其中容器鏡像分發比natvie方式提速可高達57倍，registry網絡出口流量降低99.5%以上。今天，阿裡妹邀請阿裡基礎架構事業群進階技術專家如柏，為我們詳述蜻蜓從檔案分發到鏡像傳輸的技術之路。
<b>蜻蜓的誕生</b>
随着阿裡業務爆炸式增長，2015年時釋出系統日均的釋出量突破兩萬，很多應用的規模開始破萬，釋出失敗率開始增高，而根本原因就是釋出過程需要大量的檔案拉取，檔案伺服器扛不住大量的請求，當然很容易想到伺服器擴容，可是擴容後又發現後端存儲成為瓶頸。此外，大量來自不同IDC的用戶端請求消耗了巨大的網絡帶寬，造成網絡擁堵。
同時，很多業務走向國際化，大量的應用部署在海外，海外伺服器下載下傳要回源國内，浪費了大量的國際帶寬，而且還很慢；如果傳輸大檔案，網絡環境差，失敗的話又得重來一遍，效率極低。
于是很自然的就想到了P2P技術，因為P2P技術并不新鮮，當時也調研了很多國内外的系統，但是調研的結論是這些系統的規模和穩定性都無法達到我們的期望。是以就有了蜻蜓這個産品。
<b>設計目标</b>
針對這些痛點，蜻蜓在設計之初定了幾個目标：
解決檔案源被打爆的問題，在Host之間組P2P網，緩解檔案伺服器壓力，節約跨IDC之間的網絡帶寬資源。
加速檔案分發速度，并且保證上萬伺服器同時下載下傳，跟一台伺服器下載下傳沒有太大的波動。
解決跨國下載下傳加速和帶寬節約。
解決大檔案下載下傳問題，同時必須要支援斷點續傳。
Host上的磁盤IO，網絡IO必須可以被控制，以避免對業務造成影響。
<b>系統架構</b>
蜻蜓整體架構
蜻蜓整體架構分三層：第一層是Config Service， 他管理所有的Cluster Manager，Cluster Manager又管理所有的Host， Host就是終端，dfget就是類似wget的一個用戶端程式。
Config Service 主要負責Cluster Manager的管理、用戶端節點路由、系統配置管理以及預熱服務等等。簡單的說， 就是負責告訴Host，離他最近的一組Cluster Manager的位址清單，并定期維護和更新這份清單，使Host總能找到離他最近的Cluster Manager。
Cluster Manager 主要的職責有兩個：
以被動CDN方式從檔案源下載下傳檔案并生成一組種子分塊資料；
構造P2P網絡并排程每個peer之間互傳指定的分塊資料。
Host上就存放着dfget，dfget的文法跟wget非常類似。主要功能包括檔案下載下傳和P2P共享等。
在阿裡内部我們可以用StarAgent來下發dfget指令，讓一組機器同時下載下傳檔案，在某種場景下一組機器可能就是阿裡所有的伺服器，是以使用起來非常高效。除了用戶端外， 蜻蜓還有Java SDK，可以讓你将檔案“PUSH”到一組伺服器上。
下面這個圖闡述了兩個終端同時調用dfget，下載下傳同一個檔案時系統的互動示意圖：
蜻蜓P2P組網邏輯示意圖
兩個Host和CM會組成一個P2P網絡，首先CM會檢視本地是否有緩存，如果沒有，就會回源下載下傳，檔案當然會被分片，CM會多線程下載下傳這些分片，同時會将下載下傳的分片提供給Host們下載下傳，Host下載下傳完一個分片後，同時會提供出來給peer下載下傳，如此類推，直到所有的Host全部下載下傳完。
本地下載下傳的時候會将下載下傳分片的情況記錄在metadata裡，如果突然中斷了下載下傳，再次執行dfget指令，會斷點續傳。
下載下傳結束後，還會比對MD5，以確定下載下傳的檔案和源檔案是完全一緻的。蜻蜓通過HTTP cache協定來控制CM端對檔案的緩存時長，CM端當然也有自己定期清理磁盤的能力，確定有足夠的空間支撐長久的服務。
在阿裡還有很多檔案預熱的場景，需要提前把檔案推送到CM端，包括容器鏡像、索引檔案、業務優化的cache檔案等等。
在第一版上線後，我們進行了一輪測試， 結果如下圖：
傳統下載下傳和蜻蜓P2P下載下傳測試結果對比圖
X軸是用戶端數量， Y軸是下載下傳時長，
檔案源：測試目标檔案200MB（網卡：千兆bit/s）
Host端：百兆bit/s網卡
CM端：2台伺服器（24核 64G，網卡：千兆bit/s)
從這個圖可以看出兩個問題：
傳統模式随着用戶端的增加，下載下傳時長跟着增加，而dfget可以支撐到7000用戶端依然沒變好。
傳統模式到了1200用戶端以後就沒有資料了，因為資料源被打爆了。
<b>從釋出系統走向基礎設施 </b>
2015年雙11後，蜻蜓的下載下傳次數就達到了12萬/月，分發量4TB。當時在阿裡還有别的下載下傳工具，如wget，curl，scp，ftp 等等，也有自建的小規模檔案分發系統。我們除了全面覆寫自身釋出系統外，也做了小規模的推廣。到2016年雙11左右，我們的下載下傳量就達到了1.4億/月，分發量708TB，業務增長了近千倍。
2016年雙11後我們提出了一個更高的目标， 希望阿裡大規模檔案分發和大檔案分發90%的業務由蜻蜓來承擔。
我希望通過這個目标錘煉出最好的P2P檔案分發系統。此外也可以統一集團内所有的檔案分發系統。統一可以讓更多的使用者受益，但統一從來不是終極目标， 統一的目的是：1. 減少重複建設；2. 全局優化。
隻要優化蜻蜓一個系統，全集團都能受益。比如我們發現系統檔案是每天全網分發的，而光這一個檔案壓縮的話就能給公司每天節省9TB網絡流量。跨國帶寬資源尤其寶貴。而如果大家各用各的分發系統，類似這樣的全局優化就無從談起。
是以統一勢在必行！
在大量資料分析基礎上，我們得出全集團檔案分發的量大概是3.5億次/周，而我們當時的占比隻有10%不到。
經過半年努力，在2017年4月份，我們終于實作了這個目标， 達到90%+的業務占有率，業務量增長到3億次/周（跟我們之前分析的資料基本吻合），分發量977TB，這個數字比半年前一個月的量還大。
當然，不得不說這跟阿裡容器化也是密不可分的，鏡像分發流量大約占了一半。下面我們就來介紹下蜻蜓是如何支援鏡像分發的。在說鏡像分發之前先說下阿裡的容器技術。
<b>阿裡的容器技術</b>
容器技術的優點自然不需要多介紹了，全球來看，容器技術以Docker為主占了大部分市場，當然還有其他解決方案：比如rkt，Mesos Uni Container，LXC等，而阿裡的容器技術命名為Pouch。早在2011年，阿裡就自主研發了基于LXC的容器技術T4，隻是當時我們沒有創造鏡像這個概念，T4還是當做虛拟機來用，當然比虛拟機要輕量的多。
2016年阿裡在T4基礎上做了重大更新，演變為今天的Pouch，并且已經開源。目前Pouch容器技術已經覆寫阿裡巴巴集團幾乎所有的事業部，線上業務100%容器化，規模高達數十萬。鏡像技術的價值擴大了容器技術的應用邊界，而在阿裡如此龐大的應用場景下，如何實作高效“鏡像分發”成為一個重大命題。
回到鏡像層面。宏觀上，阿裡巴巴有規模龐大的容器應用場景；微觀上，每個應用鏡像在鏡像化時，品質也存在參差不齊的情況。
理論上講用鏡像或者用傳統“基線”模式，在應用大小上不應該有非常大的差別。但事實上這完全取決于Dockerfile寫的好壞，也取決于鏡像分層是否合理。阿裡内部其實有最佳實踐，但是每個團隊了解接受程度不同，肯定會有用的好壞的之分。尤其在一開始，大家打出來的鏡像有3～4GB這都是非常常見的。
是以作為P2P檔案分發系統，蜻蜓就有了用武之地，無論是多大的鏡像，無論是分發到多少機器，即使你的鏡像打的非常糟糕，我們都提供非常高效的分發，都不會成瓶頸。這樣就給我們快速推廣容器技術，讓大家接受容器運維模式，給予了充分消化的時間。
<b>容器鏡像</b>
在講鏡像分發之前先簡單介紹下容器鏡像。我們看下Ubuntu系統的鏡像：我們可以通過指令 docker history ubuntu:14.04 檢視 ubuntu:14.04，結果如下：
需要注意的是：鏡像層 d2a0ecffe6fa 中沒有任何内容，也就是所謂的空鏡像。
鏡像是分層的，每層都有自己的ID和尺寸，這裡有4個Layer，最終這個鏡像是由這些Layer組成。
Docker鏡像是通過Dockerfile來建構，看一個簡單的Dockerfile：
鏡像建構過程如下圖所示：
可以看到，新鏡像是從 base 鏡像一層一層疊加生成的。每安裝一個軟體，就在現有鏡像的基礎上增加一層。
當容器啟動時，一個可寫層會被加載到鏡像的頂層，這個可讀可寫層也被稱為“容器層”，容器層之下都是“鏡像層”，都是隻讀的。
如果鏡像層内容為空，相應的資訊會在鏡像json檔案中描述，如果鏡像層内容不為空，則會以檔案的形式存儲在OSS中。
<b>鏡像分發</b>
Docker 鏡像下載下傳流程圖
以阿裡雲容器服務為例，傳統的鏡像傳輸如上圖所示，當然這是最簡化的一種架構模式，實際的部署情況會複雜的多，還會考慮鑒權、安全、高可用等等。
從上圖可以看出，鏡像傳輸跟檔案分發有類似的問題，當有一萬個Host同時向Registry請求時，Registry就會成為瓶頸，還有海外的Host通路國内Registry時候也會存在帶寬浪費、延時變長、成功率下降等問題。
下面介紹下Docker Pull的執行過程：
Docker 鏡像分層下載下傳圖
Docker Daemon調用Registry API得到鏡像的Manifest，從Manifest中能算出每層的URL，Daemon随後把所有鏡像層從Registry并行下載下傳到Host本地倉庫。
是以最終，鏡像傳輸的問題變成了各鏡像層檔案的并行下載下傳的問題。而蜻蜓擅長的正是将每層鏡像檔案從Registry用P2P模式傳輸到本地倉庫中。
那麼具體又是如何做到的呢？
事實上我們會在Host上啟動dfGet proxy，Docker/Pouch Engine的所有指令請求都會通過這個proxy，我們看下圖：
蜻蜓P2P容器鏡像分發示意圖
首先，docker pull指令，會被dfget proxy截獲。然後，由dfget proxy向CM發送排程請求，CM在收到請求後會檢查對應的下載下傳檔案是否已經被緩存到本地，如果沒有被緩存，則會從Registry中下載下傳對應的檔案，并生成種子分塊資料（種子分塊資料一旦生成就可以立即被使用）；如果已經被緩存，則直接生成分塊任務，請求者解析相應的分塊任務，并從其他peer或者supernode中下載下傳分塊資料，當某個Layer的所有分塊下載下傳完成後，一個Layer也就下載下傳完畢了，同樣，當所有的Layer下載下傳完成後，整個鏡像也就下載下傳完成了。
蜻蜓支援容器鏡像分發，也有幾個設計目标：
大規模并發：必須能支援十萬級規模同時Pull鏡像。
不侵入容器技術核心（Docker Daemon， Registry）：也就是說不能改動容器服務任何代碼。
支援Docker，Pouch，Rocket ，Hyper等所有容器/虛拟機技術。
支援鏡像預熱：建構時就推送到蜻蜓叢集CM。
支援大鏡像檔案：至少30GB。
安全
<b>Native Docker V.S 蜻蜓</b>
我們一共做了兩組實驗：
實驗一：1個用戶端
測試鏡像大小：50MB、200MB、500MB、1GB、5GB
鏡像倉庫帶寬：15Gbps
用戶端帶寬：雙百兆bit/s網絡環境
測試規模：單次下載下傳
單用戶端不同模式對比圖
Native和蜻蜓（關閉智能壓縮特性）平均耗時基本接近，蜻蜓稍高一點，因為蜻蜓在下載下傳過程中會校驗每個分塊資料的MD5值，同時在下載下傳之後還會校驗整個檔案的MD5，以保證下載下傳的檔案跟源檔案是一緻的；而開啟了智能壓縮的模式下，其耗時比Native模式還低！
實驗二：多用戶端并發
測試鏡像大小：50MB、200MB、500MB、1GB、5GB
多并發：10并發、200并發、1000并發
不同鏡像大小和并發數的對比圖
上圖可以看出，随着下載下傳規模的擴大，蜻蜓與Native模式耗時差異顯著擴大，最高可提速可以達20倍。在測試環境中源的帶寬也至關重要，如果源的帶寬是2Gbps，提速可達57倍。
下圖是下載下傳檔案的總流量（并發數 * 檔案大小）和回源流量（去Registry下載下傳的流量）的一個對比：
蜻蜓鏡像分發出流量對比圖
向200個節點分發500M的鏡像，比docker原生模式使用更低的網絡流量，實驗資料表明采用蜻蜓後，Registry的出流量降低了99.5%以上；而在1000并發規模下，Registry的出流量更可以降低到99.9%左右。
<b> 阿裡巴巴實踐效果</b>
蜻蜓在阿裡投入使用大概已有兩年，兩年來業務發展迅速，從分發的次數來統計目前一個月接近20億次，分發3.4PB資料。其中容器鏡像的分發量接近一半。
蜻蜓在阿裡檔案vs鏡像分發流量趨勢圖
在阿裡最大的一次分發應該就是今年雙11期間， 要對上萬台伺服器同時下發5GB的資料檔案。
<b>走向智能化</b>
阿裡在AIOps起步雖然不是最早， 但是我們近年來投入巨大，并在很多産品上有所應用。蜻蜓這個産品中有以下應用：
智能流控
流控在道路交通中很常見，比如中國道路限速規定，沒有中心線的公路，限速為40公裡/小時；同方向隻有1條機動車道的公路，限速為70公裡/小時；快速道路80公裡；高速公路最高限速為120公裡/小時等等。這種限速對每輛車都一樣，顯然不夠靈活，是以在道路非常空閑的情況下，道路資源其實是非常浪費的，整體效率非常低下。
紅綠燈其實也是流控的手段，現在的紅綠燈都是固定時間，不會根據現實的流量來做智能的判斷，是以去年10月召開的雲栖大會上，王堅博士曾感慨，世界上最遙遠的距離不是從南極到北極，而是從紅綠燈到交通攝像頭，它們在同一根杆上，但從來沒有通過資料被連接配接過，攝像頭看到的東西永遠不會變成紅綠燈的行動。這既浪費了城市的資料資源，也加大了城市營運發展的成本。
蜻蜓其中一個參數就是控制磁盤和網絡帶寬使用率的，使用者可以通過參數設定使用多少網絡IO/磁盤IO。如上所述，這種方法是非常僵化的。是以目前我們智能化方面的主要思想之一是希望類似的參數不要再人為來設定，而是根據業務的情況結合系統運作的情況，智能的決定這些參數的配置。最開始可能不是最優解，但是經過一段時間運作和訓練後自動達到最優化的狀态，保證業務穩定運作同時又盡可能的充分利用網絡和磁盤帶寬，避免資源浪費。
智能排程
分塊任務排程是決定整個檔案分發效率高低與否的關鍵因素，如果隻是通過簡單的排程政策，比如随機排程或者其他固定優先級的排程，這種做法往往會引起下載下傳速率的頻繁抖動，很容易導緻下載下傳毛刺過多，同時整體下載下傳效率也會很差。為了最優化任務排程，我們經曆了無數次的嘗試和探索，最終通過多元度（比如機器硬體配置、地理位置、網絡環境、曆史下載下傳結果和速率等等次元的資料）的資料分析（主要利用了梯度下降算法，後續還會嘗試其他算法），智能動态決定目前請求者最優的後續分塊任務清單。
智能壓縮
智能壓縮會對檔案中最值得壓縮的部分實施相應的壓縮政策，進而可以節約大量的網絡帶寬資源。
對容器鏡像目前的實際平均資料來看，壓縮率(Compression Ration) 是40%，也就是說100MB鏡像可以壓縮到40MB。針對1000并發規模，通過智能壓縮可以減少60%的流量。
在下載下傳某些敏感的檔案（比如秘鑰檔案或者賬号資料檔案等）時，傳輸的安全性必須要得到有效的保證，在這方面，蜻蜓主要做了兩個工作：
支援攜帶HTTP的header資料，以滿足那些需要通過header來進行權限驗證的檔案源；
利用對稱加密算法，對檔案内容進行傳輸加密。
開源
随着容器技術的流行，容器鏡像這類大檔案分發成為一個重要問題，為了更好的支援容器技術的發展，資料中心大規模檔案的分發，阿裡決定開源蜻蜓來更好的推進技術的發展。阿裡将持續支援開源社群，并把自己經過實戰檢驗的技術貢獻給社群。敬請期待。
<b>總結</b>
蜻蜓通過使用P2P技術同時結合智能壓縮、智能流控等多種創新技術，解決大規模檔案下載下傳以及跨網絡隔離等場景下各種檔案分發難題，大幅提高資料預熱、大規模容器鏡像分發等業務能力。
蜻蜓支援多種容器技術，對容器本身無需做任何改造，鏡像分發比natvie方式提速可高達57倍，Registry網絡出流量降低99.5%以上。承載着PB級的流量的蜻蜓，在阿裡已然成為重要的基礎設施之一，為業務的極速擴張和雙11大促保駕護航。
PS：雲效2.0 智能運維平台 - 緻力于打造具備世界級影響力的智能運維平台，誠聘資深技術/産品專家，工作地點：杭州、北京、美國，有意者可以點選文末“閱讀原文”了解詳情。
<b>Reference</b>
[1]Docker Overview：
https://docs.docker.com/engine/docker-overview/
[2]Where are docker images stored：
http://blog.thoward37.me/articles/where-are-docker-images-stored/
[3]Image Spec：
https://github.com/moby/moby/blob/master/image/spec/v1.md
[4]Pouch開源位址：
https://github.com/alibaba/pouch
[5]蜻蜓開源位址：
https://github.com/alibaba/dragonfly
[6]阿裡雲容器服務：
https://www.aliyun.com/product/containerservice
[7]飛天專有雲靈活版：
https://yq.aliyun.com/articles/224507
[8]雲效智能運維平台：
https://www.aliyun.com/product/yunxiao
原文釋出時間為：2017-11-14
本文作者：如柏