FaaS 和容器
容器鏡像因其顛覆式創新成爲雲原生時代應用部署格式的事實標準。頭部雲廠商 FaaS (Function-as-a-Service) 服務如阿里雲函數計算、AWS Lambda 也相繼在 2020 年支持使用容器鏡像部署函數，全面擁抱容器生態。自發布以來，開發者陸續將機器學習、音視頻處理、事件驅動離線數據處理、前端自動化等多個場景使用鏡像快速無服務器化，提高效率、降低成本。然而，冷啓動一直是 Serverless 無法繞開的問題。容器鏡像需要將數據通過網絡遠程下載並解壓，對於 GB 級別的鏡像，拉取時間可能高達分鐘級別，客觀上放大了冷啓動副作用，阻礙實時應用的 Serverless 演進。
函數計算鏡像加速功能
傳統的鏡像拉取加速強調"開發者負責"，如精簡鏡像，合理分配鏡像層，multi-stage 構建，使用工具（如 docker-slim）去除不需要的數據，遵循構建最佳實踐等。這些工作不僅加重了用戶負擔，加速效果有限，且有運行時穩定性風險。阿里集團超大規模和場景高度複雜的容器環境，對鏡像存儲、加速技術有深厚的積累，出色地承擔了 3 年雙十一、雙十二、春節等大促秒殺場景的嚴苛的挑戰。阿里雲 Serverless 同容器鏡像、存儲等服務深度合作，將內部創新在函數計算輸出：杭州、北京、上海、美東、美西正式發佈了鏡像加速功能。該功能將原本屬於開發者的鏡像優化負擔轉由函數計算承擔，進一步幫助開發者提高生產效率，專注業務創新。
1. 加速效果
我們在選擇了內部生產環境和開源社區的工作負載，覆蓋機器學習、人工智能、前端自動化、Web 應用等 7 種鏡像大小、IO 訪問模式、啓動命令的不同組合作爲 benchmark，部署在 FC 北京區域。如下圖所示，函數計算開啓鏡像加速功能後加速普遍超過 50%，對於機器學習場景中常見的臃腫鏡像（如多個團隊共享基礎鏡像, ml-small-import, ml-large-import, ai-cat-or-dog）加速效果更爲明顯（約 70%-86%），鏡像越大優化空間往往越高。
2. 使用方式
鏡像加速可以通過控制檯、CLI 工具或是 FC SDK 開啓，詳細步驟參考鏡像拉取加速文檔。
- 方式一：在函數計算控制檯函數配置下選擇“開啓鏡像加速”。
- 方式二：使用 Funcraft 工具部署。
在已有的 CustomContainerConfig 配置下添加 AccelerationType: Default 如需關閉則配置 AccelerationType：
CustomContainerConfig:
Image: registry-vpc.cn-beijing.aliyuncs.com/fc-demo/python-flask:v0.1
AccelerationType: Default3. 功能特點
FC 鏡像加速具備以下特點：
- 使用簡單：只需在函數上開啓鏡像加速，函數計算會自動製作加速鏡像和緩存，轉換完成後（5分鐘以內），函數自動採用加速鏡像緩存。
- 專注業務創新：開發者無需花費時間刻意精簡優化鏡像大小或嚴格區分 Serverless 和 Serverfull 應用鏡像的構建方式，FC 負責按照應用實際使用數據拉取和解壓。
- 加速免費，使用門檻低：鏡像加速開啓不產生額外費用，也不需要開發者額外購買或升級任何其他服務。事實上由於鏡像拉取時間變短，相應的請求費用也隨之降低。
- 極速彈性、縮容到 0、事件觸發：FaaS 結合容器鏡像已經極大簡化了應用遷移至 Serverless，加速功能進一步解鎖了實時、準實時工作負載，曾經需要分鐘級別的容器啓動現在可以幾秒內快速啓動，真正實現縮容到 0。
鏡像拉取爲什麼慢？
一個 OCI V1 容器鏡像包含多個層（layer），每層都是一個壓縮打包的文件系統（文件夾），通常以 tar.gz 格式存儲在遠端服務（如對象、文件存儲）。拉取鏡像時步驟如下：
- 將各個 layer 對應的 tar.gz 文件完整下載至本地。
- 每層順序解壓。
- 將各個層合併（如 Overlay）作爲 rootfs 啓動容器。
上述步驟雖然簡單，卻是鏡像拉取慢的主要原因：
- 文件格式缺陷、粗粒度數據分層、順序解壓：gzip 層導致無法細粒度隨機讀取應用實際需要的數據，且要求所有層單線程順序解壓。實際觀察發現鏡像層可以通過併發下載提高速度，然而解壓環節在 gzip 格式下卻很難優化。
- 低效的壓縮/解壓縮算法：鏡像層採用的 gzip，benchmark gzip 解壓速度對比 lz4 平均慢接近 9 倍。
- 全量數據下載：同樣由於粗粒度的分層和 gzip 格式（不支持 seek），鏡像數據不論是否實際有用，都要被完整下載至本地。
綜上原理，鏡像拉取時間和鏡像大小成正比，而容器鏡像構建過程中運行 apt/yum install, 無用的測試、數據文件，構建過程中執行 chmod/chown 等命令造成同一數據複製多份，極易引入大量應用不需要的數據。
加速原理
函數計算將阿里集團成熟的鏡像加速技術應用在公共雲服務中，加速技術圍繞兩個核心思路：
- 按需加載：僅讀取應用真實需要的數據，極大減少數據傳輸量。
- 更高效的存儲和算法：相同大小的數據，更快地解壓。
1. 按需加載
Benchmark 中包含鏡像數據加載率在 12% - 84% 之間，除了鏡像較小的 web 應用，大部分場景數據利用率低於 50%。以層（layer）作爲數據分發單位的原始鏡像被轉換成支持細粒度按需讀取的數據格式，並存放在延遲和吞吐都更優的存儲中。
2. 高效解壓
除了按需加載帶來的下載步驟延時節省，鏡像加速技術在數據解壓步驟也同樣做了大量優化。下圖可以看出即使在加載 70% 以上全量數據的情況下，優化效果仍然超過 60%。
未來規劃
函數計算正式發佈了容器鏡像加速，通過按需讀取和更高效的解壓技術在不同場景下加速 50%-80%，即使 GB 級別的鏡像也可以在幾秒內完成端到端啓動。加速功能結合函數計算極致彈性和事件觸發的特點，解鎖了更多對實時要求高的工作負載。容器應用可以更容易地享受 Serverless 特性，真正做到縮容到 0 以及快速大規模擴容。FC 在未來會持續優化冷啓動各個環節提供極致彈性，承擔更多用戶責任，使開發者專注業務創新。
附錄：實驗場景數據
作者：Shuai Chang，阿里云云原生 Serverless 團隊高級技術專家，主導了函數計算同容器技術生態融合以及 FaaS 雲原生可觀測。
本文爲阿里雲原創內容，未經允許不得轉載。