伯克利論斷：Serverless 才是雲時代的主宰

編者按：

來自伯克利的犀利斷言：Serverless 計算將會成為雲時代預設的計算正規化，將會取代 Serverful （傳統雲）計算模式，因此也意味著伺服器-客戶端模式的終結。

你準備好了嗎？

引言

2009年，伯克利以獨特的視角釋出了一篇文獻，定義了雲端計算，十年過去了，這篇文章被引用無數，其中的觀點更是當下最好的見證：

1. 按需計算的表現形式。
2. 消除雲使用者的前期承諾。
3. 根據需要在短期內支付使用計算資源的能力。
4. 規模經濟，由於許多非常大的資料中心，顯著降低了成本。
5. 通過資源虛擬化簡化操作並提高利用率。
6. 通過多路複用來承載不同組織的工作負載，進而提高硬體利用率。

2019年，伯克利又以新的視角釋出了一篇文獻：將雲中的程式設計變得簡單：伯克利視角下的Serverless 計算。 觀點同樣讓人眼前一亮：

Serverless 所提供的介面，簡化了雲端計算的程式設計，其代表了程式設計師生產力的又一次的變革，一如程式語言從彙編時代演變為高階語言時代。

因為Serverless 和傳統的雲端計算有著本質的區別：

1. 計算和儲存的解耦，彼此獨立擴充套件和定價。
2. 將執行的程式碼作為執行的物件，而屏棄了分配該段程式碼所執行的資源。
3. 程式碼成為明碼標價的物件，而不再是執行程式碼所需要的資源。

如果各位看官和我一樣，對於伯克利視角下的Serverless好奇的話，不妨跟隨我接下來以問答的方式來解讀一下這篇文獻：

資料中心即計算機。 —— Luiz Barroso（2007）

Serverless 計算的最佳理解是？

在任何的 Serverless 平臺，使用者只需要使用高階語言撰寫使用雲功能，然後以事件來觸發執行即可，如將圖片上傳到雲端儲存中、將影像縮圖插入到資料庫表中，而所有的傳統的操作：例項選擇、例項擴充套件、部署、容錯、監控、日誌、安全補丁等等，均由Serverless計算的來掌控。

Serverless 計算和傳統的雲端計算（serverful）有何區別？

相對於Serverless 計算，傳統意義上的雲端計算已經成為了 Serverful 計算了，以下列表從開發者和系統管理員的角度分別對比了他們二者之間的區別：

	特性	AWS Serverless 雲端計算	AWS Serverful 雲端計算
程式設計師	何時執行程式	由雲使用者根據事件自行選擇	除非明確停止，否則會一直執行。
	程式語言	JavaScript、Python、Java、Go等有限的語言	任何語言
	程式狀態	儲存在儲存（無狀態）	任何地方（有狀態或無狀態）
	最大記憶體大小	0.125~3GiB（雲使用者自行選擇）	0.5~1952GiB（雲使用者自行選擇）
	最大本地儲存	0.5GiB	0~3600 GiB （雲使用者自行選擇）
	最長執行時間	900秒	隨意
	最小計費單元	0.1秒	60秒
	每計費單元價格	$0.0000002	$0.0000867 - $0.4080000
	作業系統和庫	雲供應商選擇	雲使用者自行選擇
系統管理員	伺服器例項	雲供應商選擇	雲使用者自行選擇
	擴充套件	雲供應商負責提供	雲使用者自己負責
	部署	雲供應商負責提供	雲使用者自己負責
	容錯	雲供應商負責提供	雲使用者自己負責
	監控	雲供應商負責提供	雲使用者自己負責
	日誌	雲供應商負責提供	雲使用者自己負責

基於雲環境的描述下，Serverful 計算猶如傳統底層的程式語言，如彙編程式；而Serverless 計算猶如高階的程式語言，如Python。前者開發者需要考慮每一個細節，到CPU 暫存器這樣一個級別，而後者開發者只需要考慮要實現的功能即可。

Serverless 之所以成為可能的基礎條件有哪些？

1. Serverless 計算是在PaaS和原來模式的之上的重要創新。
2. 基於VM的隔離技術，如Firecracker 、gVisor等技術的成熟。
3. 允許雲使用者攜帶執行程式所需要的庫。
4. BaaS 的發展，如物件儲存的不斷完善。
5. 容器技術、Kubernetes 專案的崛起。
6. 邊緣計算的迅猛發展需求

伯克利對 Serverless 的大膽預言是什麼？

Serverless 將會在接下來的十年，迅速的被採用，將會得到飛速的發展。

• 新的BaaS儲存服務會被發明，以擴充套件在 Serverless 計算上能夠執行更加適配的應用程式型別。 這樣的儲存能夠與本地塊儲存的效能相匹配，而且具有臨時和持久可供選擇。
• 比現有的 x86 微處理器更多的異構計算機。
• 更加安全、易用的程式設計，不僅具有高階語言的抽象能力，還有很好的細粒度的隔離性。
• 基於Serverless 計算的價格將低於Serverful計算，至少不會高於Serverful計算。
• Serverless 將會接入更多的後臺支撐服務，如OLTP 資料庫、訊息佇列服務等。
• Serverless 計算一旦取得技術上的突破，將會導致Serverful服務的下滑。
• Serverless 將會成為雲時代預設的計算正規化，將會取代 Serverful 計算，因此也意味著伺服器-客戶端模式的終結。

