近日阿裡巴巴開源了其雲原生容器鏡像加速技術（ https://github.com/alibaba/accelerated-container-image
），其推出的overlaybd鏡像格式，相比于傳統的分層tar封包件格式，實作了基于網絡的按需讀取，進而使得容器可以快速啟動。
該技術方案原本是阿裡雲内部DADI項目的一部分， DADI是Data Accelerator for Disaggregated Infrastructure的縮寫，旨在為計算存儲分離架構提供各種可能的資料通路加速技術。鏡像加速是DADI架構在容器及雲原生領域的一次突破性嘗試，該技術自2019年投産以來，已線上上部署了大量機器，累計啟動容器次數超過10億，支援了阿裡巴巴集團及阿裡雲的多個業務線，極大提高了應用的釋出和擴容效率。2020年，團隊在國際頂級會議發表了論文 "DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20"
[1] ，并随後啟動了開源項目，計劃将技術該貢獻給社群，通過建立标準并打造生态，吸引更多的開發者投入到容器及雲原生性能優化這個領域上來。背景簡介
随着Kubernetes和雲原生的大爆發，容器在企業内部的大規模應用已經越來越廣泛。部署啟動快是容器的核心優勢之一，這個啟動快是指本地鏡像執行個體化的時間非常短，即“熱啟動”時間短。然而對于“冷啟動”，即在本地無鏡像的情況下，需要先從Registry下載下傳鏡像才能建立容器。業務的鏡像經過長期維護和更新，無論是鏡像層數還是整體大小都會達到一個較大的量級，比如可能達到數百MB或者幾個GB。是以生産環境中，容器的冷啟動往往耗時數分鐘，并且随規模擴大會導緻Registry因叢集内網絡擁堵而無法快速地下載下傳鏡像。
例如，在之前某年的雙十一活動中，阿裡内部一個應用因為容量不足觸發緊急擴容，但因并發量過大，整體擴容耗時較長，這期間對部分使用者的使用體驗造成了影響。而到了2019年，随着DADI的部署上線，新鏡像格式的容器在“鏡像拉取+容器啟動”上耗費的總時間比普通容器縮短了5倍，且p99長尾時間更是比後者快了17倍。
如何處理存儲在遠端的鏡像資料，這是解決容器冷啟動慢這個問題的核心點。曆史上業界對這一問題做出的嘗試有：使用塊存儲或者NAS儲存容器鏡像，實作按需讀取；使用基于網絡的分發技術（如p2p），将鏡像從多個源頭下載下傳、或者提前預熱到主機上，避免出現網絡單點瓶頸。近年來，針對新鏡像格式的讨論也逐漸被提上議題，根據Harter等人的研究
[2]表明，拉取鏡像占用了容器啟動時間的76%，而隻有6.4%的時間用來讀取資料。是以，支援On-demand Read技術的鏡像，已經成為預設的潮流風向。Google提出的stargz
[3]格式，其全稱是Seekable tar.gz，顧名思義，可以有選擇地從存檔中搜尋并提取特定的檔案，無需掃描或者解壓整個鏡像。stargz旨在提高鏡像拉取的性能，其延遲拉取技術（lazy-pull）不會拉取整個鏡像檔案，實作了按需讀取。為了進一步提高運作時效率，stargz又推出了一個containerd的snapshotter插件，在存儲層面對I/O做了進一步優化。
在容器的生命周期中，鏡像就緒後需要挂載（mount），而分層鏡像挂載的核心技術便是overlayfs，它以一種堆疊的形式将下層的多個layer檔案合并，并向上暴露出一個統一的隻讀檔案系統。類比上文提到的塊存儲和NAS，一般可以通過快照的形式進行分層堆疊，而跟stargz綁定的CRFS，也可以看做是overlayfs的另一種實作。
新鏡像格式
DADI沒有直接使用overlayfs，或者說，它隻是借鑒了overlayfs和早期聯合檔案系統（union filesystem）的思想，但提出了一種全新的基于塊裝置的分層堆疊技術，稱之為overlaybd，它為容器鏡像提供了一系列基于塊的合并資料視圖。overlaybd的實作十分簡單，是以很多之前想做而不能做的事都可以成為現實；而實作一個完全POSIX相容的檔案系統接口則充滿挑戰，并可能存在bug，這點從各個主流檔案系統的發展曆史上就可以看出。
除了簡單以外，overlaybd對比overlayfs的其他優點有：
- 避免多層鏡像導緻的性能下降，如overlayfs模式下大檔案的更新會觸發跨層引用複制，系統必須先将檔案複制到可寫層；或者建立硬連結速度很慢等問題
- 可以友善地采集block級别的I/O模式，進行錄制以及重放，進而預取資料，進一步加速啟動
- 使用者的檔案系統和主控端OS可以靈活選擇，如支援Windows NTFS
- 可以使用有效的編解碼器進行線上解壓縮
- 可以下沉到雲中的分布式存儲（如EBS）中，鏡像系統盤可以跟資料盤使用同一套存儲方案
- overlaybd具有天然的可寫層支援（RW），隻讀挂載甚至可以成為曆史
overlaybd原理
為了了解overlaybd的原理，首先需要了解容器鏡像的分層機制。容器鏡像由多個增量layer檔案組成，在使用時進行疊加，這樣在鏡像分發時隻需要對layer檔案進行分發。每一層實質上都是與上一層的差異（包括檔案的添加，修改或删除）的壓縮包。容器引擎可以通過其storage driver，按照約定的方式将差異疊加起來，然後以Read-Only的模式挂載到指定目錄，該目錄即稱為lower_dir；而以Read/Write模式挂載的可寫層，挂載目錄則一般稱為upper_dir。
請注意，overlaybd本身沒有檔案的概念，它隻是将鏡像抽象為虛拟塊裝置，并在其上裝載正常的檔案系統。當使用者應用讀取資料時，該讀取請求首先由正常的檔案系統處理，将請求轉換為虛拟塊裝置的一次或多次讀取。這些讀取請求會被轉發到使用者态的接收程式，即overlaybd的運作時載體，最後轉換為對一個或多個layer的随機讀取。
與傳統鏡像一樣，overlaybd在内部仍然保留着layer分層的結構，但每層的内容都是檔案系統變更差異對應的一系列data block。overlaybd向上提供了一個合并視圖，對layer的疊加規則很簡單，即對于任意一個data block，總是使用最後的變更，在layer中未發生變更的塊均視為全零塊；向下又提供了将一系列data block導出成一個layer檔案的功能，該檔案高密度非稀疏、且可索引。是以，對塊裝置某個連續LBA範圍進行讀操作，可能包含了原本屬于多層的小塊資料段，我們将這些小塊資料段稱為segment。從segment的屬性中找到層号，便能夠繼續映射到對這層的layer檔案的讀取上來。傳統的容器鏡像可以将它的layer檔案儲存在Registry或者對象存儲上，那麼overlaybd鏡像自然也可以。
為了更好的相容性，overlaybd在layer檔案的最外層，包裝了一層tar檔案的頭和尾，這樣僞裝成一個tar檔案。由于 tar内部僅一個檔案，不影響按需讀取。目前無論是docker、containerd或者buildkit，對鏡像的下載下傳或上傳預設都有untar和tar的流程，不侵入代碼是無法逾越的，是以增加tar僞裝有利于相容性和流程的統一，例如在鏡像轉換、建構、或者全量下載下傳使用時，都無需修改代碼，隻需提供插件即可。
整體架構
DADI整體架構如圖，以下分别介紹各個元件
containerd snapshotter
containerd自1.4版起，開始初步支援一些啟動遠端鏡像的功能，并且k8s已經明确将放棄Docker作為運作時的支援。是以DADI開源版本選擇優先支援containerd生态，之後再支援Docker。
snapshotter的核心功能是實作抽象的服務接口，用于容器rootfs的挂載和解除安裝等操作。它的設計替代了在Docker 早期版本稱之為graphdriver的子產品，使得存儲驅動更加簡化，同時相容了塊裝置快照與overlayfs。
DADI提供的overlaybd-snapshotter一方面能讓容器引擎支援新的overlaybd格式的鏡像，即将虛拟塊裝置挂載到對應的目錄，另一方面也相容傳統OCI tar格式鏡像，讓使用者繼續以overlayfs運作普通容器。
iSCSI target
iSCSI是一種被廣泛支援的遠端塊裝置協定，穩定成熟性能高，遇到故障可恢複。overlaybd子產品作為iSCSI協定的後端存儲，即使程式意外crash，重新拉起即可恢複。而基于檔案系統的鏡像加速方案，例如stargz，則無法恢複。
iSCSI target是overlaybd的運作時載體。在本項目中，我們實作了兩種target子產品：第一種是基于開源項目tgt
[4]，由于其擁有backing store機制，可以将代碼編譯成動态連結庫以便運作時加載；第二種是基于Linux核心的LIO SCSI target（又稱為TCMU）
[5]，整個target運作在核心态，可以比較友善地輸出虛拟塊裝置。
ZFile
ZFile是我們提供的一種支援線上解壓的資料壓縮格式。它将源檔案按固定大小的block size切分，各資料塊進行單獨壓縮，同時維護一個jump table，記錄了各資料塊在ZFile中的實體偏移位置。如需從ZFile中讀資料，隻要查找索引找到對應位置，并僅解壓縮相關的data block即可。
ZFile支援各種有效的壓縮算法，包括lz4，zstd等，它解壓速度極快，開銷低，可以有效節省存儲空間和資料傳輸量。實驗資料表明，按需解壓遠端的ZFile資料，性能高于加載非壓縮資料，這是因為傳輸節省的時間，大于解壓的額外開銷。
overlaybd支援将layer檔案導出成ZFile格式。
cache
正如上文所說，layer檔案儲存在Registry上，容器對塊裝置的讀I/O會映射到對Registry的請求上（這裡利用到了Registry對HTTP Partial Content的支援）。但是由于cache機制的存在，這種情形不會一直存在。cache會在容器啟動後的一段時間後自動開始下載下傳layer檔案，并持久化到本地檔案系統。如果cache命中，則讀I/O就不會再發給Registry，而是讀本地。
行業領先
3月25日，權威咨詢機構Forrester釋出2021年第一季度FaaS平台（Function-As-A-Service Platforms）評估報告，阿裡雲憑借産品能力全球第一的優勢脫穎而出，在八個評測次元中拿到最高分，成為比肩亞馬遜AWS的全球FaaS上司者。這也是首次有國内科技公司進入FaaS上司者象限。
衆所周知，容器是FaaS平台的承載基礎，而容器啟動速度更是決定了整個平台的性能與響應延遲。DADI助力阿裡雲函數計算産品，大幅度縮短容器啟動時間50%~80%
[6]，帶來了全新的Serverless使用體驗。
總結展望
阿裡巴巴開源的DADI容器加速項目以及其推出的overlaybd鏡像格式，有助于應對新時代下容器對快速啟動的需求。項目組未來将協同社群一起，加快對接主流工具鍊，積極參與新鏡像格式标準制定，目标是讓overlaybd成為OCI遠端鏡像格式的标準之一。
歡迎大家參與開源項目，一起貢獻力量！
後續工作
Artfacts Manifest
OCI Image的v1 Manifest格式描述能力有限，無法滿足遠端鏡像需求。目前v2的讨論沒有實質進展，推翻v1也不現實。但是，可以借助OCI Artfacts Manifest使用Additional Descriptor來描述原始資料，相容性上有所保證，使用者更容易接受。Artfacts也是OCI/CNCF在推廣的項目，DADI未來計劃擁抱Artfacts并實作PoC。
開放對多種檔案系統的支援
DADI本身支援使用者根據需要選擇合适的檔案系統來建構鏡像，但是目前尚未開放相應的接口，預設使用了ext4檔案系統。我們未來将完善相關接口并放開此功能，由使用者根據自身需要，決定使用什麼檔案系統。
Buildkit工具鍊
目前使用者可以通過buildkit外挂snapshotter來建構鏡像，未來将進一步完善，形成完整工具鍊。
資料預取
在容器啟動後對I/O模式進行記錄，後續啟動同一鏡像時便可以重放該記錄，對資料進行預取，避免臨時請求Registry，這樣容器的冷啟動時間将繼續縮短一半以上。理論上所有無狀态或幂等容器都可以進行錄制和重放。
![在DOS下運作不了ipconfig指令[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)