函數計算支援容器鏡像-加速應用 Serverless 程序

FaaS 的門檻

Serverless 形态的雲服務幫助開發者承擔了大量複雜的擴縮容、運維、容量規劃、雲産品打通內建等責任，使得開發者可以專注業務邏輯、提高傳遞速度 (Time-to-market) ，持續優化成本。Function-as-a-Service (FaaS) 作為雲上最早也是應用最廣泛的 Serverless 計算形态，在幾年的時間内吸引了大批開發者，逐漸建立了

Serverless 優先

的選型邏輯。 然而從傳統應用遷移到 FaaS 在開發者體驗上還面臨諸多挑戰:

1. 環境不統一：各廠商定義的傳遞物格式，運作環境相容性、豐富度都不盡相同，需要開發者适配，甚至重新編譯。
2. 學習成本：打包依賴庫、建構成壓縮代碼包和熟悉的開發部署方式不同
3. 服務限制：如代碼包限制在百 MB 級别，迫使傳遞物代碼依賴分離，加大管理和釋出難度。
4. 傳遞物缺乏版本管理：格式不标準，最佳實踐不統一，需要開發者自行負責。
5. 生态不成熟：缺少流行開源工具（如 CI/CD 流水線）的支援和內建。

另一方面，容器在可移植性和傳遞靈活性上實作了颠覆式創新。圍繞容器的生态沉澱非常豐富且成熟，被廣泛接受使用，應用容器化正在快速成為開發和部署的事實标準。然而容器本身并沒有減輕運維、擴縮容、閑置成本、和雲服務內建等難題。

比較項	容器技術	FaaS
應用可移植性	Builds once, runs anywhere	雲廠商鎖定
開發、建構工具鍊	豐富、标準的開源生态	雲廠商提供
持續建構、傳遞 （CI/CD）
代碼、環境分享複用	标準鏡像 Layer	FaaS 優化的 Layer
運作時環境	高度靈活、自定義	平台指定的運作環境
運維責任	Serverfull, 開發運維人員負責	Serverless, 雲廠商負責
成本優化	容器細粒度編排、部署	請求粒度計費，無閑置成本
伸縮速度	和鏡像大小相關，10s-分鐘級	極速，100ms 級别
事件驅動、雲産品內建	弱，需自建	核心能力

函數計算支援容器鏡像

阿裡雲 FaaS 函數計算支援容器鏡像作為函數傳遞物，将容器優秀的開發、部署、生态（

上線前

）結合函數計算自身免運維、零閑置成本、雲服務內建等特性（

上線後

），全面更新開發者體驗：

• 簡化應用 Serverless 化：無需修改代碼或是重新編譯二進制、共享對象（*.so），本地調試，保持開發和線上環境一緻。
• 更大函數代碼限制：解壓前鏡像最大支援1 GB（相比代碼包最大解壓前 50MB），避免代碼和依賴分離，簡化分發和部署。
• 容器鏡像分層緩存：增量代碼上傳和拉取，提高開發效率和降低冷啟動延遲。
• 鏡像分享、複用：邏輯可以移植、減少重複開發建設。
• 混合部署：同一應用 Serverfull (ECS, 容器 ACK)、Serverless (FC, ASK, SAE)，不同應用混合部署或同一應用不同服務間切流，達到性能一緻、資源剛性傳遞、快速擴容、運維最小化的平衡。
• CI/CD： 持續建構、內建測試、代碼上傳、存儲和标準的版本管理，豐富的開源生态 CI/CD 工具可以複用。

典型客戶場景

事件驅動音視訊處理

