隨著集群規模的擴大，您是否曾經因鏡像分發問題而困擾過？根據不同的場景，我們利用不同的鏡像分發方法：

• 基于 P2P 的 CNCF/ Dragonfly (以下稱為“蜻蜓”）分發是緩解鏡像中心帶寬和減少分發時間的最直接方式。
  

• CNCF/containerd 中的遠程文件系統快照程序直接遠程存儲鏡像，使容器引擎通過網絡讀取鏡像內容，幾乎不需要時間分發。
  

你會發現第二種方式依賴于網絡穩定性。本文將總結如何根據鏡像內容讀請求動態加載從遠程到本地存儲的鏡像作為權衡，以及如何選擇適合鏡像分布的方式。

背景介紹

在業務很小的時候，可以單臺機器部署單個容器；但當業務量大了，并且分為多個應用時，就需要將多個應用部署在同一臺機器上；此時多個應用的依賴是一個比較難解決的問題。且多個應用同時運行，相互之間也有所干擾。


一開始，可以使用虛擬機的方式來實現，這樣每個應用一個虛擬機，基本不存在依賴沖突，但是虛擬機還是會有啟動慢，空間占用大等一系列問題。


后面隨著技術的發展，有了 lxc 技術，它能讓應用跑在一個單獨的命名空間上，實現了應用的運行態隔離。


這里可以看到，虛擬機解決了靜態隔離的問題，lcx 解決了運行態隔離的問題，而 Docker 則同時解決了運行態和靜態隔離兩個問題，因此得到親睞。

Docker 核心

Docker 的三大核心：鏡像、容器、倉庫。容器在 Docker 之前已經有了不同的實現，比如 lxc。鏡像和倉庫是 Docker 的很大創新。鏡像是一個實體，倉庫是它的集中存儲中心，而容器則是鏡像的運行時。


Docker 通過鏡像，可以很神奇地實現比如：開發的同學在自己喜歡的平臺上面做開發測試（例如 ubuntu），而真正部署的節點，可能是 redhat/centos 的服務器。





Docker 是以鏡像為基礎，所以容器運行時必須要有鏡像，而容器又可以通過 docker commit 生成一個鏡像。但是第一個鏡像從哪里來呢？可以通過 docker import/load 的方式導入。并且可以通過 docker push/pull 的方向將鏡像上傳到鏡像中心，或從鏡像中心下載鏡像。




鏡像制作


Docker 提供了一套 docker build 機制，方便來制作鏡像。想像一下，沒有 docker build 機制，制作鏡像的步驟如下：

• 從一個基礎鏡像啟動一個容器；
  
• 在容器中執行對應的命令，比如安裝一個軟件包，添加一個文件等；
  
• 使用 docker commit 命令，把剛才的容器 commit 成一個鏡像；
  
• 如果還有其它步驟要做，就要從新鏡像中啟動一個容器，然后再 commit，直到完成所有操作。
  

有了 docker build 機制，只需要一個 dockerfile，然后 Docker 就會把上述步驟自動化了，最后生成一個目標鏡像。




詳細看一下是如何使用鏡像的，鏡像是一層一層的，設計上，鏡像所有層是只讀的，linux 通過 aufs/overlayfs 的方式將一個鏡像 mount 到主機上后，從上往下看，最上面層是容器的可讀寫層，容器運行時的所有寫操作都寫到這一層上面，而下面的層都是鏡像的只讀層。

大規模集群鏡像下載慢

在 Docker 的 registry 或其它網站上看到，像 busybox， nginx， mysql 等鏡像都不大，也就是幾十 M 到幾百 M 的樣子。


但是阿里巴巴的鏡像普遍有 3~4G，鏡像這么大原因有許多，比如：

• 集團使用了富容器的模式，這是一種類似虛擬機的方式，對開發較為友好，開發可以在以前的經驗上做開發，不需要太多的學習成本，這就導致集團的基礎鏡像有 2~3G；
  
• 集團的業務都采用分布式的方式開發，依賴許多中間件，而中間件因版本的原因，沒有完全統一起來，每個中間件都有幾百 M；再加上本身 java 業務包也不小，所以普遍 3~4G 是很正常的;
  
• 集團有上十萬的物理機，上面運行著上百萬的容器，每天有著上千次發布。可以想像一下，就單單把鏡像從鏡像中心下載到物理機上面，每天消耗的帶寬是巨大的。
  

這就導致一個問題：鏡像中心很有可能被打爆。


這種情況在集團出現多次，在打爆的情況下，當前的鏡像拉取被阻塞，同時又有更多的鏡像拉取請求上來，導致鏡像中心嚴重超負荷運行，并且致使問題越來越嚴重，可能會導致整個系統奔潰。因此，必須解決鏡像下載導致的問題。

蜻蜓架構

集團開發了蜻蜓（Dragonfly ）這套 P2P 下載系統。上面是蜻蜓的架構圖，蜻蜓可以分為三層，最上層是一個配置中心，中間是超級節點，下面就是運行容器的物理節點。


配置中心管理整個蜻蜓集群，當物理節點上有鏡像要下載時，它通過 dfget 命令向超級節點發出請求，而向哪些超級節點發出請求是由配置中心配置的。


以下圖為例：





當下載一個文件時，物理節點發送了一個 dfget 請求到超級節點，超級節點會檢查自身是否有這部分數據，如果有，則直接把數據傳送給物理節點；否則會向鏡像中心發出下載請求，這個下載請求是分塊的，這樣，只有下載失敗的塊需要重新下載，而下載成功的塊，則不需要。


更為重要的是，如果是兩個或更多物理節點請求同一份數據，那么蜻蜓收到請求后，只會往鏡像中心發一個請求，極大地降低了鏡像中心的壓力。


關于 P2P，也就是說如果一個節點有了另一個節點的數據，為了減少超級節點的壓力，兩個節點可以完成數據的互傳。這樣更高效地利用了網絡帶寬。

蜻蜓效果

從上面的蜻蜓效果圖可以看到：


隨著鏡像拉取的并發量越來越大，傳統方式所消耗的時間會越來越多，后面的線條越來越陡；但是蜻蜓模式下，雖然耗時有增加，但只是輕微增加。效果還是非常明顯的。

蜻蜓里程碑

應該說，集團內是先有蜻蜓，后面才有 docker 的。原因是集團在全面 docker 之前，使用了 t4 等技術，不管哪種技術，都需要在物理機上面下載應用的包，然后把應用跑起來。


所以，從里程碑上看，2015 年 6 月就已經有了蜻蜓 p2p 了，隨著集團全面 Docker 化，在 2015 年 9 月，蜻蜓提供了對 Docker 鏡像的支持，后面的幾個時間點上，可以看到蜻蜓經受了幾次雙 11 的考驗，并且經過軟件迭代，在 2017 年 11 月的時候實現了開源。


現在蜻蜓還在不斷演化，比如說全部使用 golang 重寫，解決 bug，提供更多能力集，相信蜻蜓的明天更美好。

蜻蜓也不能完美解決的問題——鏡像下載

蜻蜓在集團取得了極好的效果，但是并不能解決所有問題，比如我們就遇到了以下比較突出的問題：

• 鏡像下載導致業務抖動

在實踐中，上線的業務運行經常有抖動的現象，分析其中原因，有部分業務抖動時，都在做鏡像下載。


分析原因發現：鏡像層采用的是 gzip 壓縮算法。這一古老的算法，是單線程運行，并且獨占一個 CPU，更要命的是解壓速度也很慢，如果幾個鏡像層同時展開的話，就要占用幾個 CPU，這搶占了業務的 CPU 資源，導致了業務的抖動。

• 應用擴容要更好的時效性

平時應用發布、升級時，只需要選擇在業務低峰，并且通過一定的算法，比如只讓 10% 左右的容器做發布、升級操作，其它 90% 的容器還給用戶提供服務。這種不影響業務、不影響用戶體驗的操作，對于時效性要求不高，只要在業務高峰來臨前完成操作即可，所以耗時一兩個小時也無所謂。


假設遇到大促場景，原計劃 10 個容器可以服務 100 萬用戶，但是，突然來了 300 萬用戶，這時所有用戶的體驗將會下降，這時就需要通過擴容手段來增加服務器數量，此時對容器擴出來有著極高的時效要求。

• 如何而對云環境

現在所有公司都在上云，集團也在上云階段，但云上服務器的一些特性與物理機還是有些差別，對鏡像來講感受最深的就是磁盤 IO 了，原來物理機的 SSD 磁盤，IO 可以達到 1G 以上，而使用 ECS 后，標準速度是 140M，速度只有原來的十分之一。



Gzip 優化


對于 gzip 的問題，通過實測及數據分析，如上圖所示：


1 與 2 下載的是同一個鏡像層，只是 1 下載的是一個 gzip 格式的，而 2 下載的是一個沒有壓縮的鏡像層。可以看到 2 因為下載的數據量要大很多，所以下載的時間要長許多，但是 1 中將 400M 的 gzip 還原成 1G 的原始數據卻又消耗了太多時間，所以最終兩者總體時效是差不多的。


并且由于去掉 gzip，鏡像下載不會搶占業務的 CPU 資源。自從上了這一方案后，業務抖動的次數明顯減少了許多。


在蜻蜓的章節，鏡像下載是鏡像層從超級節點到物理機，在這一過程中，蜻蜓有一個動態壓縮能力，比如使用更好的 lz4 算法，即達到了數據壓縮的效果，又不會造成業務抖動。這就是圖 3，整體上這一點在集團的應用效果很不錯。

遠程盤架構

解決了鏡像下載對業務的干擾后，擴容、云環境的問題還沒有解決。這時遠程盤就派上用場了。


從上面的架構圖看，集團有一套鏡像轉換機制，將原始的鏡像層放在遠端服務器上，第一個層都有一個唯一的遠程盤與之對應。然后鏡像中保存的是這個遠程盤的 id，這樣做下來，遠程盤的鏡像可以做到 kB 級別。對于 kB 級別的鏡像，下載耗時在 1~2 秒之間。


通過遠程盤，解決了鏡像下載的問題，同時由于遠程盤放在物理機同一個機房，容器運行時讀取鏡像數據，相當于從遠程盤上面讀取數據，因為在同一個機房，當然不能跟本地盤比，但是效果可以與云環境的云盤性能相媲美。

遠程盤的問題

遠程盤雖然解決了鏡像下載的問題，但是所有鏡像的數據都是從遠程盤上讀取，消耗比較大的網絡帶寬。當物理機上環境比較復雜時，遠程盤的數據又不能緩存在內存時，所有數據都要從遠端讀取，當規模上來后，就會給網絡帶來不小的壓力。


另外一個問題是，如果遠程盤出現問題，導致 IO hang，對于容器進程來講，就是僵尸進程，而僵尸進程是無法殺死的。對于應用來講，一個容器要么是死，要么是活，都好辦，死的了容器上面的流量分給活著的容器即可，但對于一個僵尸容器，流量沒法摘除，導致這部分業務就受損了。


最后，遠程盤因為要服務多臺物理機，必然要在磁盤 IO 上面有比較好的性能，這就導致了成本較高。

DADI

針對上述問題，集團采用的 DADI 這一項技術，都是對癥下藥：

• 使用 P2P 技術

遠程盤是物理機所有數據都要從遠程盤上讀，這樣會導致對遠程盤機器的配置較高的要求，并且壓力也很大。


而通過 P2P 手段，可以將一部分壓力分擔掉，當一臺機器已經有另一臺需要的數據時，它倆之間可以完成數據互傳。

• 高效壓縮算法

同樣是解決網絡帶寬的問題，遠程盤對應的數據都是沒有壓縮的，傳輸會占用比較多的帶寬。


而 DADI 則在傳輸過程中，跟蜻蜓一樣，對數據進行壓縮，減少網絡壓力。

• 本機緩存

這個是核心買點了，當容器啟動后，DADI 會把整個鏡像數據拉取到本地，這樣即使網絡有問題，也不會導致容器進程僵尸，解決了業務受損的問題。

總結

以上是生活随笔為你收集整理的云原生时代，2个方案轻松加速百万级镜像的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。