導(dǎo)讀：2017天貓雙11， 交易峰值32.5萬/秒，支付峰值25.6萬/秒，數(shù)據(jù)庫處理峰值4200萬次/秒，成交額1682億數(shù)字的背后是50+神秘技術(shù)！其中，阿里集團(tuán)基礎(chǔ)設(shè)施蜻蜓，在雙11期間，對上萬臺(tái)服務(wù)器同時(shí)下發(fā)5GB的數(shù)據(jù)文件，讓大規(guī)模文件分發(fā)靠蜻蜓系統(tǒng)完美實(shí)現(xiàn)。

蜻蜓，通過解決大規(guī)模文件下載以及跨網(wǎng)絡(luò)隔離等場景下各種難題，大幅提高數(shù)據(jù)預(yù)熱、大規(guī)模容器鏡像分發(fā)等業(yè)務(wù)能力。月均分發(fā)次數(shù)突破20億次，分發(fā)數(shù)據(jù)量3.4PB。其中容器鏡像分發(fā)比natvie方式提速可高達(dá)57倍，registry網(wǎng)絡(luò)出口流量降低99.5%以上。今天，阿里巴巴集團(tuán)基礎(chǔ)架構(gòu)事業(yè)群運(yùn)維中臺(tái)負(fù)責(zé)人，親歷者如柏，將為我們詳述蜻蜓從文件分發(fā)到鏡像傳輸?shù)募夹g(shù)之路。

蜻蜓的誕生 

蜻蜓是阿里自研的P2P文件分發(fā)系統(tǒng)，是阿里基礎(chǔ)運(yùn)維平臺(tái)重要組成部分，是云效-智能運(yùn)維平臺(tái)的核心競爭力，也是阿里云容器服務(wù)的關(guān)鍵組件。

隨著阿里業(yè)務(wù)爆炸式增長，2015年時(shí)發(fā)布系統(tǒng)日均的發(fā)布量突破兩萬，很多應(yīng)用的規(guī)模開始破萬，發(fā)布失敗率開始增高， 而根本原因就是發(fā)布過程需要大量的文件拉取，文件服務(wù)器扛不住大量的請求，當(dāng)然很容易想到服務(wù)器擴(kuò)容，可是擴(kuò)容后又發(fā)現(xiàn)后端存儲(chǔ)成為瓶頸。此外，大量來自不同IDC的客戶端請求消耗了巨大的網(wǎng)絡(luò)帶寬，造成網(wǎng)絡(luò)擁堵。

同時(shí)，很多業(yè)務(wù)走向國際化，大量的應(yīng)用部署在海外，海外服務(wù)器下載要回源國內(nèi)，浪費(fèi)了大量的國際帶寬，而且還很慢；如果傳輸大文件，網(wǎng)絡(luò)環(huán)境差，失敗的話又得重來一遍，效率極低。

于是很自然的就想到了P2P技術(shù)，因?yàn)镻2P技術(shù)并不新鮮，當(dāng)時(shí)也調(diào)研了很多國內(nèi)外的系統(tǒng)，但是調(diào)研的結(jié)論是這些系統(tǒng)的規(guī)模和穩(wěn)定性都無法達(dá)到我們的期望。所以就有了蜻蜓這個(gè)產(chǎn)品。

設(shè)計(jì)目標(biāo)

針對這些痛點(diǎn)，蜻蜓在設(shè)計(jì)之初定了幾個(gè)目標(biāo)：

1. 解決文件源被打爆的問題，在Host之間組P2P網(wǎng)，緩解文件服務(wù)器壓力，節(jié)約跨IDC之間的網(wǎng)絡(luò)帶寬資源。

2. 加速文件分發(fā)速度，并且保證上萬服務(wù)器同時(shí)下載，跟一臺(tái)服務(wù)器下載沒有太大的波動(dòng)。

3. 解決跨國下載加速和帶寬節(jié)約。

4. 解決大文件下載問題，同時(shí)必須要支持?jǐn)帱c(diǎn)續(xù)傳。

