背景

2019 年 Berkeley 預(yù)測 Serverless 將取代 Serverful 計算[1]，成為云計算的計算新范式。Serverless 為應(yīng)用程序開發(fā)提供了一種全新的系統(tǒng)架構(gòu)，其憑借著彈性伸縮省事省心，按需付費更低成本、聚焦業(yè)務(wù)降低 OPS 這三大核心價值，將開發(fā)人員從繁重的手動資源管理和性能成本優(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è)計。

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

Serverless 計算

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

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

什么是并發(fā)？

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

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

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

單實例單并發(fā)

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

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

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

Tips:只有綠色部分是毫秒計費，黃色和空白部分均不會計費，真正 100% 為計算資源付費。

FaaS scaling and concurrency

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

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

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

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

阿里云 FC 計算節(jié)點安全隔離

虛擬化級別安全隔離

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

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

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

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

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

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

FaaS 簡略概覽

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

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

IO-intensive workload[11]

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

FaaS IO-intensive workload

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

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

FaaS with DB

單實例多并發(fā)

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

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

IO 等待期間不再是資源浪費

Google Cloud Run IO-Intensive workload

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

Google Cloud Run With DB

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

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

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

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

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

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

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

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

結(jié)論

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

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

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

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

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

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

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

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

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

審核編輯：劉清