前言
随着 Serverless 概念的進一步普及，越來越多的企業使用者開始将業務遷移到 Serverless 平台。通過 Serverless，使用者可以聚焦業務實作。無需關注運維與基礎設施，按需使用資源和付費 ，其中使用者最大的收益展現在兩個方面：
- "零"運維成本，将底層基礎設施的運維工作交由平台提供方（雲廠商）去完成；
- “零”資源浪費，無需常備資源，僅在需要運作業務的時候啟動執行個體，在處理完邏輯之後釋放資源，按使用量付費，降低雲資源的使用成本。
Serverless 給雲使用者帶來巨大收益的同時，也給雲廠商帶來了極大的挑戰。首先雲廠商需要提供穩定、強大的基礎設施，幫使用者維護好海量的執行個體；其次，按量付費，資源按需啟動運作則要求雲廠商提供足夠強大的彈性能力，能夠在短時間内為使用者啟動足夠多的執行個體，讓使用者可以在業務高峰到來的時候迅速準備好服務予以應對，這樣使用者才會放心地将核心業務托管在 Serverless 産品上。
在今年的雲栖大會上，阿裡雲的 Serverless 産品大放異彩，函數計算産品宣布支援 2 萬函數執行個體 /min 的并發傳遞能力，而 ECI（彈性容器執行個體）的技術專家陳曉宇更是進行了現場示範，在 6 秒鐘的時間内拉起了 3000 個彈性容器執行個體，向客戶展示了阿裡雲強大的 Severless 彈性能力。
在示範過程中，曉宇介紹了 ECI 在管控排程上的優化方案，同時也介紹了支撐 ECI 的底層方案--袋鼠系統。本文将詳細展開介紹袋鼠系統在阿裡雲強大基礎設施上所做的優化，揭秘支援阿裡雲雲原生 Serverless 快速彈性背後的底層技術。
雲原生容器運作時
對于雲廠商來說，Serverless 型産品需要有一個合适的運作時，提供以下基礎的能力：
- 雲原生生态相容：Severless 是雲原生的典型業務，對于雲原生生态（k8s 體系）有很強的依賴，是以需要運作時能夠無縫地與雲原生生态無縫對接
- 具備強隔離能力：雲廠商會服務衆多不同的客戶，是以一般單一實體機上需要運作多個不同客戶的執行個體，特别是在 Serverless 場景下，執行個體的規格普遍偏小，實體機上服務的客戶數量會更多。是以需要由運作時實作執行個體之間的絕對隔離，保障不同租戶之間的資料安全和穩定性。
基于以上的訴求，kata containers 進入了我們的視線。kata containers 架構引入了沙箱容器的概念，通過硬體虛拟化技術和獨立核心，提供了與 VM 同等級的多租隔離，另外通過 kata-shim-v2 接口，直接對接 contained 和 k8s，減少了重複建構、部署容器元件的開銷，也能夠較好地與開源的 k8s 生态（監控、metric、安全等）元件進行對接。
早在 2019 年，阿裡雲就基于 kata containers 架構進行 Serverless 服務的探索，将其用到了生産中去，即阿裡雲袋鼠沙箱容器 1.0 架構。在生産實踐過程中，我們也發現了原生 kata containers 的一些不足：
- 首先是啟動速度：由于硬體虛拟化和分離核心的存在，相比于普通容器，kata 容器需要額外增加虛拟化環境的建立時間、guest 核心啟動時間、guest OS 内系統元件啟動時間等，這些時間累加起來會極大的影響容器的擴容速度。雖然袋鼠沙箱 1.0 做了很多針對性的優化，将容器執行個體整體拉起時間（從containerd發起建立容器到 pause 容器 running）時間優化到了 800ms，但是相比普通容器還是有比較大的差距。
- 其次是資源開銷：在 kata 容器預設推薦配置中，會預留 2G 的記憶體資源給 guest 内的管控資源或 guest kernel 使用。在實際應用過程中，即便袋鼠沙箱進行了大量的優化，最終整體的 guest 内開銷還有 200M左 右，host 上也有接近 100M 左右的記憶體開銷。
- 最後是穩定性：這是一個表征不明顯但是影響極大的問題。相比于普通容器，kata containers 引入了更多的元件，包含 kata-shim，hypervisor、guest kernel、kata-agent 等等，衆多元件極容易出現銜接異常引發的問題，主要展現在執行個體的建立、銷毀等過程中。對此 kata-shim-v2 在一定程度上緩解了這個問題，但是線上上還是遇到過一些由于 shim-v2 和 hypervisor 之間的通信或者狀态同步導緻的穩定性問題。
以上的問題在 Serverless 場景下會被放大，比如文章開頭的時候提到的極速并發能力，就需要運作時能夠快速的啟動執行個體，進而能夠在短時間内盡量多地将容器準備好投入服務，而 800ms 的啟動時間使得單機的并發能力受到了極大的限制；而 Severless 有大量的極小規格執行個體，像 ECI 就推出了 512M 記憶體的規格，在函數計算場景更是有 128M 的執行個體，如果運作時本身就有 200M 的開銷，對于客戶來說成本是不可接受的。同時，Serverless 執行個體的普遍運作時間很短，每日新增的執行個體建立是海量的，如果在建立、銷毀過程中會出現大量問題的話，那是不具備穩定生産條件的。
基于以上遇到的問題，阿裡雲的袋鼠團隊與螞蟻的可信原生技術團隊以 kata containers 為基礎架構，推出了阿裡雲袋鼠沙箱容器 2.0：
- 用基于硬體虛拟化的輕量級沙箱替換傳統的 vm，同時使用精簡裝置模型，并優化裁剪配置 Alibaba Cloud Linux kenrel，将整體軟體棧各個元件打薄；
- 創新性地将 shim-v2 元件和沙箱管理單元融合到一個程序中，推出了全新的容器引擎 runD，将 shim 以及沙箱管理的通信從 gRPC 換成了 function call 以及 IPC；
- 打通基于 ebpf 的管控通道，實作shim對于沙箱内運作時的 upcall 機制；
- 使用阿裡雲全新推出的 LifSeaOS（ContainerOS）作為 guestOS；
- 采用 rust 語言全新開發，并內建kata rust agent，實作沙箱管控鍊路的rust改造。
架構優化帶來的收益也是明顯的。
通過管控鍊路的縮短以及元件的精簡，并輔以對沙箱記憶體配置設定流程、host cgroup 管理流程和 IO 鍊路的優化，runD 執行個體的端到端啟動時間（從 containerd 下發建立指令到 pause 容器拉起）縮短到了 300ms，并發能力達到了 200/s。進入 2021 年，袋鼠沙箱容器更是引入了沙箱執行個體複制技術，在實驗室環境下将單執行個體端到端啟動縮短到了 110ms，并發能力提升到了驚人的 360/s。在生産環境下，即便包含業務管控耗時，ECI 的執行個體啟動時間也在1秒左右，單機并發達到了 50/s，支撐起了叢集 3000/6s，5000/15s 的極速并發能力。
除了啟動時間的收益，資源開銷也有了顯著的縮小，目前袋鼠沙箱容器内的資源 overhead 已經減少到 30M 左右，在産品上通過少量的資源“補償”，即可實作使用者的“零”overhead，所買即所得；同時 runD 在 host 上的資源開銷縮減到了 2M 左右，實作了在單一實體機上的 2000 執行個體的高密服務能力。
除了性能、開銷名額上的收益，新架構的使用也獲得了元件能力的更新。首先 runD 實作了針對沙箱容器的全鍊路熱更新能力，為産品的穩定性提供了兜底保障；同時使能了執行個體内資源熱插、熱拔的能力，可以實作針對單一執行個體的無損 VPA 能力。
袋鼠沙箱容器目前已經在阿裡雲上服務了數十款 Serverless 雲産品，每日承接了上百萬執行個體的建立、銷毀流量，為使用者提供了穩定、高效的運作時服務。而 runD 引擎也即将開源，我們期望通過社群化的運作，讓更多的雲原生場景能夠通過開源的技術獲得收益，敬請大家期待。
雲原生底層系統
以上着重介紹了阿裡雲袋鼠沙箱容器 2.0 運作時，但是 Serverless 産品是整體的優秀表現，單靠一個運作時是不夠的，需要有一套完整的系統方案進行支撐，袋鼠團隊正是在緻力于在打造這樣一套包含運作時、單機存儲、單機網絡方案的阿裡雲雲原生底層系統。
袋鼠沙箱容器運作在阿裡雲神龍平台上，享受神龍平台強大的 I 層能力。同時我們與 Alibaba Cloud Linux 的核心團隊針對雲原生 Serverless 場景進行了 Linux 核心深層次的優化，利用沙箱内 guest->runD->host kernel->神龍平台全棧優化，充分發揮阿裡雲強大的軟、硬體基礎設施結合能力帶來的紅利。
在針對 Serverless 業務進行特征分析和畫像的過程中，我們詳細刻畫了 Serverless 帶給雲基礎設施的壓力。統計資料發現，絕大部分執行個體的運作時長都很短，以分鐘甚至毫秒級為機關。再結合上文提到的大量 Serverless 使用者會在雲上使用小規格或者極小規格執行個體，以及瞬間并發的使用特征，如果給每一個 Severless 執行個體都配置設定一個傳統的 VPC 網卡或者雲盤，那麼頻繁的執行個體建立、銷毀會對整體的網絡、存儲後端帶來一系列嚴重的串擾。是以袋鼠團隊建構了一套單機系統，能夠覆寫單一實體機節點上的網絡、存儲，疊加于阿裡雲的基礎網絡和存儲之上，以單機為粒度吸收 Serverless 帶來的執行個體頻繁建立、銷毀的壓力。
網絡
針對 Severless 大量使用者使用網絡僅需要進行單向通路的特點（即容器不需要對外提供通路端口或者服務，僅需要通路 VPC 内的雲服務或者 ECS），袋鼠團隊設計研發了 ANSM（Alibaba Network Service Mesh）方案，将單實體機上 ENI 的建立頻率直接降低為零。
基于 ANSM 網絡方案，執行個體的網絡建立時間由秒級下降到了 200ms，并且單售賣節點上的執行個體數量、服務使用者的數量擺脫了 ENI 數量的限制，可以在一台實體機上排程任意使用者的任意數量的 POD，在生産上最大 POD 數量可達 2000 以上。
存儲
在存儲上，袋鼠提供了基于 Devicemapper 的存儲分割方案，利用該方案，一台售賣節點僅需要建立一次高規格的 ESSD 雲盤，然後便可以利用 Devicemapper 的能力進行切割對外提供服務，這個方案将不同執行個體存儲的建立時間由秒級優化到了毫秒級，同時使用塊裝置的形态提供給不同的使用者，保障了使用者之間資料的安全性。
鏡像
在生産實踐中，我們發現拉取容器鏡像、解壓容器鏡像耗時很長，占據了執行個體整體端到端啟動的大部分時間，是以 ECI 提供了 image cache 鏡像緩存方案，将使用者鏡像緩存在快照之中，直接将這這部分時間清零。同時我們也在探索是否有可以讓使用者無感進行鏡像拉取加速的方式，我們将關注點放到了 2016 年 Tyler Harter 在 FAST 會議上發表的題為《 Slacker: Fast Distribution with Lazy Docker Containers 》的演講，在其演講中闡述了他們的一個觀測結果：容器啟動階段僅需要使用鏡像中不到 7% 的資料。是以我們提出一種設想，是否可以有一種按需加載的鏡像拉取手段，僅将必要的資料拉取到本地，減少不必要的資料傳輸，在提升執行個體啟動性能的基礎上，同步減少并發場景下對于鏡像倉庫的傳輸帶寬的壓力。
在 2021 年，阿裡雲袋鼠沙箱容器正式将 Nydus 方案用在了 Serverless 産品之上。Nydus 是一種新型容器鏡像格式，基于 Nydus 鏡像加速方案，可以實作：
- 容器鏡像按需加載
- Chunk 級别的鏡像資料去重
- 去除鏡像分層，減少不同鏡像層之間的重複資料
使用 Nydus 鏡像加速方案之後，ECI 拉取 423M 大小的鏡像（解壓後 1.1G）時間由 20s 下降到了 0.8s，極大提升了執行個體啟動性能。目前 Nydus 已經在 CNCF 開源，并且正在與社群一起推進下一代鏡像格式，更多 Nydus 細節檢視：
https://github.com/dragonflyoss/image-service 小結
随着雲服務廠商服務邊界的逐漸上移，Serverless 服務正在通過給使用者提供更好的彈性、性能和成本能力幫助客戶快捷的完成業務的部署、運維和擴縮容，而袋鼠作為阿裡雲 Serverless 運作時産品的軟體系統底座，也在不斷地探索以更快的啟動時間、更高的并發能力和更強的運作時性能建構更強的 Servless 産品，為使用者帶來更多的價值。在此歡迎有識之士加入我們，一起建構硬核的雲原生底層系統。
聯系郵箱：[email protected]
加入龍蜥社群
加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥社群（OpenAnolis）交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！
關于龍蜥社群
龍蜥社群(OpenAnolis)是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于 2020 年 9 月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。
短期目标是開發龍蜥作業系統(Anolis OS)作為 CentOS 替代版，重新建構一個相容國際 Linux 主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。
龍蜥OS 8.4已釋出，支援 x86_64 、ARM64、LoongArch 架構，完善适配 Intel、飛騰、海光、兆芯、鲲鵬、龍芯等晶片，并提供全棧國密支援。
歡迎下載下傳：
https://openanolis.cn/download加入我們，一起打造面向未來的開源作業系統！
https://openanolis.cn