5. Host上的磁盤IO，網(wǎng)絡(luò)IO必須可以被控制，以避免對業(yè)務(wù)造成影響。

系統(tǒng)架構(gòu)

蜻蜓整體架構(gòu)

蜻蜓整體架構(gòu)分三層：第一層是Config Service， 他管理所有的Cluster Manager，Cluster Manager又管理所有的Host， Host就是終端，dfget就是類似wget的一個(gè)客戶端程序。

Config Service 主要負(fù)責(zé)Cluster Manager的管理、客戶端節(jié)點(diǎn)路由、系統(tǒng)配置管理以及預(yù)熱服務(wù)等等。簡單的說， 就是負(fù)責(zé)告訴Host，離他最近的一組Cluster Manager的地址列表，并定期維護(hù)和更新這份列表，使Host總能找到離他最近的Cluster Manager。

Cluster Manager 主要的職責(zé)有兩個(gè)：

1. 以被動(dòng)CDN方式從文件源下載文件并生成一組種子分塊數(shù)據(jù)；

2. 構(gòu)造P2P網(wǎng)絡(luò)并調(diào)度每個(gè)peer之間互傳指定的分塊數(shù)據(jù)。

Host上就存放著dfget，dfget的語法跟wget非常類似。主要功能包括文件下載和P2P共享等。

在阿里內(nèi)部我們可以用StarAgent來下發(fā)dfget指令，讓一組機(jī)器同時(shí)下載文件，在某種場景下一組機(jī)器可能就是阿里所有的服務(wù)器，所以使用起來非常高效。除了客戶端外， 蜻蜓還有Java SDK，可以讓你將文件“PUSH”到一組服務(wù)器上。

下面這個(gè)圖闡述了兩個(gè)終端同時(shí)調(diào)用dfget，下載同一個(gè)文件時(shí)系統(tǒng)的交互示意圖：

蜻蜓P2P組網(wǎng)邏輯示意圖

兩個(gè)Host和CM會(huì)組成一個(gè)P2P網(wǎng)絡(luò)，首先CM會(huì)查看本地是否有緩存，如果沒有，就會(huì)回源下載，文件當(dāng)然會(huì)被分片，CM會(huì)多線程下載這些分片，同時(shí)會(huì)將下載的分片提供給Host們下載，Host下載完一個(gè)分片后，同時(shí)會(huì)提供出來給peer下載，如此類推，直到所有的Host全部下載完。

本地下載的時(shí)候會(huì)將下載分片的情況記錄在metadata里，如果突然中斷了下載，再次執(zhí)行dfget命令，會(huì)斷點(diǎn)續(xù)傳。

下載結(jié)束后，還會(huì)比對MD5，以確保下載的文件和源文件是完全一致的。蜻蜓通過HTTP cache協(xié)議來控制CM端對文件的緩存時(shí)長，CM端當(dāng)然也有自己定期清理磁盤的能力，確保有足夠的空間支撐長久的服務(wù)。

在阿里還有很多文件預(yù)熱的場景，需要提前把文件推送到CM端，包括容器鏡像、索引文件、業(yè)務(wù)優(yōu)化的cache文件等等。

在第一版上線后，我們進(jìn)行了一輪測試， 結(jié)果如下圖：

傳統(tǒng)下載和蜻蜓P2P下載測試結(jié)果對比圖

X軸是客戶端數(shù)量， Y軸是下載時(shí)長，

文件源：測試目標(biāo)文件200MB（網(wǎng)卡：千兆bit/s）

Host端：百兆bit/s網(wǎng)卡

CM端：2臺(tái)服務(wù)器（24核 64G，網(wǎng)卡：千兆bit/s)

從這個(gè)圖可以看出兩個(gè)問題：

1. 傳統(tǒng)模式隨著客戶端的增加，下載時(shí)長跟著增加，而dfget可以支撐到7000客戶端依然沒變好。

2. 傳統(tǒng)模式到了1200客戶端以后就沒有數(shù)據(jù)了，因?yàn)閿?shù)據(jù)源被打爆了。

