一背景

函式計算在2020年8月創新地提供了容器映象的函式部署方式。AWS Lambda在2020年12月Re-Invent，國內其他FaaS提供商在2021年6月也相繼宣佈了FaaS支援容器的重磅功能。冷啟動一直都是FaaS的痛點，引入比程式碼壓縮包大幾十倍的容器映象後冷啟動惡化便成為開發者最大的擔憂。

函式計算在支援容器映象的設計階段就決定要讓開發者像使用程式碼包（秒級彈效能力）一樣的體驗使用映象，既要易用性也要保持FaaS自身的極致彈性，免除使用者的糾結和取捨。理想的使用者體驗是函式呼叫幾乎感覺不到映象資料遠端傳輸帶來的延遲額外消耗。

最佳化映象加速冷啟動大致分為兩種做法：降低絕對延遲和降低冷啟動機率。自容器映象上線以來我們已經透過映象加速技術，分階段降低了絕對延遲。本文在此基礎上，介紹藉助函式計算下一代IaaS底座神龍裸金屬和安全容器，進一步降低絕對延遲且能夠大幅降低冷啟動頻率。

二最佳化歷程

（以某一映象為例）

1 第一代架構：ECS虛擬機器

第一階段（2021年3月）：按需載入，減少資料傳輸

過去的問題在於啟動映象前全量拉取映象內部資料，導致無用的映象資料也會被完整下載而佔用了過多的準備時間。於是我們最初的最佳化方向是儘量忽略無用的映象資料，達到按需載入。為此，我們透過映象加速技術，省略掉了拉取無用資料的時間，實現了函式計算自定義映象冷啟動從分鐘級到秒級提升的相關技術細節。

第二階段（2021年6月）：記錄容器例項啟動I/O軌跡，在後續例項啟動中提前預取映象資料

我們發現，函式例項在容器啟動和初始化階段，I/O資料訪問模式高度一致。根據FaaS平臺基於應用執行模式排程資源的特點，我們在函式例項首次啟動時記錄了I/O軌跡的脫敏資料，在後續的例項啟動時，將軌跡資料作為提示，提前預取映象資料到本地，進一步減小了冷啟動延時。

上述兩種加速最佳化雖然大幅減小了冷啟動絕對延遲，但由於傳統ECS VM在閒置一段時間後就會被回收，再次啟動新機器時就會重新觸發冷啟動。於是，如何減少冷啟動頻次便成為了下一階段重點攻克的題目之一。

2 下一代架構：彈性裸金屬伺服器（神龍）+ microVM

在設計下一代架構時我們不僅考慮解決冷啟動頻次問題，也同樣注意到快取對於啟動時延的影響。於是我們創新性的發明了Serverless Caching，根據不同的儲存服務特點構建資料驅動、智慧高效的快取體系，實現軟硬體協同最佳化，將Custom Container體驗進一步提升。函式計算後臺神龍的更迭時間遠大於ECS VM的閒置回收時間，對於使用者側而言，熱啟動頻率大幅提升，在冷啟動後，快取會持續保留在神龍機器上，快取命中率可達90%以上。

對比ECS虛擬機器，神龍裸金屬加上微型虛擬機器的架構為映象加速帶來了更多的最佳化空間：

減小回源頻寬壓力並且減少重複資料儲存。比起ECS VM來，同時幾千例項啟動，對於映象倉庫的讀放大和磁碟儲存空間的寫放大降低至少兩個數量級。

虛擬機器級別的安全隔離使得函式計算元件可以安全地組成可用區級別快取網路，速度傳輸速度甚至優於雲盤。

函式計算Custom Container登陸神龍的同時也提高了資源利用率，降低成本，這對使用者和服務端維護是雙贏。

Serverless Caching的架構則可以在不增加資源使用成本的同時提供更多的最佳化潛力。

