背景

2019 年 Berkeley 預(yù)測 Serverless 將取代 Serverful 計(jì)算[1]，成為云計(jì)算的計(jì)算新范式。Serverless 為應(yīng)用程序開發(fā)提供了一種全新的系統(tǒng)架構(gòu)，其憑借著彈性伸縮省事省心，按需付費(fèi)更低成本、聚焦業(yè)務(wù)降低 OPS 這三大核心價(jià)值，將開發(fā)人員從繁重的手動(dòng)資源管理和性能成本優(yōu)化中解放出來，讓工程師的生產(chǎn)力再次發(fā)生變革。

從上面的定義可以看出， Severless != No Server， 只是對于開發(fā)者來說，沒有了 Server 去管理。而在云廠商提供的服務(wù)中，Serverless 架構(gòu)應(yīng)該是采用 FaaS（Function as a service，函數(shù)即服務(wù)）和 BaaS（后端服務(wù)）服務(wù)來解決問題的一種設(shè)計(jì)。

FaaS 服務(wù)的典型代表：AWS lambda、阿里云函數(shù)計(jì)算 FC、Azure Functions、Google Cloud Functions 等。BaaS 服務(wù)典型代表：AWS: S3、Dynamodb、SQS 等；阿里云：OSS、 TableStore、MNS 等。

Serverless 計(jì)算

當(dāng)然隨著需求和技術(shù)的發(fā)展，業(yè)界出現(xiàn)了一些 FaaS 以外的其它形態(tài)的 Serverless 計(jì)算服務(wù)，比如 Google Cloud Run、AWS App Runner、阿里云 Serverless 應(yīng)用引擎 SAE、 阿里云 Serverless Kubernetes ASK 等，這些服務(wù)也提供了彈性伸縮能力和按使用計(jì)費(fèi)的收費(fèi)模式，具備 Serverless 服務(wù)的形態(tài)，可以說進(jìn)一步擴(kuò)大了 Serverless 計(jì)算的陣營。

而在 Serverless 計(jì)算領(lǐng)域最典型的兩種產(chǎn)品形態(tài)代表 FaaS 和 Google Cloud Run, 都不約而同采用了并發(fā)度（Concurrency）這個(gè)指標(biāo)作為擴(kuò)縮容策略。接下來我們重點(diǎn)剖析下不同產(chǎn)品形態(tài)下并發(fā)的語義以及為什么這些流行的 Serverless 計(jì)算產(chǎn)品為什么采用并發(fā)度作為擴(kuò)縮容的策略。

什么是并發(fā)？

并發(fā)是現(xiàn)代計(jì)算的核心原則之一， 并發(fā)是指計(jì)算系統(tǒng)同時(shí)處理多個(gè)任務(wù)的能力。例如，如果您的計(jì)算機(jī)同時(shí)運(yùn)行多個(gè)程序，則具有多個(gè)并發(fā)進(jìn)程 / 線程可以共享 CPU 時(shí)間。如果單個(gè)應(yīng)用程序進(jìn)程同時(shí)處理多個(gè)網(wǎng)絡(luò)請求，或者并行處理隊(duì)列中的多個(gè)作業(yè)，則也可以認(rèn)為該應(yīng)用程序正在執(zhí)行并發(fā)工作。

比如 “世界第一語言 PHP” 在 Web 領(lǐng)域的實(shí)踐，使用就是進(jìn)程池，如下圖中的 FastCGI 進(jìn)程管理器。發(fā)送到服務(wù)器的 Web 請求將被分配給進(jìn)程池中的 CGI 進(jìn)程。該 CGI 進(jìn)程將處理該單個(gè)請求。如果同時(shí)收到多個(gè)請求，則將啟動(dòng)多個(gè) CGI 進(jìn)程并行處理它們。然而，每個(gè)進(jìn)程一次只能處理一個(gè)請求。服務(wù)器能夠通過對 CGI 進(jìn)程進(jìn)行上下文切換來處理并發(fā)請求。操作系統(tǒng)調(diào)度程序?qū)⒏櫵?CGI 進(jìn)程，并在需要時(shí)切換正在 CPU 上運(yùn)行的 CGI 進(jìn)程，以使每個(gè) CGI 進(jìn)程在需要時(shí)都能獲得屬于自己的、公平的 CPU 時(shí)間份額。

如今，有更多用于并發(fā)的工具， 這包括現(xiàn)代編程語言內(nèi)置的強(qiáng)大異步并發(fā)機(jī)制，以及幫助簡化并發(fā)的云計(jì)算服務(wù)。讓我們看看一些云計(jì)算服務(wù)如何設(shè)計(jì)和使用并發(fā)。

單實(shí)例單并發(fā)

云廠商的 FaaS 服務(wù)的并發(fā)擴(kuò)縮容原理基本大同小異， 我們以 AWS Lambda 官方文檔[3] 為參考：

當(dāng)首次調(diào)用一個(gè)函數(shù)時(shí)，F(xiàn)aaS 服務(wù)會(huì)創(chuàng)建一個(gè)函數(shù)實(shí)例，并運(yùn)行處理程序方法以處理事件。完成后，函數(shù)會(huì)在一段時(shí)間內(nèi)保持可用狀態(tài)，以處理后續(xù)的事件。如果在函數(shù)忙碌時(shí)有其他事件到達(dá)，F(xiàn)aaS 會(huì)創(chuàng)建更多的函數(shù)實(shí)例來同時(shí)處理這些請求。

從文檔中我們可以看出，每個(gè)函數(shù)實(shí)例一次只能處理一個(gè)事件請求（即 one concurrent request per instance，也稱為單實(shí)例單并發(fā)）。在處理事件請求時(shí)，函數(shù)被認(rèn)為是繁忙的，因此任何并發(fā)事件都必須轉(zhuǎn)到另一個(gè)函數(shù)實(shí)例。每次必須創(chuàng)建函數(shù)的新實(shí)例時(shí)，都會(huì)出現(xiàn)短暫的 “冷啟動(dòng)”(Cold Start) 延遲。這個(gè)冷啟動(dòng)的持續(xù)時(shí)間取決于您的代碼大小和使用的運(yùn)行時(shí) Runtime。下圖[4]顯示了當(dāng)有多個(gè)并發(fā)請求需要進(jìn)行并行處理時(shí)，F(xiàn)aaS 如何實(shí)時(shí)擴(kuò)展函數(shù)實(shí)例的數(shù)量：

Tips:只有綠色部分是毫秒計(jì)費(fèi)，黃色和空白部分均不會(huì)計(jì)費(fèi)，真正 100% 為計(jì)算資源付費(fèi)。

FaaS scaling and concurrency

這使得 FaaS 的并發(fā)模型在某些方面類似于那些老式的 PHP 進(jìn)程管理器。在這兩種情況下：1). PHP 進(jìn)程管理器通過并行啟動(dòng)更多進(jìn)程來實(shí)現(xiàn)并發(fā)。單個(gè)進(jìn)程一次只能處理一個(gè)事件請求。2). FaaS 通過并行啟動(dòng)更多的執(zhí)行環(huán)境容器實(shí)例來實(shí)現(xiàn)并發(fā)， 單個(gè)實(shí)例一次只能處理一個(gè)事件請求。但使用 PHP 進(jìn)程管理器那樣的進(jìn)程級別的并發(fā)有兩個(gè)經(jīng)典難題需要解決：

進(jìn)程之間的安全隔離：您必須在操作系統(tǒng)分配 CPU 時(shí)間和系統(tǒng)資源給進(jìn)程時(shí)做出正確的決策。一個(gè)進(jìn)程可能會(huì)消耗過多的資源，影響在同一臺(tái)機(jī)器上運(yùn)行的其他進(jìn)程的性能。

自動(dòng)擴(kuò)縮容：以 PHP 應(yīng)用程序?yàn)槔?，您必須管理每個(gè)服務(wù)器上的 PHP CGI 進(jìn)程數(shù)量，并且必須對運(yùn)行這些進(jìn)程的服務(wù)器數(shù)量進(jìn)行手動(dòng)擴(kuò)縮容。

FaaS 能很好解決上述兩個(gè)難題，F(xiàn)aaS 明顯有一些現(xiàn)代化的特點(diǎn)，以函數(shù)計(jì)算執(zhí)行環(huán)境容器的安全隔離為例[5]:

阿里云 FC 計(jì)算節(jié)點(diǎn)安全隔離

虛擬化級別安全隔離

神龍裸金屬計(jì)算節(jié)點(diǎn)可運(yùn)行來自不同用戶的函數(shù)實(shí)例，使用阿里云安全沙箱[13]提供函數(shù)級別虛擬化及容器隔離，ECS 虛擬機(jī)只允許運(yùn)行同用戶的函數(shù)實(shí)例，借助 ECS 隔離提供用戶級別虛擬化隔離，使用 Runc[14]等容器技術(shù)實(shí)現(xiàn)函數(shù)級別的容器隔離。

函數(shù)實(shí)例網(wǎng)絡(luò)訪問受限，用戶決定網(wǎng)絡(luò)外訪權(quán)限

函數(shù)實(shí)例配置私有 IP 地址，用戶不可直接訪問，且實(shí)例間網(wǎng)絡(luò)不可達(dá)，網(wǎng)絡(luò)隔離使用 open vSwitch、iptables 和 routing tables 實(shí)現(xiàn)。

函數(shù)實(shí)例資源受限函數(shù) CPU / 內(nèi)存設(shè)置的配額

函數(shù)計(jì)算負(fù)責(zé)函數(shù)實(shí)例沙箱容器的漏洞修復(fù)及安全升級

使用 FaaS 這種事件驅(qū)動(dòng)的全托管計(jì)算服務(wù)，您將自動(dòng)獲得隔離的執(zhí)行環(huán)境實(shí)例，F(xiàn)aaS 服務(wù)自動(dòng)管理執(zhí)行環(huán)境實(shí)例的數(shù)量和容量。您所要做的事情就是提供您的代碼到 FaaS 服務(wù)，并向 FaaS 服務(wù)發(fā)送事件以觸發(fā)該代碼執(zhí)行即可。

FaaS 簡略概覽

從上面對 FaaS 并發(fā)擴(kuò)縮容的討論中，相信大家很快 get 到單個(gè)實(shí)例一個(gè)并發(fā)的能力對 CPU 密集型的邏輯非常友好。而現(xiàn)代的許多工作負(fù)載都充滿了 I/O 操作，如果我們采用 FaaS 經(jīng)典的 one concurrent request per instance 模式，會(huì)有如下痛點(diǎn)問題：

嚴(yán)重的資源浪費(fèi)

IO-intensive workload[11]

藍(lán)色方框表示程序正在工作時(shí)的時(shí)間，紅色方框表示等待 IO 操作完成所花費(fèi)的時(shí)間。由于 IO 請求可能比 CPU 指令花費(fèi)的時(shí)間長幾個(gè)數(shù)量級，因此您的程序可能會(huì)花費(fèi)大部分時(shí)間等待， 實(shí)例資源浪費(fèi)嚴(yán)重。并且隨著并并發(fā)數(shù)目的變大，浪費(fèi)的資源也呈線性增長，如下面紅色部分即為浪費(fèi)的計(jì)算資源：

FaaS IO-intensive workload

2.可能會(huì)對共享資源造成意想不到的后果

數(shù)據(jù)庫是一個(gè)典型的例子。當(dāng)使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（如 mysql）時(shí)，數(shù)據(jù)庫有一個(gè)最大并發(fā)連接數(shù)。傳統(tǒng)常駐型服務(wù)器通常使用 “數(shù)據(jù)庫連接池” 進(jìn)行優(yōu)化。“數(shù)據(jù)庫連接池” 限制了單個(gè)服務(wù)器實(shí)例對數(shù)據(jù)庫的最大并發(fā)連接數(shù)，同時(shí)允許并發(fā)的請求能有效地共享 “數(shù)據(jù)庫連接池” 的連接。然而，如果每個(gè)實(shí)例只能處理一個(gè)請求并維持與數(shù)據(jù)庫的開放連接，則請求的數(shù)量與到數(shù)據(jù)庫的連接數(shù)之間存在一對一的關(guān)系。結(jié)果是在負(fù)載高峰期間，數(shù)據(jù)庫可能會(huì)因過多連接而打滿，并最終拒絕新連接。如果一個(gè)數(shù)據(jù)庫實(shí)例的最大連接數(shù)為 100，使用 FaaS， 示意圖如下：

FaaS with DB

單實(shí)例多并發(fā)

因此，就 FaaS 領(lǐng)域的 one concurrent request per instance 的痛點(diǎn)問題，Google Cloud Run 提供了 multi concurrent requests per instance 的能力[6]，這就很好解決我們上文討論的單實(shí)例單并發(fā)擴(kuò)縮容模型的痛點(diǎn)：

Google Cloud Run 單個(gè)實(shí)例默認(rèn)最大并發(fā)度 (即單個(gè)實(shí)例的并發(fā)請求數(shù)上限) 為 80，最大可調(diào)整到 1000。

IO 等待期間不再是資源浪費(fèi)

Google Cloud Run IO-Intensive workload

對共享資源造成影響可預(yù)期：提高數(shù)據(jù)庫連接吞吐

Google Cloud Run With DB

如果每個(gè)實(shí)例配置了數(shù)據(jù)庫連接池大小為 10，那么每個(gè)實(shí)例可以允許 10 個(gè)并行請求到數(shù)據(jù)庫。由于每個(gè)實(shí)例可能會(huì)接收高達(dá) 80 個(gè)并發(fā)請求，“數(shù)據(jù)庫連接池” 將在等待數(shù)據(jù)庫連接被釋放并返回到池中時(shí)，自動(dòng)阻止傳入的請求。通過使用 10 個(gè)數(shù)據(jù)庫連接響應(yīng) 80 個(gè)請求，理論上可以在數(shù)據(jù)庫達(dá)到其最大連接限制之前將數(shù)據(jù)庫的吞吐量提高 10 倍。

有趣的是，一些 FaaS 廠商勇敢做出了 multi concurrent requests per instance 的嘗試，比如阿里云函數(shù)計(jì)算設(shè)置實(shí)例并發(fā)度[15]，Google Cloud Functions 第 2 代也開始支持設(shè)置實(shí)例并發(fā)度[16]。旨在解決現(xiàn)代很重要的 IO 密集型工作負(fù)載問題。

為什么 Serverless 使用并發(fā)讀擴(kuò)縮容

FaaS 和 Google Cloud Run 采用實(shí)例并發(fā)度 (即實(shí)例的并發(fā)請求數(shù)上限) 這個(gè)指標(biāo)進(jìn)行擴(kuò)縮容，而不是采用 CPU 指標(biāo)等 HPA 策略，是因?yàn)樵?Serverless 領(lǐng)域，實(shí)例并發(fā)度是 “基于請求處理 / 事件驅(qū)動(dòng)進(jìn)行擴(kuò)縮容” 表達(dá)最好的一個(gè)方式。

FaaS 和 Google Cloud Run 都有實(shí)例縮至為 0 和有請求進(jìn)來可以拉起一個(gè)新實(shí)例的能力，在實(shí)例 0-1 過程中無法使用 CPU 或內(nèi)存等指標(biāo)進(jìn)行擴(kuò)容。

更好地匹配請求處理：并發(fā)度能夠更好地匹配實(shí)際請求的數(shù)量，因此可以更好地利用計(jì)算資源，同時(shí)確保請求能夠快速得到響應(yīng)。以阿里云函數(shù)計(jì)算和 K8S 做一個(gè)資源匹配請求速度的對比[7]:

更好的資源利用率：實(shí)例并發(fā)度策略可以更好地利用計(jì)算資源，可以在請求高峰期間快速擴(kuò)容，而在請求較少時(shí)保持最小的實(shí)例數(shù)量，從而減少資源浪費(fèi)。FaaS 和 Google Cloud Run 允許用戶運(yùn)行任何語言的代碼，并自動(dòng)擴(kuò)展以匹配流量：并發(fā)度總數(shù) = 同時(shí)處理請求的實(shí)例數(shù)量 *每個(gè)實(shí)例的最大并發(fā)請求數(shù)上限

當(dāng)然，引入的并發(fā)度的概念也給習(xí)慣了 CPU 指標(biāo)等擴(kuò)縮容的開發(fā)者帶來的新的疑惑， 對于 IO 密集型的應(yīng)用，基于 CPU 指標(biāo)的 HPA 擴(kuò)容策略很簡單就可以提高應(yīng)用程序的可用性、性能和可靠性，并使資源更高效地利用。反而單個(gè)實(shí)例的最大并發(fā)度的合理值怎么去設(shè)置是一個(gè)比較頭疼的問題？這個(gè)問題，業(yè)界通常都是建議您根據(jù)自己的負(fù)載情況做壓測迭代出合適的并發(fā)度值。阿里云函數(shù)計(jì)算為此做了一個(gè)業(yè)界最前沿的探索，提供了自動(dòng)化推薦能力：從青銅到王者，揭秘 Serverless 自動(dòng)化函數(shù)最佳配置[8][17], 并由此展望智能動(dòng)態(tài)并發(fā)度：在這種模式下，用戶不需要通過手動(dòng)配置參數(shù)，而是在函數(shù)運(yùn)行時(shí)動(dòng)態(tài)調(diào)整，根據(jù)實(shí)例 CPU 負(fù)載的健康指標(biāo)自動(dòng)調(diào)整到最佳值。

結(jié)論

基于上文對并發(fā)度的討論，對于單實(shí)例單并發(fā)（云產(chǎn)品代表 FaaS）和 單實(shí)例多并發(fā)（云產(chǎn)品代表 Google Cloud Run） 這兩種形態(tài)的 Serverless 產(chǎn)品， 我應(yīng)該選擇哪個(gè)產(chǎn)品來托管我的應(yīng)用程序呢？以下是一些情景是我個(gè)人會(huì)選擇哪種產(chǎn)品的建議：

但最終還是需要根據(jù)您具體的業(yè)務(wù)需求做取舍，選擇最合適的產(chǎn)品和方案。注：FaaS 中的函數(shù)計(jì)算 FC 和 Google Cloud Functions V2 也支持單實(shí)例多并發(fā)。

上述表格中的建議是基于阿里云函數(shù)計(jì)算應(yīng)用中心 [9] 中的用戶對于應(yīng)用的偏好部署次數(shù)【見下圖】以及客戶落地案例【見參考 [12]】來佐證的， 尤其對于每個(gè)請求必須相互隔離或者 CPU 密集型任務(wù)， FaaS 具有無與倫比的優(yōu)勢：

對于存量應(yīng)用，將 CPU 密集型任務(wù)從應(yīng)用中抽離出來，提升服務(wù)的穩(wěn)定性，這個(gè)文章 PDF Generation With AWS Lambda[10][18]深入討論了這種實(shí)踐的收益。

對于新業(yè)務(wù) CPU/GPU 密集型應(yīng)用， 如音視頻處理以及最近大火的大模型 AIGC (AI generated content ) 應(yīng)用， 是 FaaS 天然契合的場景 。

在 AI 場景中請求和后端資源的調(diào)度比傳統(tǒng)的微服務(wù)場景的要求會(huì)更高，主要原因是 AI 場景的請求對資源的消耗特別大。比如一個(gè) Stable Diffusion 使用 A10 GPU 卡部署，一塊 A10卡 (ecs.gn7i-c8g1.2xlarge)啟動(dòng) Stable Diffusion 服務(wù)一次只能處理個(gè)位數(shù)的文本繪圖請求。一旦同時(shí)進(jìn)來請求過多，就會(huì)出現(xiàn)計(jì)算資源競爭從而導(dǎo)致請求超時(shí)的情況。而 FaaS 的"one concurrent request per instance"天然契合這個(gè)場景，簡直就是絕配。

函數(shù)計(jì)算 FC 應(yīng)用中心文件處理應(yīng)用部署情況圖

函數(shù)計(jì)算 FC 應(yīng)用中心音視頻處理應(yīng)用部署情況圖

函數(shù)計(jì)算 FC 應(yīng)用中心 AI 應(yīng)用部署情況圖

審核編輯：劉清