每年雙11之前都是發(fā)布高峰期， 2015年雙11就是靠蜻蜓完美渡過了。

從發(fā)布系統(tǒng)走向基礎(chǔ)設(shè)施

2015年雙11后，蜻蜓的下載次數(shù)就達(dá)到了12萬/月，分發(fā)量4TB。當(dāng)時(shí)在阿里還有別的下載工具，如wget，curl，scp，ftp 等等，也有自建的小規(guī)模文件分發(fā)系統(tǒng)。我們除了全面覆蓋自身發(fā)布系統(tǒng)外，也做了小規(guī)模的推廣。到2016年雙11左右，我們的下載量就達(dá)到了1.4億/月，分發(fā)量708TB，業(yè)務(wù)增長了近千倍。

2016年雙11后我們提出了一個(gè)更高的目標(biāo)， 希望阿里大規(guī)模文件分發(fā)和大文件分發(fā)90%的業(yè)務(wù)由蜻蜓來承擔(dān)。我們希望蜻蜓成為全集團(tuán)的基礎(chǔ)設(shè)施。

我希望通過這個(gè)目標(biāo)錘煉出最好的P2P文件分發(fā)系統(tǒng)。此外也可以統(tǒng)一集團(tuán)內(nèi)所有的文件分發(fā)系統(tǒng)。統(tǒng)一可以讓更多的用戶受益，但統(tǒng)一從來不是終極目標(biāo)， 統(tǒng)一的目的是：1. 減少重復(fù)建設(shè)；2. 全局優(yōu)化。

只要優(yōu)化蜻蜓一個(gè)系統(tǒng)，全集團(tuán)都能受益。比如我們發(fā)現(xiàn)系統(tǒng)文件是每天全網(wǎng)分發(fā)的，而光這一個(gè)文件壓縮的話就能給公司每天節(jié)省9TB網(wǎng)絡(luò)流量�？鐕鴰�寬資源尤其寶貴。而如果大家各用各的分發(fā)系統(tǒng)，類似這樣的全局優(yōu)化就無從談起。

所以統(tǒng)一勢在必行！

在大量數(shù)據(jù)分析基礎(chǔ)上，我們得出全集團(tuán)文件分發(fā)的量大概是3.5億次/周，而我們當(dāng)時(shí)的占比只有10%不到。

經(jīng)過半年努力，在2017年4月份，我們終于實(shí)現(xiàn)了這個(gè)目標(biāo)， 達(dá)到90%+的業(yè)務(wù)占有率，業(yè)務(wù)量增長到3億次/周（跟我們之前分析的數(shù)據(jù)基本吻合），分發(fā)量977TB，這個(gè)數(shù)字比半年前一個(gè)月的量還大。

當(dāng)然，不得不說這跟阿里容器化也是密不可分的，鏡像分發(fā)流量大約占了一半。下面我們就來介紹下蜻蜓是如何支持鏡像分發(fā)的。在說鏡像分發(fā)之前先說下阿里的容器技術(shù)。

阿里的容器技術(shù)

容器技術(shù)的優(yōu)點(diǎn)自然不需要多介紹了，全球來看，容器技術(shù)以Docker為主占了大部分市場，當(dāng)然還有其他解決方案：比如rkt，Mesos Uni Container，LXC等，而阿里的容器技術(shù)命名為Pouch。早在2011年，阿里就自主研發(fā)了基于LXC的容器技術(shù)T4，只是當(dāng)時(shí)我們沒有創(chuàng)造鏡像這個(gè)概念，T4還是當(dāng)做虛擬機(jī)來用，當(dāng)然比虛擬機(jī)要輕量的多。

2016年阿里在T4基礎(chǔ)上做了重大升級(jí)，演變?yōu)榻裉斓腜ouch，并且已經(jīng)開源。目前Pouch容器技術(shù)已經(jīng)覆蓋阿里巴巴集團(tuán)幾乎所有的事業(yè)部，在線業(yè)務(wù)100%容器化，規(guī)模高達(dá)數(shù)十萬。鏡像技術(shù)的價(jià)值擴(kuò)大了容器技術(shù)的應(yīng)用邊界，而在阿里如此龐大的應(yīng)用場景下，如何實(shí)現(xiàn)高效“鏡像分發(fā)”成為一個(gè)重大命題。