(L1~L4為不同級別快取，距離和延遲從小到大）

三橫向對比

到目前為止，我們已經將映象加速最佳化到了較高的水準。我們在函式計算的公開用例裡面挑選了4個典型的映象並將它們適配至國內外幾個大型雲廠商（名稱以廠商A、廠商B代替）進行橫向對比，每間隔3小時呼叫上述映象，重複數次，我們得到了以下結果：

1 AI線上推理-貓狗識別

該映象包含了基於TensorFlow深度學習框架的影像識別應用。阿里雲函式計算和廠商A都能正常執行，但廠商A效能較差。廠商B則無法正常執行。下圖中阿里雲函式計算和廠商A的延時資料包含映象拉取，容器啟動，執行推理運算端對端的延時，而廠商B的資料只是拉取映象部分的延時，都已經是最慢。FC相對穩定，可以看出函式計算在CPU消耗型如AI推理方面有著更大優勢。

以雲盤熱啟動為基準（灰色），對比各個廠商的額外開銷（彩色）

2 Python Flask Web Service

此映象為常見的網路服務，內部使用Python搭配Flask服務框架。此映象的作用旨在測試不同雲產品是否有能力完成高效按需載入。FC與廠商A均有波動但後者的波動最為明顯。

以雲盤熱啟動為基準（灰色），對比各個廠商的額外開銷（彩色）

3 Python機器學習運算

映象內同樣是Python執行環境，可以看出各個廠商依舊保持著各自的特性，廠商B全量下載，廠商A部分請求有最佳化但不穩定。

以雲盤熱啟動為基準（灰色），對比各個廠商的額外開銷（彩色）

4 Cypress Headless Chrome

此映象包含無頭瀏覽器測試流程，廠商A由於程式設計模型限制和執行環境不相容無法執行。而廠商B過慢只能在規定時間內耗時71.1秒完成應用初始化。不難看出函式計算在重I/O的映象方面依然有著不錯的表現。

以雲盤熱啟動為基準（灰色），對比各個廠商的額外開銷（彩色），綠色部位為優於基準線的端到端耗時

四推薦最佳實踐

支援容器技術是 FaaS 的必備特質，容器增加了可移植性和交付敏捷性，而云服務減輕了運維與閒置成本、提供了彈性擴縮容能力。自定義映象與函式計算結合最直接的解決了使用者為雲廠商定製化地移植大容量業務邏輯帶來的困擾。

FaaS執行容器時需要儘可能消除額外開銷，使使用者體驗與本地執行場景相近。穩定快速的運行同樣是優秀FaaS的標準，FC提供了映象載入最佳化的同時大大降低了冷啟動頻次為穩定快速的執行提供了保障。不僅如此，在應用的可移植方面更加需要做到平滑，不限制開發模式的同時也要儘量降低使用者使用門檻。函式計算自定義映象支援標準HTTP服務，自由配置可用埠，可讀的同時也可寫，提供多種工具鏈以及多元化的部署方案，無強制等待映象準備完成時間，自帶HTTP觸發而不依賴其他雲服務，支援自定義域名等一系列優質解決方案。

函式計算自定義映象適用但不限於人工智慧推理、大資料分析、遊戲結算、線上課程教育、音影片處理等。推薦使用阿里雲容器映象服務企業版例項ACR EE，自帶映象加速功能，省去使用ACR映象時手動開啟加速拉取和加速映象準備的步驟。

1 AI/ML線上推理

推理類計算依賴大體積底層訓練框架以及大量的資料處理，普通的AI框架如Tensorflow的映象可以輕鬆達到GB級，對CPU要求已經很高，要再滿足擴縮容就更是挑戰。函式計算自定義映象可以很好的解決此類需求，使用者只需直接使用底層訓練框架映象並與資料處理邏輯打包至新的映象內便可以輕鬆省去更換執行環境所帶來的移植開銷，同時又可以滿足彈性擴縮容帶來的快速訓練結果。歌曲喜好推理、圖片AI識別分析等都可以無縫與函式計算銜接以達到彈性滿足大量動態的線上推理請求。

2 輕量靈活ETL

服務都依賴資料，而資料處理往往需要消耗大量資源來滿足高效快速的資料變更請求。自定義映象與其他函式計算執行時一樣可以滿足資料處理時的安全隔離，又同時保留了使用者將資料處理部分的業務邏輯自由的打包成映象的便捷能力。提供平滑遷移的同時滿足了映象啟動的極低額外延時，滿足了使用者針對如資料庫治理、萬物物聯等應用場景的安全，高效，彈性的資料處理需求。

3 遊戲戰鬥結算

各類遊戲內通常會設定日常任務等場景短時間集聚大量玩家同時需要戰鬥結算一類的資料處理，為了不讓遊戲玩家失去耐心，戰鬥資料校驗通常需要在短短幾秒內完成，且單個玩家的資料結算單位時間不能隨著玩家數量增長而惡化。此類資料處理的業務邏輯通常繁雜且高度重複，將玩家資料處理邏輯打包至函式計算自定義映象內便可以彈性滿足短時間大量相似的玩家結算請求。

五未來規劃

最佳化函式計算自定義映象的初衷就是要讓使用者感受不到容器映象傳輸帶來的額外延遲，給雲原生開發者最極致的體驗。最佳化不會停止，我們最終的目標是幾乎消除容器映象拉取的額外開銷和大量擴容時映象倉庫成為瓶頸，極速伸縮。進一步完善Serverless Caching的同時Custom Container功能未來會幫助Kubernetes上的Web應用, Job類工作負載無縫執行在函式計算。Kubernetes負責處理常駐、流量穩定的工作負載，Serverless服務分擔波動明顯的計算將逐漸成為雲原生的最佳實踐。

函式計算的公開用例：https://github.com/awesome-fc