4 個場景揭祕，如何低成本讓容器化應用 Serverless 化？

做者 | changshuai 來源 | Serverless 公衆號

FaaS 的門檻

Serverless 形態的雲服務幫助開發者承擔了大量複雜的擴縮容、運維、容量規劃、雲產品打通集成等責任，使得開發者能夠專一業務邏輯、提升交付速度 (Time-to-market) ，持續優化成本。Function-as-a-Service (FaaS) 做爲雲上最先也是應用最普遍的 Serverless 計算形態，在幾年的時間內吸引了大批開發者，逐漸創建了 Serverless 優先的選型邏輯。然而從傳統應用遷移到 FaaS 在開發者體驗上還面臨諸多挑戰：

1. 環境不統一：各廠商定義的交付物格式，運行環境兼容性、豐富度都不盡相同，須要開發者適配，甚至從新編譯；

2. 學習成本：打包依賴庫、構建成壓縮代碼包和熟悉的開發部署方式不一樣；

3. 服務限制：如代碼包限制在百 MB 級別，迫使交付物代碼依賴分離，加大管理和發佈難度；

4. 交付物缺少版本管理：格式不標準，最佳實踐不統一，須要開發者自行負責；

5. 生態不成熟：缺乏流行開源工具（如 CI/CD 流水線）的支持和集成。

另外一方面，容器在可移植性和交付敏捷性上實現了顛覆式創新。圍繞容器的生態沉澱很是豐富且成熟，被普遍接受使用，應用容器化正在快速成爲開發和部署的事實標準。然而容器自己並無減輕運維、擴縮容、閒置成本、和雲服務集成等難題。

函數計算支持容器鏡像

阿里雲 FaaS 函數計算支持容器鏡像做爲函數交付物，將容器優秀的開發、部署、生態（上線前）結合函數計算自身免運維、零閒置成本、雲服務集成等特性（上線後），全面升級開發者體驗：

• 簡化應用 Serverless 化：無需修改代碼或是從新編譯二進制、共享對象（*.so），本地調試，保持開發和線上環境一致；

• 更大函數代碼限制：解壓前鏡像最大支持 1 GB（相比代碼包最大解壓前 50MB），避免代碼和依賴分離，簡化分發和部署；

• 容器鏡像分層緩存：增量代碼上傳和拉取，提升開發效率和下降冷啓動延遲；

• 鏡像分享、複用：邏輯能夠移植、減小重複開發建設；

• 混合部署：同一應用 Serverfull (ECS, 容器 ACK)、Serverless (FC, ASK, SAE)，不一樣應用混合部署或同一應用不一樣服務間切流，達到性能一致、資源剛性交付、快速擴容、運維最小化的平衡；

• CI/CD：持續構建、集成測試、代碼上傳、存儲和標準的版本管理，豐富的開源生態 CI/CD 工具能夠複用。

典型客戶場景

1. 事件驅動音視頻處理

音視頻處理有流量波動較大、對計算資源彈性要求高、監聽視頻上傳事件以及依賴工做流和隊列等服務的特性，使得 FaaS 成爲自建音視頻業務上雲的首選。然而這類場景中最經常使用的軟件 ffmpeg 每每須要定製編譯知足不一樣的需求。編譯的二進制依賴編譯環境中的共享對象（*.so）和 glibc 等庫，與 FaaS 運行環境不兼容沒法運行。從新編譯不只帶來了額外工做，不一樣的依賴和版本也給業務穩定性帶來了挑戰。

以下圖示例，使用已有 Dockerfile 將轉碼邏輯以及相關依賴保持現有的安裝方式和徹底隔離的容器沙箱運行環境，極大下降遷移成本，穩定性風險和 FaaS 的開發部署學習成本。

2. 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% 資源利用率進一步優化了服務質量和成本。

3. 傳統 Web 單體 HTTP 應用 Serverless 演進

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

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

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

企業上雲的節奏在不斷加快，然而因爲業務特性，私有云和公共雲混合的運行方式將是將來至關長一段時間內做爲常態。企業甚至須要多雲廠商來保證遷移、容災、資源剛性交付的需求。容器鏡像是雲上、雲下的軟件交付物統一的默認選擇。

函數計算自定義 runtime 選擇 HTTP server 標準的交互方式，函數代碼編程方式不與廠商綁定，減輕企業對雲廠商鎖定（vendor-lockin）的顧慮，在雲上能夠運行的函數，在雲下甚至其餘雲廠商一樣能夠做爲獨立的 HTTP Web 應用單獨部署，服務請求。容器打包的函數能夠運行在其餘雲服務的容器服務或 IaaS 自建服務，實現多雲的容災、彈性資源保障。

冷啓動最佳實踐

• 容器鏡像地址推薦使用與函數計算同地域的 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 和容器技術的聯繫將會變得更加緊密，開發部署運維差別不斷縮小，讓開發者幾乎不須要修改業務邏輯即能爲不一樣的工做負載選擇合適的技術方案，用開放、標準、統一的雲原生技術持續創新，爲客戶創造更多價值。