回到鏡像層面。宏觀上，阿里巴巴有規(guī)模龐大的容器應(yīng)用場景；微觀上，每個(gè)應(yīng)用鏡像在鏡像化時(shí)，質(zhì)量也存在參差不齊的情況。

理論上講用鏡像或者用傳統(tǒng)“基線”模式，在應(yīng)用大小上不應(yīng)該有非常大的區(qū)別。但事實(shí)上這完全取決于Dockerfile寫的好壞，也取決于鏡像分層是否合理。阿里內(nèi)部其實(shí)有最佳實(shí)踐，但是每個(gè)團(tuán)隊(duì)理解接受程度不同，肯定會(huì)有用的好壞的之分。尤其在一開始，大家打出來的鏡像有3～4GB這都是非常常見的。

所以作為P2P文件分發(fā)系統(tǒng)，蜻蜓就有了用武之地，無論是多大的鏡像，無論是分發(fā)到多少機(jī)器，即使你的鏡像打的非常糟糕，我們都提供非常高效的分發(fā)，都不會(huì)成瓶頸。這樣就給我們快速推廣容器技術(shù)，讓大家接受容器運(yùn)維模式，給予了充分消化的時(shí)間。

容器鏡像

在講鏡像分發(fā)之前先簡單介紹下容器鏡像。我們看下Ubuntu系統(tǒng)的鏡像：我們可以通過命令 docker history ubuntu:14.04 查看 ubuntu:14.04，結(jié)果如下：

需要注意的是：鏡像層 d2a0ecffe6fa 中沒有任何內(nèi)容，也就是所謂的空鏡像。

鏡像是分層的，每層都有自己的ID和尺寸，這里有4個(gè)Layer，最終這個(gè)鏡像是由這些Layer組成。

Docker鏡像是通過Dockerfile來構(gòu)建，看一個(gè)簡單的Dockerfile：

鏡像構(gòu)建過程如下圖所示：

可以看到，新鏡像是從 base 鏡像一層一層疊加生成的。每安裝一個(gè)軟件，就在現(xiàn)有鏡像的基礎(chǔ)上增加一層。

當(dāng)容器啟動(dòng)時(shí)，一個(gè)可寫層會(huì)被加載到鏡像的頂層，這個(gè)可讀可寫層也被稱為“容器層”，容器層之下都是“鏡像層”，都是只讀的。

如果鏡像層內(nèi)容為空，相應(yīng)的信息會(huì)在鏡像json文件中描述，如果鏡像層內(nèi)容不為空，則會(huì)以文件的形式存儲(chǔ)在OSS中。

鏡像分發(fā)

Docker 鏡像下載流程圖

以阿里云容器服務(wù)為例，傳統(tǒng)的鏡像傳輸如上圖所示，當(dāng)然這是最簡化的一種架構(gòu)模式，實(shí)際的部署情況會(huì)復(fù)雜的多，還會(huì)考慮鑒權(quán)、安全、高可用等等。

從上圖可以看出，鏡像傳輸跟文件分發(fā)有類似的問題，當(dāng)有一萬個(gè)Host同時(shí)向Registry請求時(shí)，Registry就會(huì)成為瓶頸，還有海外的Host訪問國內(nèi)Registry時(shí)候也會(huì)存在帶寬浪費(fèi)、延時(shí)變長、成功率下降等問題。

下面介紹下Docker Pull的執(zhí)行過程：

Docker 鏡像分層下載圖

Docker Daemon調(diào)用Registry API得到鏡像的Manifest，從Manifest中能算出每層的URL，Daemon隨后把所有鏡像層從Registry并行下載到Host本地倉庫。

