无码人妻丰满熟妇,扒开胸罩疯狂揉搓奶头,黄色香视频

背景

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

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

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

Serverless 計算

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

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

什么是并發(fā)？

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

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

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

單實例單并發(fā)

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

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

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

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

FaaS scaling and concurrency

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

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

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

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

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

虛擬化級別安全隔離

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

函數(shù)實例網絡訪問受限，用戶決定網絡外訪權限

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

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

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

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

FaaS 簡略概覽

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

嚴重的資源浪費

IO-intensive workload[11]

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

FaaS IO-intensive workload

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

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

FaaS with DB

單實例多并發(fā)

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

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

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

Google Cloud Run IO-Intensive workload

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

Google Cloud Run With DB

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

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

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

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

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

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

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

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

結論

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

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

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

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

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

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