Serverless 計算的軟體棧架構概覽

Serverless 介於基礎雲平臺和應用程式之間，旨在簡化基於雲的程式設計開發，Cloud Functions （通常稱之為FaaS）提供通用的計算，輔以專門的後端即服務（BaaS）等生態系統，如物件儲存、Key-Value 資料庫等。

Serverless 目前應用的場景如何？

來自2018年的一個調查顯示：

百分比	使用者場景
32%	web 和 API 服務
21%	資料處理，如批處理的ETL
17%	整個第三方的服務
16%	內部 tooling
8%	聊天機器人，如 Alexa Skills（Alexa AI 助手 SDK）
6%	物聯網

對五類典型應用的深度分析：

應用程式	描述	挑戰	解決辦法	花銷比較
實時視訊壓縮（ExCamera）	扔到雲中的視訊解碼	物件儲存太慢，無法支援細粒度的通訊; 功能太粗糙，無法完成任務。	功能對功能以避免物件儲存；以功能排程而不是任務。	比基於虛擬機器快60倍，但是錢只花了1/6。
MapReduce	大資料處理（100TB排序）	由於物件儲存延遲和IOPS限制，擴充套件成為問題	使用低延遲儲存，高IOPS	比虛擬機器快1%，節省15%的費用
線性代數計算（Numpy-wren)	大規模線性代數計算	物件儲存的低延遲、難以實現客戶端的廣播問題。	使用低延時高吞吐的物件儲存，	比原來慢了3個數量級，CPU的消耗降低1.26到2.5倍。
機器學習pipeline(Cirrus)	大規模的機器學習	缺乏快速的儲存，難以實現廣播、聚合問題。	使用低延遲儲存，高IOPS	比虛擬機器快3~5倍，比原來貴7倍
資料庫（Serverless SQLite）	應用程式的主要狀態（OLTP）	缺乏共享記憶體，物件儲存具有高延遲，缺乏對入站連線的支援。	如果寫入需求低，共享檔案系統可以工作。	TPC-C基準，要比原來的快3倍，讀取比例匹配但寫入不匹配。

對 Serverless 計算的期待？

1. 抽象層：更多的資源排程、增加資料依賴功能
2. 系統：高效能、經濟實惠、透明配置的儲存，最小化啟動時間，協調服務
3. 網路：實現更高吞吐量的通訊
4. 安全：隨機的排程、物理隔離、細粒度的安全上下文、
5. 體系結構：異構性、價格下調、更方便的管理

Serverless 計算目前有被人們吐槽的地方？

在分析了五大典型（實時視訊解碼、MapReduce、大規模線性代數計算、機器學習訓練、資料庫）應用案例之後，得出如下幾個結論：

1. 儲存空間不足以進行細粒度操作
2. 缺乏細粒度的協調
3. 標準通訊模式的效能不佳
4. 啟動的延遲性

是什麼吸引著大家去追求 Serverless 計算方式？

對於雲使用者來說：

1. 不需要任何的操作雲基礎設施、部署等知識，關注功能即可
2. 更加容易編寫應用程式是最主要的動力
3. 更短的執行時間，毋須關心記憶體的大小，無狀態的天然特性
4. 省錢

對於雲提供商來說：

1. 減少對X86 伺服器的採用，可有效節省成本。
2. 對計算新的抽象，意味著未來的無限可能性

謬誤和陷阱

本章是向 Hennessy and Patterson 二位的風格致敬。鑑於本文只是讀論文的解讀，所以不會翻譯所有的內容，這裡僅拋磚引玉，講述兩個非常有趣的答覆：

謬誤 ：Cloud Functions 無法處理需要可預測效能的極低延遲應用程式。

Serverful 計算，即伺服器例項對於低延遲應用程式的處理，是它們始終處於啟動狀態，因此它們可以在收到請求時快速回復請求。 那麼，照葫蘆畫瓢，如果 Cloud Functions 的啟動延遲對於給定的應用程式來說不夠好，可以使用類似的策略：通過定期執行它們來Cloud Functions 進行預熱，從而確保在任何給定時間都能夠及時的響應，進而滿足傳入的請求。

陷阱：Serverless 計算會導致無法預料的成本

這種純粹意義上按程式碼執行付費的模式，其實是大家對於這樣新的計費模式的不適應罷了，尤其是大型公司的預算考慮，相信隨著時間的推移，一旦人們瞭解了自己的業務以及有了一些歷史資料之後，就會適應這樣的計算模式的，一如對於如電力這樣的計費模式。

筆者能力所限，加上論文論斷式的風格，最後強烈建議各位看官請移步伯克利網站下載論文，進行進一步的深度閱讀！尤其是引用的材料。

論文連結：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf