作者 | changshuai

FaaS 的門檻

Serverless 形態(tài)的云服務(wù)幫助開發(fā)者承擔(dān)了大量復(fù)雜的擴(kuò)縮容、運(yùn)維、容量規(guī)劃、云產(chǎn)品打通集成等責(zé)任，使得開發(fā)者可以專注業(yè)務(wù)邏輯、提高交付速度 (Time-to-market) ，持續(xù)優(yōu)化成本。Function-as-a-Service (FaaS) 作為云上最早也是應(yīng)用最廣泛的 Serverless 計(jì)算形態(tài)，在幾年的時(shí)間內(nèi)吸引了大批開發(fā)者，逐漸建立了 Serverless 優(yōu)先的選型邏輯。然而從傳統(tǒng)應(yīng)用遷移到 FaaS 在開發(fā)者體驗(yàn)上還面臨諸多挑戰(zhàn)：

環(huán)境不統(tǒng)一：各廠商定義的交付物格式，運(yùn)行環(huán)境兼容性、豐富度都不盡相同，需要開發(fā)者適配，甚至重新編譯；

學(xué)習(xí)成本：打包依賴庫、構(gòu)建成壓縮代碼包和熟悉的開發(fā)部署方式不同；

服務(wù)限制：如代碼包限制在百 MB 級(jí)別，迫使交付物代碼依賴分離，加大管理和發(fā)布難度；

交付物缺乏版本管理：格式不標(biāo)準(zhǔn)，最佳實(shí)踐不統(tǒng)一，需要開發(fā)者自行負(fù)責(zé)；

生態(tài)不成熟：缺少流行開源工具（如 CI/CD 流水線）的支持和集成。

另一方面，容器在可移植性和交付敏捷性上實(shí)現(xiàn)了顛覆式創(chuàng)新。圍繞容器的生態(tài)沉淀非常豐富且成熟，被廣泛接受使用，應(yīng)用容器化正在快速成為開發(fā)和部署的事實(shí)標(biāo)準(zhǔn)。然而容器本身并沒有減輕運(yùn)維、擴(kuò)縮容、閑置成本、和云服務(wù)集成等難題。

函數(shù)計(jì)算支持容器鏡像

阿里云 FaaS 函數(shù)計(jì)算支持容器鏡像作為函數(shù)交付物，將容器優(yōu)秀的開發(fā)、部署、生態(tài)（上線前）結(jié)合函數(shù)計(jì)算自身免運(yùn)維、零閑置成本、云服務(wù)集成等特性（上線后），全面升級(jí)開發(fā)者體驗(yàn)：

簡化應(yīng)用 Serverless 化：無需修改代碼或是重新編譯二進(jìn)制、共享對(duì)象（*.so），本地調(diào)試，保持開發(fā)和線上環(huán)境一致；

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

容器鏡像分層緩存：增量代碼上傳和拉取，提高開發(fā)效率和降低冷啟動(dòng)延遲；

鏡像分享、復(fù)用：邏輯可以移植、減少重復(fù)開發(fā)建設(shè)；

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

CI/CD：持續(xù)構(gòu)建、集成測(cè)試、代碼上傳、存儲(chǔ)和標(biāo)準(zhǔn)的版本管理，豐富的開源生態(tài) CI/CD 工具可以復(fù)用。

典型客戶場(chǎng)景

1. 事件驅(qū)動(dòng)音視頻處理

音視頻處理有流量波動(dòng)較大、對(duì)計(jì)算資源彈性要求高、監(jiān)聽視頻上傳事件以及依賴工作流和隊(duì)列等服務(wù)的特性，使得 FaaS 成為自建音視頻業(yè)務(wù)上云的首選。然而這類場(chǎng)景中最常用的軟件 ffmpeg 往往需要定制編譯滿足不同的需求。編譯的二進(jìn)制依賴編譯環(huán)境中的共享對(duì)象（*.so）和 glibc 等庫，與 FaaS 運(yùn)行環(huán)境不兼容無法運(yùn)行。重新編譯不僅帶來了額外工作，不同的依賴和版本也給業(yè)務(wù)穩(wěn)定性帶來了挑戰(zhàn)。

使用已有 Dockerfile 將轉(zhuǎn)碼邏輯以及相關(guān)依賴保持現(xiàn)有的安裝方式和完全隔離的容器沙箱運(yùn)行環(huán)境，極大降低遷移成本，穩(wěn)定性風(fēng)險(xiǎn)和 FaaS 的開發(fā)部署學(xué)習(xí)成本。

2. Serverless AI/ML 模型預(yù)測(cè)、推理 serving

AI/ML 推理預(yù)測(cè)服務(wù)同樣可以享受 FaaS 免運(yùn)維、自動(dòng)伸縮、低成本的好處。然而社區(qū)流行的框架如 TensorFlow 都默認(rèn)以容器鏡像的方式分享和復(fù)用。不僅官方提供了完整的版本覆蓋，基于官方鏡像的社區(qū)生態(tài)也非?；钴S。

在離線模型訓(xùn)練階段以容器鏡像部署在 ECS 或 ACK/ASK GPU 集群。在服務(wù)推理/預(yù)測(cè)（serving inference/prediction）階段，CPU 往往是性價(jià)比更高的選擇。Serving 的特點(diǎn)是請(qǐng)求量驅(qū)動(dòng)，既需要能快速響應(yīng)突發(fā)（burst）流量，又要在波谷周期釋放資源，甚至是縮容至0節(jié)省成本。而這些需求天然就是函數(shù)計(jì)算所擅長的。

在沒有容器鏡像支持之前，想要將一個(gè) TensoflowFlow serving 的示例部署在函數(shù)計(jì)算上并不容易。TensorFlow 本身的庫大小遠(yuǎn)超過代碼包 50MB 的限制，將依賴打包進(jìn) NAS 可以繞過這個(gè)問題，然而卻增大了上手和遷移的難度。不規(guī)范的依賴和版本管理也為變更引入穩(wěn)定性風(fēng)險(xiǎn)。而使用容器鏡像以及函數(shù)計(jì)算 HTTP server 的編程模型，簡單的幾行 Dockerfile 就可以在 FC 跑起來 Tensorflow Serving 的示例：

函數(shù)計(jì)算支持容器鏡像幫助 AI/ML 場(chǎng)景平滑地混合部署容器和函數(shù)，統(tǒng)一 CICD 工具、流程和最佳實(shí)踐。函數(shù)計(jì)算免運(yùn)維、高并發(fā)、百毫秒級(jí)別的實(shí)例擴(kuò)容和 100% 資源利用率進(jìn)一步優(yōu)化了服務(wù)質(zhì)量和成本。

3. 傳統(tǒng) Web 單體 HTTP 應(yīng)用 Serverless 演進(jìn)

傳統(tǒng) Web 單體 (monolithic) 應(yīng)用現(xiàn)代化有三個(gè)主要的訴求：責(zé)任拆分、減輕運(yùn)維壓力（資源規(guī)劃、系統(tǒng)升級(jí)、安全補(bǔ)丁等運(yùn)維負(fù)擔(dān)）以及成本優(yōu)化。雖然采用職責(zé)單一的函數(shù)是一種最佳實(shí)踐，但是進(jìn)行職責(zé)拆分往往需要更長時(shí)間的設(shè)計(jì)和重構(gòu)。借助函數(shù)計(jì)算的鏡像支持能力，單體應(yīng)用可以很容易的遷移至 FaaS 服務(wù)以滿足免運(yùn)維，彈性水平擴(kuò)展和100%成本效率的訴求。

傳統(tǒng) Web 應(yīng)用由于歷史原因或者業(yè)務(wù)復(fù)雜度，運(yùn)行環(huán)境（容器鏡像）和業(yè)務(wù)邏輯往往高度耦合且解耦代價(jià)較高。為了 Serverless 化改造有時(shí)不得不升級(jí)操作系統(tǒng)及依賴庫版本，在 FaaS 廠商提供的環(huán)境中重新編譯。遷移至 Serverless 架構(gòu)有時(shí)間成本和穩(wěn)定性風(fēng)險(xiǎn)。函數(shù)計(jì)算對(duì)容器鏡像的支持幫助傳統(tǒng)容器化 Web 應(yīng)用無改造，更快地享受 Serverless 的價(jià)值，將時(shí)間和精力專注于業(yè)務(wù)邏輯創(chuàng)新和迭代而非重復(fù)枯燥的環(huán)境、依賴版本管理、升級(jí)維護(hù)和容量規(guī)劃和伸縮。

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

企業(yè)上云的節(jié)奏在不斷加快，然而由于業(yè)務(wù)特性，私有云和公共云混合的運(yùn)行方式將是未來相當(dāng)長一段時(shí)間內(nèi)作為常態(tài)。企業(yè)甚至需要多云廠商來保證遷移、容災(zāi)、資源剛性交付的需求。容器鏡像是云上、云下的軟件交付物統(tǒng)一的默認(rèn)選擇。

函數(shù)計(jì)算自定義 runtime 選擇 HTTP server 標(biāo)準(zhǔn)的交互方式，函數(shù)代碼編程方式不與廠商綁定，減輕企業(yè)對(duì)云廠商鎖定（vendor-lockin）的顧慮，在云上可以運(yùn)行的函數(shù)，在云下甚至其他云廠商同樣可以作為獨(dú)立的 HTTP Web 應(yīng)用單獨(dú)部署，服務(wù)請(qǐng)求。容器打包的函數(shù)可以運(yùn)行在其他云服務(wù)的容器服務(wù)或 IaaS 自建服務(wù)，實(shí)現(xiàn)多云的容災(zāi)、彈性資源保障。

冷啟動(dòng)最佳實(shí)踐

容器鏡像地址推薦使用與函數(shù)計(jì)算同地域的 VPC 鏡像地址，例如 registry-vpc.cn-hangzhou.aliyuncs.com/fc-demo/helloworld:v1beta1, 以獲得最優(yōu)的鏡像拉取延時(shí)和穩(wěn)定性；

鏡像最小化，使用類似 docker-slim 工具僅保存必要的依賴和代碼，避免不需要的文檔、數(shù)據(jù)或其他文件造成的額外延遲；

在資源允許和線程安全的情況下，搭配單實(shí)例多并發(fā)一同使用，可避免不必要的冷啟動(dòng)，同時(shí)降低成本；

容器鏡像配合預(yù)留實(shí)例一起使用，消除冷啟動(dòng)。

DevOps/GitOps 最佳實(shí)踐

容器鏡像的支持標(biāo)準(zhǔn)化了構(gòu)建步驟和函數(shù)交付產(chǎn)物，讓復(fù)用 CI/CD 工具成為可能。函數(shù)計(jì)算與阿里云云效DevOps 服務(wù)集成，推出了 CI/CD 流水線。

當(dāng)有新的代碼被 push 進(jìn)入代碼倉庫（Github/Gitlab） master 分支, 構(gòu)建流水線任務(wù)被開啟，按照代碼中指定的 Dockerfile, 容器鏡像會(huì)被構(gòu)建并推送至阿里云容器鏡像服務(wù)。流水線的最后一個(gè)步驟會(huì)部署發(fā)布新版本的函數(shù)，完成一次自動(dòng)化的發(fā)布。

除了云效 DevOps 完整自動(dòng)化的持續(xù)集成交付體驗(yàn)，阿里云容器鏡像服務(wù)和自建開源 CICD 流水線也同樣可以用方自動(dòng)化函數(shù)發(fā)布。函數(shù)計(jì)算發(fā)布方式的標(biāo)準(zhǔn)化使得企業(yè)可以用統(tǒng)一的工具持續(xù)交付多個(gè)不同的服務(wù)，降低開發(fā)運(yùn)維人員對(duì)部署工具的學(xué)習(xí)成本，自動(dòng)化部署提高成功率和交付速度 (time-to-market)。

和 Custom Runtime 的異同

函數(shù)計(jì)算在 2019 年推出了的自定義運(yùn)行時(shí)Custom runtime，那么這次發(fā)布的自定義容器（custom-container）和已有的運(yùn)行時(shí)有和異同呢？

相同的編程模型和函數(shù)計(jì)算系統(tǒng)的交互方式：完全相同的 HTTP server 協(xié)議，已有的 custom runtime 函數(shù)可以直接移植到環(huán)境兼容的自定義容器環(huán)境中，不需要修改代碼；

兩個(gè) runtime 有不同的適用場(chǎng)景和取舍：

對(duì)于非容器化的應(yīng)用，您可以持續(xù)使用 custom runtime；

對(duì)于冷啟動(dòng)延遲容忍度較低的場(chǎng)景，推薦您使用 custom runtime 節(jié)省鏡像拉取時(shí)間；

對(duì)于異步離線且已經(jīng)容器化的任務(wù)（job 類型），推薦您使用 cutome-container runtime；

使用函數(shù)計(jì)算預(yù)留實(shí)例，且部署環(huán)境和業(yè)務(wù)邏輯耦合緊密的應(yīng)用可以優(yōu)先考慮使用 custom-container runtime。

未來規(guī)劃

隨著容器逐漸成為應(yīng)用交付部署的標(biāo)準(zhǔn)方式，F(xiàn)aaS 會(huì)和容器生態(tài)做更緊密的融合，幫助容器化的應(yīng)用以更低的成本 Serverless 化，包括周邊配套生態(tài)例如聲明式的部署方式的融合，同 K8s 相似的應(yīng)用抽象，云原生可觀測(cè)性軟件集成?；谌萜麋R像拉取加速，讓函數(shù)計(jì)算能兼顧可移植和快速啟動(dòng)的性能。

容器技術(shù)和 Serverless 的初心都是要幫助用戶更快地交付（time-to-market）和持續(xù)優(yōu)化成本，消除資源閑置產(chǎn)生的浪費(fèi)，增加企業(yè)競(jìng)爭力。

最終云原生的兩大技術(shù)領(lǐng)域：Serverless 和容器技術(shù)的聯(lián)系將會(huì)變得更加緊密，開發(fā)部署運(yùn)維差異不斷縮小，讓開發(fā)者幾乎不需要修改業(yè)務(wù)邏輯即能為不同的工作負(fù)載選擇合適的技術(shù)方案，用開放、標(biāo)準(zhǔn)、統(tǒng)一的云原生技術(shù)持續(xù)創(chuàng)新，為客戶創(chuàng)造更多價(jià)值。

審核編輯 黃昊宇