一 背景
函數計算在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的架構則可以在不增加資源使用成本的同時提供更多的優化潛力。
三 橫向對比
到目前為止，我們已經将鏡像加速優化到了較高的水準。我們在函數計算的公開用例裡面挑選了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