所以最終，鏡像傳輸?shù)膯栴}變成了各鏡像層文件的并行下載的問題。而蜻蜓擅長的正是將每層鏡像文件從Registry用P2P模式傳輸?shù)奖镜貍}庫中。

那么具體又是如何做到的呢？

事實(shí)上我們會(huì)在Host上啟動(dòng)dfGet proxy，Docker/Pouch Engine的所有命令請求都會(huì)通過這個(gè)proxy，我們看下圖：

蜻蜓P2P容器鏡像分發(fā)示意圖

首先，docker pull命令，會(huì)被dfget proxy截獲。然后，由dfget proxy向CM發(fā)送調(diào)度請求，CM在收到請求后會(huì)檢查對應(yīng)的下載文件是否已經(jīng)被緩存到本地，如果沒有被緩存，則會(huì)從Registry中下載對應(yīng)的文件，并生成種子分塊數(shù)據(jù)（種子分塊數(shù)據(jù)一旦生成就可以立即被使用）；如果已經(jīng)被緩存，則直接生成分塊任務(wù)，請求者解析相應(yīng)的分塊任務(wù)，并從其他peer或者supernode中下載分塊數(shù)據(jù)，當(dāng)某個(gè)Layer的所有分塊下載完成后，一個(gè)Layer也就下載完畢了，同樣，當(dāng)所有的Layer下載完成后，整個(gè)鏡像也就下載完成了。

蜻蜓支持容器鏡像分發(fā)，也有幾個(gè)設(shè)計(jì)目標(biāo)：

1. 大規(guī)模并發(fā)：必須能支持十萬級(jí)規(guī)模同時(shí)Pull鏡像。

2. 不侵入容器技術(shù)內(nèi)核（Docker Daemon， Registry）：也就是說不能改動(dòng)容器服務(wù)任何代碼。

3. 支持Docker，Pouch，Rocket ，Hyper等所有容器/虛擬機(jī)技術(shù)。

4. 支持鏡像預(yù)熱：構(gòu)建時(shí)就推送到蜻蜓集群CM。

5. 支持大鏡像文件：至少30GB。

6. 安全。

Native Docker V.S 蜻蜓

我們一共做了兩組實(shí)驗(yàn)：

實(shí)驗(yàn)一：1個(gè)客戶端

1. 測試鏡像大�。�50MB、200MB、500MB、1GB、5GB

2. 鏡像倉庫帶寬：15Gbps

3. 客戶端帶寬：雙百兆bit/s網(wǎng)絡(luò)環(huán)境

4. 測試規(guī)模：單次下載

單客戶端不同模式對比圖

Native和蜻蜓（關(guān)閉智能壓縮特性）平均耗時(shí)基本接近，蜻蜓稍高一點(diǎn)，因?yàn)轵唑言谙螺d過程中會(huì)校驗(yàn)每個(gè)分塊數(shù)據(jù)的MD5值，同時(shí)在下載之后還會(huì)校驗(yàn)整個(gè)文件的MD5，以保證下載的文件跟源文件是一致的；而開啟了智能壓縮的模式下，其耗時(shí)比Native模式還低！

實(shí)驗(yàn)二：多客戶端并發(fā)

1. 測試鏡像大�。�50MB、200MB、500MB、1GB、5GB

2. 鏡像倉庫帶寬：15Gbps

3. 客戶端帶寬：雙百兆bit/s網(wǎng)絡(luò)環(huán)境

4. 多并發(fā)：10并發(fā)、200并發(fā)、1000并發(fā)

不同鏡像大小和并發(fā)數(shù)的對比圖

上圖可以看出，隨著下載規(guī)模的擴(kuò)大，蜻蜓與Native模式耗時(shí)差異顯著擴(kuò)大，最高可提速可以達(dá)20倍。在測試環(huán)境中源的帶寬也至關(guān)重要，如果源的帶寬是2Gbps，提速可達(dá)57倍。

下圖是下載文件的總流量（并發(fā)數(shù) * 文件大�。┖突卦戳髁浚ㄈ�Registry下載的流量）的一個(gè)對比：