音視訊處理有流量波動較大、對計算資源彈性要求高、監聽視訊上傳事件以及依賴工作流和隊列等服務的特性使得 FaaS 成為自建音視訊業務上雲的首選。然而這類場景中最常用的軟體 ffmpeg 往往需要定制編譯滿足不同的需求。編譯的二進制依賴編譯環境中的共享對象（*.so）和 glibc 等庫，與 FaaS 運作環境不相容無法運作。重新編譯不僅帶來了額外工作，不同的依賴和版本也給業務穩定性帶來了挑戰。 如下圖示例，使用已有 Dockerfile 将轉碼邏輯以及相關依賴保持現有的安裝方式和完全隔離的容器沙箱運作環境，極大降低遷移成本，穩定性風險和 FaaS 的開發部署學習成本。

Serverless AI/ML 模型預測、推理 serving

AI/ML 推理預測服務同樣可以享受 FaaS 免運維、自動伸縮、低成本的好處。然而社群流行的架構如 TensorFlow 都預設以容器鏡像的方式分享和複用。不僅官方提供了完整的版本覆寫，基于官方鏡像的社群生态也非常活躍。在離線模型訓練階段以容器鏡像部署在 ECS 或 ACK/ASK GPU 叢集。 在服務推理/預測（serving inference/prediction）階段，CPU 往往是成本效益更高的選擇。Serving 的特點是請求量驅動，既需要能快速響應突發（burst）流量，又要在波谷周期釋放資源，甚至是縮容至0節省成本。而這些需求天然就是函數計算所擅長的。

在沒有容器鏡像支援之前，想要将一個 TensoflowFlow serving 的示例部署在函數計算上并不容易。TensorFlow 本身的庫大小遠超過代碼包 50MB 的限制，将依賴打包進 NAS 可以繞過這個問題，然而卻增大了上手和遷移的難度。不規範的依賴和版本管理也為變更引入穩定性風險。而使用容器鏡像以及函數計算 HTTP server 的程式設計模型，簡單的幾行 Dockerfile 就可以在 FC 跑起來 Tensorflow Serving 的示例：

函數計算支援容器鏡像幫助 AI/ML 場景平滑地混合部署容器和函數，統一 CICD 工具、流程和最佳實踐。函數計算免運維、高并發、百毫秒級别的執行個體擴容和 100% 資源使用率進一步優化了服務品質和成本。

傳統 Web 單體 HTTP 應用 Serverless 演進

傳統 Web 單體 (monolithic) 應用現代化有三個主要的訴求：責任拆分、減輕運維壓力（資源規劃、系統更新、安全更新檔等運維負擔）以及成本優化。雖然采用職責單一的函數是一種最佳實踐，但是進行職責拆分往往需要更長時間的設計和重構。借助函數計算的鏡像支援能力，單體應用可以很容易的遷移至 FaaS 服務以滿足免運維，彈性水準擴充和100%成本效率的訴求。

傳統 Web 應用由于曆史原因或者業務複雜度，運作環境（容器鏡像）和業務邏輯往往高度耦合且解耦代價較高。為了 Serverless 化改造有時不得不更新作業系統及依賴庫版本，在 FaaS 廠商提供的環境中重新編譯。遷移至 Serverless 架構有時間成本和穩定性風險。函數計算對容器鏡像的支援幫助傳統容器化 Web 應用無改造，更快地享受 Serverless 的價值，将時間和精力專注于業務邏輯創新和疊代而非重複枯燥的環境、依賴版本管理、更新維護和容量規劃和伸縮。

雲上雲下，跨雲廠商混合部署

企業上雲的節奏在不斷加快，然而由于業務特性，私有雲和公共雲混合的運作方式将是未來相當長一段時間内作為常态。企業甚至需要多雲廠商來保證遷移、容災、資源剛性傳遞的需求。容器鏡像是雲上、雲下的軟體傳遞物統一的預設選擇。函數計算自定義 runtime 選擇 HTTP server 标準的互動方式，函數代碼程式設計方式不與廠商綁定，減輕企業對雲廠商鎖定（vendor-lockin）的顧慮，在雲上可以運作的函數，在雲下甚至其他雲廠商同樣可以作為獨立的 HTTP Web 應用單獨部署，服務請求。容器打包的函數可以運作在其他雲服務的容器服務或 IaaS 自建服務，實作多雲的容災、彈性資源保障。