蜻蜓鏡像分發(fā)出流量對比圖

向200個(gè)節(jié)點(diǎn)分發(fā)500M的鏡像，比docker原生模式使用更低的網(wǎng)絡(luò)流量，實(shí)驗(yàn)數(shù)據(jù)表明采用蜻蜓后，Registry的出流量降低了99.5%以上；而在1000并發(fā)規(guī)模下，Registry的出流量更可以降低到99.9%左右。

阿里巴巴實(shí)踐效果

蜻蜓在阿里投入使用大概已有兩年，兩年來業(yè)務(wù)發(fā)展迅速，從分發(fā)的次數(shù)來統(tǒng)計(jì)目前一個(gè)月接近20億次，分發(fā)3.4PB數(shù)據(jù)。其中容器鏡像的分發(fā)量接近一半。

蜻蜓在阿里文件vs鏡像分發(fā)流量趨勢圖

在阿里最大的一次分發(fā)應(yīng)該就是今年雙11期間， 要對上萬臺(tái)服務(wù)器同時(shí)下發(fā)5GB的數(shù)據(jù)文件。

走向智能化

阿里在AIOps起步雖然不是最早， 但是我們近年來投入巨大，并在很多產(chǎn)品上有所應(yīng)用。蜻蜓這個(gè)產(chǎn)品中有以下應(yīng)用：

智能流控

流控在道路交通中很常見，比如中國道路限速規(guī)定，沒有中心線的公路，限速為40公里/小時(shí)；同方向只有1條機(jī)動(dòng)車道的公路，限速為70公里/小時(shí)；快速道路80公里；高速公路最高限速為120公里/小時(shí)等等。這種限速對每輛車都一樣，顯然不夠靈活，所以在道路非常空閑的情況下，道路資源其實(shí)是非常浪費(fèi)的，整體效率非常低下。

紅綠燈其實(shí)也是流控的手段，現(xiàn)在的紅綠燈都是固定時(shí)間，不會(huì)根據(jù)現(xiàn)實(shí)的流量來做智能的判斷，所以去年10月召開的云棲大會(huì)上，王堅(jiān)博士曾感慨，世界上最遙遠(yuǎn)的距離不是從南極到北極，而是從紅綠燈到交通攝像頭，它們在同一根桿上，但從來沒有通過數(shù)據(jù)被連接過，攝像頭看到的東西永遠(yuǎn)不會(huì)變成紅綠燈的行動(dòng)。這既浪費(fèi)了城市的數(shù)據(jù)資源，也加大了城市運(yùn)營發(fā)展的成本。

蜻蜓其中一個(gè)參數(shù)就是控制磁盤和網(wǎng)絡(luò)帶寬利用率的，用戶可以通過參數(shù)設(shè)定使用多少網(wǎng)絡(luò)IO/磁盤IO。如上所述，這種方法是非常僵化的。所以目前我們智能化方面的主要思想之一是希望類似的參數(shù)不要再人為來設(shè)定，而是根據(jù)業(yè)務(wù)的情況結(jié)合系統(tǒng)運(yùn)行的情況，智能的決定這些參數(shù)的配置。最開始可能不是最優(yōu)解，但是經(jīng)過一段時(shí)間運(yùn)行和訓(xùn)練后自動(dòng)達(dá)到最優(yōu)化的狀態(tài)，保證業(yè)務(wù)穩(wěn)定運(yùn)行同時(shí)又盡可能的充分利用網(wǎng)絡(luò)和磁盤帶寬，避免資源浪費(fèi)。

 

智能調(diào)度

分塊任務(wù)調(diào)度是決定整個(gè)文件分發(fā)效率高低與否的關(guān)鍵因素，如果只是通過簡單的調(diào)度策略，比如隨機(jī)調(diào)度或者其他固定優(yōu)先級(jí)的調(diào)度，這種做法往往會(huì)引起下載速率的頻繁抖動(dòng)，很容易導(dǎo)致下載毛刺過多，同時(shí)整體下載效率也會(huì)很差。為了最優(yōu)化任務(wù)調(diào)度，我們經(jīng)歷了無數(shù)次的嘗試和探索，最終通過多維度（比如機(jī)器硬件配置、地理位置、網(wǎng)絡(luò)環(huán)境、歷史下載結(jié)果和速率等等維度的數(shù)據(jù)）的數(shù)據(jù)分析（主要利用了梯度下降算法，后續(xù)還會(huì)嘗試其他算法），智能動(dòng)態(tài)決定當(dāng)前請求者最優(yōu)的后續(xù)分塊任務(wù)列表。

 

智能壓縮

智能壓縮會(huì)對文件中最值得壓縮的部分實(shí)施相應(yīng)的壓縮策略，從而可以節(jié)約大量的網(wǎng)絡(luò)帶寬資源。

對容器鏡像目前的實(shí)際平均數(shù)據(jù)來看，壓縮率(Compression Ration) 是40%，也就是說100MB鏡像可以壓縮到40MB。針對1000并發(fā)規(guī)模，通過智能壓縮可以減少60%的流量。

安全

在下載某些敏感的文件（比如秘鑰文件或者賬號(hào)數(shù)據(jù)文件等）時(shí)，傳輸?shù)陌踩�性必須要得到有效的保證，在這方面，蜻蜓主要做了兩個(gè)工作：

1. 支持?jǐn)y帶HTTP的header數(shù)據(jù)，以滿足那些需要通過header來進(jìn)行權(quán)限驗(yàn)證的文件源；

2. 利用對稱加密算法，對文件內(nèi)容進(jìn)行傳輸加密。

開源

隨著容器技術(shù)的流行，容器鏡像這類大文件分發(fā)成為一個(gè)重要問題，為了更好的支持容器技術(shù)的發(fā)展，數(shù)據(jù)中心大規(guī)模文件的分發(fā)，阿里決定開源蜻蜓來更好的推進(jìn)技術(shù)的發(fā)展。阿里將持續(xù)支持開源社區(qū)，并把自己經(jīng)過實(shí)戰(zhàn)檢驗(yàn)的技術(shù)貢獻(xiàn)給社區(qū)。敬請期待。

商業(yè)化

蜻蜓除了用于阿里集團(tuán)內(nèi)部容器化，也完全兼容社區(qū)版Docker，可以和阿里云容器服務(wù)(https://www.aliyun.com/product/containerservice)和飛天專有云敏捷版(https://yq.aliyun.com/articles/224507)無縫結(jié)合在一起，在公共云和專有云環(huán)境下支撐大規(guī)模的容器鏡像分發(fā)。

總結(jié)

蜻蜓通過使用P2P技術(shù)同時(shí)結(jié)合智能壓縮、智能流控等多種創(chuàng)新技術(shù)，解決大規(guī)模文件下載以及跨網(wǎng)絡(luò)隔離等場景下各種文件分發(fā)難題，大幅提高數(shù)據(jù)預(yù)熱、大規(guī)模容器鏡像分發(fā)等業(yè)務(wù)能力。

蜻蜓支持多種容器技術(shù)，對容器本身無需做任何改造，鏡像分發(fā)比natvie方式提速可高達(dá)57倍，Registry網(wǎng)絡(luò)出流量降低99.5%以上。承載著PB級(jí)的流量的蜻蜓，在阿里已然成為重要的基礎(chǔ)設(shè)施之一，為業(yè)務(wù)的極速擴(kuò)張和雙11大促保駕護(hù)航。

Reference

[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]阿里云容器服務(wù)：

https://www.aliyun.com/product/containerservice

[7]飛天專有云敏捷版：

https://yq.aliyun.com/articles/224507

[8]云效智能運(yùn)維平臺(tái)：

https://www.aliyun.com/product/yunxiao

 

標(biāo)簽： idc 安全 代碼 服務(wù)器 海外服務(wù)器 權(quán)限 數(shù)據(jù)分析 數(shù)據(jù)庫 推廣 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。