冷啟動最佳實踐

FaaS 代碼包的傳遞物将業務邏輯和執行環境剝離，最小化運作業務邏輯所需要加載的資料量，最大程度優化了冷啟動速度。容器鏡像則是将運作環境和業務邏輯統一傳遞，在可移植和冷啟動速度之間做了取舍。自定義運作環境的引入必然會增加額外的冷啟動延遲，對此我們推薦以下的冷啟動優化最佳實踐：

• 容器鏡像位址推薦使用與函數計算同地域的 VPC 鏡像位址，例如

  registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1

  , 以獲得最優的鏡像拉取延時和穩定性
• 鏡像最小化，使用類似 docker-slim 工具僅儲存必要的依賴和代碼，避免不需要的文檔、資料或其他檔案造成的額外延遲
• 在資源允許和線程安全的情況下，搭配 單執行個體多并發 一同使用，可避免不必要的冷啟動，同時降低成本。
• 容器鏡像配合 預留執行個體 一起使用，消除冷啟動。

DevOps/GitOps 最佳實踐

容器鏡像的支援标準化了建構步驟和函數傳遞産物，讓複用 CI/CD 工具成為可能。函數計算與阿裡雲

雲效

DevOps 服務內建，推出了 CI/CD 流水線。如下圖所示，當有新的代碼被 push 進入代碼倉庫（Github/Gitlab） master 分支, 建構流水線任務被開啟，按照代碼中指定的 Dockerfile, 容器鏡像會被建構并推送至阿裡雲容器鏡像服務。流水線的最後一個步驟會部署釋出新版本的函數，完成一次自動化的釋出。

除了雲效 DevOps 完整自動化的持續內建傳遞體驗，阿裡雲容器鏡像服務和自建開源 CICD 流水線也同樣可以用下圖展示的方式自動化函數釋出。函數計算釋出方式的标準化使得企業可以用統一的工具持續傳遞多個不同的服務，降低開發運維人員對部署工具的學習成本，自動化部署提高成功率和傳遞速度 (time-to-market)。

和 Custom Runtime 的異同

函數計算在 2019 年已經推出了自定義運作時

Custom runtime

，那麼這次釋出的自定義容器（custom-container）和已有的運作時有和異同呢？

• 相同的程式設計模型和函數計算系統的互動方式：完全相同的 HTTP server 協定，已有的 custom runtime 函數可以直接移植到環境相容的自定義容器環境中，不需要修改代碼：
• 兩個 runtime 有不同的适用場景和取舍：
  1. 對于非容器化的應用，您可以持續使用 custom runtime
  2. 對于冷啟動延遲容忍度較低的場景，推薦您使用 custom runtime 節省鏡像拉取時間
  3. 對于異步離線且已經容器化的任務（job 類型），推薦您使用 cutome-container runtime
  4. 使用函數計算預留執行個體，且部署環境和業務邏輯耦合緊密的應用可以優先考慮使用 custom-container runtime

未來規劃

随着容器逐漸成為應用傳遞部署的标準方式，FaaS 會和容器生态做更緊密的融合，幫助容器化的應用以更低的成本 Serverless 化，包括周邊配套生态例如聲明式的部署方式的融合，同 K8s 相似的應用抽象，雲原生可觀測性軟體內建。基于容器鏡像拉取加速，讓函數計算能兼顧可移植和快速啟動的性能。容器技術和 Serverless 的初心都是要幫助使用者更快地傳遞（time-to-market）和持續優化成本，消除資源閑置産生的浪費，增加企業競争力。最終雲原生的兩大技術領域：Serverless 和容器技術的聯系将會變得更加緊密，開發部署運維差異不斷縮小，讓開發者幾乎不需要修改業務邏輯即能為不同的工作負載選擇合适的技術方案，用開放、标準、統一的雲原生技術持續創新，為客戶創造更多價值。