伯克利研究員們眼中的 Serverless Computing

寫在前面

UC Berkeley 在 2019 年 2 月 10 日發布了一篇關於 Serverless 的論文，引發了業界這幾個月以來對 Serverless 的熱議。

伯克利研究員們認為 Serverless 幾乎可以處理所有系統管理操作，讓開發者更輕鬆地使用雲。能夠大大簡化雲編程，同時也標誌著一種類似於從彙編語言到高級編程語言的演變：

Serverless cloud computing handles virtually all the system administration operations needed to make it easier for programmers to use the cloud. It provides an interface that greatly simplifies cloud programming, and represents an evolution that parallels the transition from assembly language to high-level programming languages.

甚至認為Serverless 將主導雲計算的未來：

Just as the 2009 paper identified challenges for the cloud and predicted they would be addressed and that cloud use would accelerate, we predict these issues are solvable and that serverless computing will grow to dominate the future of cloud computing.

一.10 年前的 6 個預言

10 年前（2009 年 2 月 10 日），UC Berkeley 在一篇關於 Cloud Computing 的論文中指出了雲計算的 6 大潛在優勢：

• 能按需提供無限的計算資源

• 雲用戶無需預估資源

• 提供即用即付的短期計算資源

• 超大型數據中心形成的規模經濟將極大地降低成本

• 通過資源虛擬化簡化操作並提高利用率

• 通過多路復用來提高硬件利用率

P.S.關於這些預言的詳細信息，見 [伯克利研究員們眼中的 Cloud Computing](/articles/伯克利研究員們眼中的 cloud-computing/)

時至如今，這些優勢基本都實現了。但操作上的複雜性卻仍然困擾著雲用戶，多路復用的優勢也沒能完全發揮出來：

• 雲計算減輕了管理物理基礎設施的負擔，卻產生了大量同樣需要管理的虛擬資源

• 多路復用能在批處理的場景（比如 MapReduce 或高性能計算）大顯身手，而對於有狀態的服務（比如數據管理系統等企業應用）卻很難發揮作用

P.S.多路復用 是一種廣泛應用於通信領域的資源共享技術，包括分時復用（Time-division multiplexing）、分頻復用（Frequency-division multiplexing）等。

原因在於市場選擇了更低程度的資源抽象方式，雲用戶像使用物理硬件一樣控制整個資源棧，仍需考慮：

• 可用性冗餘（避免單點故障）

• 異地容災

• 負載均衡

• 彈性伸縮

• 監控

• 日誌（用於調試或性能診斷）

• 系統升級（安全補丁等）

• 可移植性（遷移到新實例）

二.Serverless Computing 登場

概念定義

意識到易用性方面的需求後，Amazon 在 2015 年推出了 AWS Lambda 服務，即雲函數（cloud functions），繼而引起了對*無服務器計算（serverless computing）*理念的廣泛關注：

Serverless suggests that the cloud user simply writes the code and leaves all the server provisioning and administration tasks to the cloud provider.

將服務器相關的配置管理工作統統交給雲供應商去做，以減輕用戶管理雲資源的負擔

因此，Serverless Computing 並不是說不需要 server 就能 computing，而是對用戶而言不必花很大精力去管理 server。同樣的，Serverless 服務能夠（自動）彈性伸縮，無需顯式預配資源，並且按使用情況計費。

另一方面，Serverless 還帶來了一種模式轉變——允許交由供應商全權操作，這讓細粒度的多租戶多路復用成為了可能：

Serverless computing, on the other hand, introduces a paradigm shift that allows fully offloading operational responsibilities to the provider, and makes possible fine-grained multi-tenant multiplexing.

Serverless 的核心是 FaaS（Function as a Service），但雲平台通常還提供 Serverless 框架來滿足 BaaS (Backend as a Service) 等特定應用程序要求。因此，可以簡單理解為：

Serverless computing = FaaS + BaaS

基本架構

Serverless 層處於應用層和基礎雲平台層之間，用來簡化雲編程：

[caption id="attachment_2050" align="alignnone" width="625"] Architecture of the serverless cloud[/caption]

其中，雲函數（Cloud functions，比如 FaaS）提供常規計算，輔以特定的 BaaS 產品生態（比如對象存儲、數據庫、消息機制等）。基礎平台包括虛擬機（VM）、專用網絡（VPC）、虛擬化數據塊存儲、身份和訪問管理（IAM）以及計費和監控。

Serverless 與 Serverful

用戶只需要在 Serverless 平台用高級語言寫一些雲函數，再選擇觸發該函數執行的事件即可。之後的事情由 Serverless 系統來搞定，實例選擇、伸縮、部署、容錯、監控、日誌、安全補丁等等全都不用關心，通過提升雲資源的易用性來簡化應用開發。

雲背景下，對雲開發者而言，傳統方式（Serverful Computing）就像是在使用底層彙編語言，哪怕是 c = a + b 的簡單計算也要經過一系列操作：

• 選擇 1 個或 2 個寄存器（預配或找出可用的資源）

• 把值加載到寄存器中（將代碼和數據加載進去）

• 執行算術運算（執行計算）

• 存儲計算結果（返回或存儲結果，最後釋放資源）

而 Serverless 方式則像是用 Python 之類的高級語言在編程，免去了這些繁瑣的操作。

因此，Serverless 最具潛力的地方就在於能給雲開發者帶來這種類似於向高級語言邁進的好處：

The aim and opportunity in serverless computing is to give cloud programmers benefits similar to those in the transition to high-level programming languages.

高級編程環境的一些特性在 Serverless 中有天然的相似之處，例如，自動化的內存管理能把開發者從內存資源的管理工作中解放出來，而Serverless 要將開發者從服務器資源的管理工作中解放出來。

確切地說，Serverless 與 Serverful 最關鍵的區別在於：

• 分離了計算和存儲：存儲和計算分開伸縮、獨立預配、獨立定價。通常存儲由單獨的雲服務提供，並且計算是無狀態的

• 不用管理資源分配就能執行代碼：用戶提供一段代碼，雲自動預配資源來執行

• 按使用付費，而不是按所分配的資源付費：按代碼執行的相關維度付費（比如執行時間），而不是按雲平台的相關維度（比如所分配 VM 的大小和數量）

三.關鍵特點

聽起來與先前的一些模式似乎沒太大區別：

• 現有的一些 PaaS 產品，比如 Firebase、Heroku、Parse 等好像就是 Serverless

• 80 年代的 Web 託管環境不也能提供 Serverless 聲稱的好處嗎？

• 聽起來像是 10 年前的 Google AppEngine，但這在 Serverless 理念出現之前就已經被市場拒絕了呀

那麼，與之前的這些模式相比，Serverless 的關鍵特點是什麼？

伸縮性

伸縮性方面，AWS Lambda 能夠精確跟蹤負載情況，按需快速響應擴展，閒時能夠縮減到零資源、零成本。並且能以更細的粒度計費（100ms），而傳統的彈性伸縮服務通常按小時計費。

最關鍵的是，Serverless 的出發點在於按代碼實際執行的時間計費，而不是為程序執行所保留的資源：

In a critical departure, it charged the customer for the time their code was actually executing, not for the resources reserved to execute their program.

這種區別保證了雲供應商能在彈性伸縮這一點上與雲用戶共擔風險、共享利益（skin in the game），繼而促進高效的資源分配。

強隔離性

Serverless 依靠強大的性能和安全隔離性實現多租戶共享硬件。

對於雲函數，VM 隔離是目前的標準方案，但預配 VM 可能需要幾秒鐘，所以雲供應商會使用一些精細的技術來加快函數執行環境的創建。比如 AWS Lambda 維護了一個熱 VM 池（a "warm pool" of VM）管理能夠立即分配給租戶的 VM，以及一個活躍實例池（an "active pool" of instances）管理那些已經在執行或準備好執行函數的實例。

資源生命周期的管理與多租戶裝箱策略（multi-tenant bin packing）是實現高利用率的關鍵，對 Serverless 而言至關重要。大多利用容器、單核、庫操作系統（library OS）或語言 VM 等技術來減少多租戶隔離的開銷，例如 Google App Engine 使用的 gVisor、AWS Lambda 中的 Firecracker VM，以及 CloudFlare Workers 平台採用 Web 瀏覽器沙盒技術來實現 JavaScript 雲函數間的多租戶隔離。

平台靈活性

PaaS 服務通常與特定用例密切相關，而 Serverless 允許用戶使用自己的類庫，所能支持的應用程序比 PaaS 更廣泛。

而且，Serverless 運行在現代化大型數據中心，所能支持的運行規模比舊的共享 web 託管環境大得多。

服務生態支持

雲函數（比如 FaaS）成功推廣了 Serverless 模式，其中一部分歸功於一些自公有雲以來就存在的 BaaS 服務（比如 AWS S3），這些 BaaS 服務都可以看作面向特定領域、高度優化的 Serverless 實現，而雲函數是一種更通用的 Serverless 表現形式：

Service	Programming Interface	Cost Model
Cloud Functions	Arbitrary code	Function execution time
BigQuery/Athena	SQL-like query	The amount of data scanned by the query
DynamoDB	puts() and gets()	Per put() or get() request + storage
SQS	enqueue/dequeue events	per-API call

四.核心優勢

對雲供應商而言，Serverless 能夠促進業務增長，簡化雲編程，吸引新用戶並幫助現有用戶充分利用雲資源。此外，運行時間短、內存佔用低以及無狀態的特性有利於統計復用。在運行這些任務時，雲供應商更容易發現那些沒有被用到的資源。甚至還能更好地利用那些不太受歡迎的機器（比如舊機器），因為實例類型是由雲供應商來定的，這兩點都能在現有資源的基礎上立即增加收益。

對雲用戶而言，除了提高編程生產力之外，大多數場景下還能節省成本，因為對底層服務器的利用率提高了。在沒有任何雲基礎設施的情況下也能直接部署函數，不僅省去了部署時間，讓雲用戶專注於應用程序自身的問題，還能節省資金，因為函數只在事件發生的時候才執行，細粒度的計費方式（目前是 100ms）意味著按實際使用付費，而不是按所保留的資源付費。

從研究角度來看，Serverless 是一種新的通用計算抽象，有望成為雲計算的未來。因為Serverless 將雲部署級別從 x86 機器代碼提升到了高級編程語言，從而實現架構創新。如果 ARM 或 RISC-V 比 x86 性價比更高，Serverless 也能輕鬆變更指令集。並且雲供應商還能通過研究面向（編程）語言的優化以及特定領域的特殊架構來加快用 Python 等語言編寫的程序。

P.S.99% 的雲計算機用的都是 x86 架構（x86 微處理器 + x86 指令集）

五.現有 Serverless 平台的局限性

現如今，雲函數已經成功應用於多種工作，包括 API 服務、事件流處理和有限的 ETL（Extract-Transform-Load，數據處理），那麼為什麼不能承載更多的通用服務呢？

原因在於：

• 對細粒度操作的存儲支持不足：目前的雲存儲服務無法滿足雲函數的需要

• 缺少細粒度協調：沒有多任務協調機制

• 標準通信模式下性能很差：多任務間無法共享、聚合數據

• 性能不可預測：雖然比傳統的基於 VM 的實例啟動延遲更低���但對於某些應用而言啟動新實例的延遲還是太高了

細粒度操作的存儲不足

Serverless 平台的無狀態性讓支持需要共享細粒度狀態的應用變得很難實現，目前主要受限於雲存儲服務。

對象存儲服務（如 AWS S3、Azure Blob Storage、Google Cloud Storage）雖然能夠快速擴展，並且提供了廉價的長期對象存儲，但存在很高的訪問成本和延遲。近期測試表明讀/寫小對象至少需要 10ms，維持 10 萬 IOPS（每秒讀寫次數，Input/Output Operations Per Second）的成本是 30 美元/分鐘，要比 AWS ElastiCache 實例高 3 到 4 個數量級，並且 ElastiCache 實例只有亞毫秒級讀寫延遲，其 IOPS 甚至能超過 100K。

KV 數據庫（如 AWS DynamoDB、Google Cloud Datastore、Azure Cosmos DB）都提供了高 IOPS 支持，但都很貴，而且無法快速擴展。雖然雲供應商也提供了基於流行開源項目（如 Memcached 或 Redis）的內存存儲實例，但缺少容錯性支持，也無法像 Serverless 平台那樣自動伸縮。

在 Serverless 基礎設施上搭建的應用需要預配透明的存儲服務，即能隨計算自動伸縮的存儲服務。不同應用程序可能對持久性、可用性、延遲、性能等有不同要求，因此可能需要臨時與持久化兩種 Serverless 存儲選項。

缺少細粒度協調

為了支持有狀態的應用，Serverless 框架需要提供一種協調多任務的方式，例如，A 任務用到了 B 任務的輸出，A 就必須有辦法知道什麼時候輸入準備好了，即使 A 和 B 位於不同節點上。許多致力於保證數據一致性的協議也需要類似的協調機制。

現有的雲存儲服務都沒有通知能力，雲供應商雖然提供了獨立的通知服務（如 SNS、SQS），但存在很高的延遲（有時幾百 ms），而且細粒度協調的使用成本也很高。雖然有一些相關改善研究（比如 Pocket），但還沒有被雲供應商所採用。

因此，應用程序要麼管理一個具有通知能力的基於 VM 的系統（例如 ElastiCache、SAND），要麼實現自己的通知機制，比如讓雲函數之間通過一個長期運行著的基於 VM 的匯聚服務器（rendezvous server）來通信。這種限制引發了對一些新 Serverless 變體的探索，比如命名函數實例允許通過直接尋址來訪問其內部狀態（例如 Actors as a Service）。

標準通信模式下性能很差

廣播（broadcast）、聚合（aggregation）、shuffle 機制等分佈式系統中的常見通信模式在雲函數環境複雜度驟增：

[caption id="attachment_2051" align="alignnone" width="1004"] communication patterns for distributed applications[/caption]

原因在於 VM 實例在發送數據之前和收到數據之後有機會在任務之間共享、聚合或合併數據，而在 Serverless 下沒有。

具體的，基於 VM 的方案中，所有運行在同一實例上的任務能夠共享廣播傳來的數據，或者在給其它實例發送部分結果之前進行本地聚合。因此，廣播和聚合的通信複雜度是 O(N)，其中 N 是系統中 VM 實例的數量。而在雲函數環境下，通信複雜度為 O(N × K)，其中 K 是每個 VM 上的函數數量。

在 shuffle 機制下這種差異更大，基於 VM 的方案中所有本地任務能把數據合併到一起，所以兩個 VM 之間只需要傳遞一條消息。假設發送方和接收方數量相等的話，需要發送 N^2 條消息，而在雲函數方案下需要發送 (N × K)^2 條消息。由於雲函數擁有的 CPU 核心數量比 VM 少得多，K 一般是 10 到 100，再加上應用程序無法控制雲函數的位置，實際可能要比等效的 VM 方案多發送 2 到 4 個數量級的數據。

P.S.這些通信模式多用於機器學習與大數據分析應用中。

性能不可預測

影響冷啟動延遲的因素有 3 點：

• 啟動雲函數所需的時間

• 初始化該函數所需軟件環境的時間，比如加載 Python 庫

• 用戶代碼中特定應用程序初始化的時間

比起後兩者的開銷，前者就不算什麼了，比如啟動雲函數只需要 1 秒，而加載所有應用程序類庫可能需要幾十秒。

另一個阻礙因素是硬件資源的可變性，因為雲供應商能夠靈活選擇底層服務器（甚至可能會遇到不同時代的 CPU）。對於這個問題，雲供應商需要在最大限度地利用資源與性能可預測性之間進行權衡。

六.理想的 Serverless Computing

要讓更多應用程序受益於 Serverless，主要面臨著抽象、系統、網絡、安全、架構等方面的挑戰。

抽象

資源需求

開發者只能限制雲函數的內存大小和執行時間，而無法控制其它資源需求，比如 CPU、GPU 或其它類型的加速器。

一種方式是讓開發者顯式指定這些資源需求，但會讓雲供應商更難通過統計復用實現高利用率，因為對雲函數調度施加了更多約束。而且有違 Serverless 精神，因為增加了雲應用開發者的資源管理負擔。

另一種更好的選擇是提升抽象層級，由雲供應商來推斷資源需求而不由開發者指定。比如雲供應商可以通過靜態代碼分析、分析上一次運行情況或者動態編譯源碼來實現。自動預配適當的內存聽起來很誘人，但充滿挑戰，尤其是在高級語言具有自動垃圾回收機制時，甚至有些研究建議這些語言運行時應該與 Serverless 平台集成起來。

數據依賴

目前的雲函數平台不知道兩個雲函數之間的數據依賴關係，導致這些函數之間可能需要交換大量數據。還可能導致不理想的節點分佈，引發更低效的通信模式。

一種解決辦法是雲供應商暴露一個能夠讓應用程序指定其計算圖的的 API，以支持更好的節點分佈決策，將通信降到最低，進而提升性能。實際上，很多通用分佈式框架（如 MapReduce、Apache Spark、Apache Beam/Cloud Dataflow）、並行 SQL 引擎（如 BigQuery, Azure Cosmos DB）以及編排框架（如 Apache Airflow）已經在內部生成了這樣的計算圖。原則上，這些系統通過改造也能運行在雲函數環境，並把計算圖暴露給雲供應商。

P.S.AWS Step Functions 已經在這麼做了，提供了一種狀態機語言和 API。

系統

高性能、預配透明且經濟實惠的存儲

對於臨時與持久化兩種存儲需求，臨時存儲主要用來解決雲函數之間傳遞狀態時的速度和延遲問題。

提供臨時存儲的一種方案是構建具有優化網絡棧的分部式內存服務，以保證微秒級延遲。並像操作系統為進程提供透明的內存預配一樣，自動伸縮，並隨應用生命周期創建/釋放，還要提供安全隔離。但目前 RAMCloud、FaRM 能保證低延遲和高 IOPS，卻沒有提供多租戶隔離，而 Pocket 無法自動伸縮，需要預先分配存儲。

而且，通過統計復用，臨時存儲要比目前的 Serverful 模式內存效率更高，能將 VM 實例中應用程序用不完的那部分內存也利用起來。

雖然 OLTP（On-Line Transaction Processing）之類的數據庫功能可能會越來越多地以 BaaS 形式提供，但對於需要比 Serverless 應用更長的持久���存儲的應用，還應該實現高性能的 Serverless 持久存儲。

對於持久化存儲，可以利用基於 SSD 的分佈式存儲輔以分佈式內存緩存，比如 Anna KV 數據庫，通過結合多個現有的雲存儲服務來實現高性價比和高性能，但這種設計的關鍵點是如何在大量尾部訪問分佈的情況下實現低尾延遲（tail latency），此時內存緩存能力可能比 SSD 能力低得多。此外，利用有望實現微秒級訪問時間的新存儲技術也是一種可能的解決方案。

與 Serverless 臨時存儲類似，持久化存儲服務也應該是預配透明、安全隔離的。不同的是，Serverless 持久化存儲只能顯式釋放資源，像傳統存儲系統一樣。當然，還必須保證持久性，任何已寫入的數據都要能在故障中保留下來。

協調/信號服務

雲函數之間通常採用生產者 - 消費者模式來共享狀態，需要消費者立即得知生產者的數據可用了。

同樣，一個函數可能需要在滿足某種條件時發信號給另一個，或者多個函數可能也想要配合工作，例如實現數據一致性機制。此類信號系統將受益於微秒級延遲、可靠的傳輸以及廣播或群組通信，而且因為雲函數實例無法單獨尋址，無法用來實現教科書式的分佈式系統算法（如 consensus 或 leader election）。

最小化啟動時間

啟動時間分為 3 部分：

• 調度及啟動運行雲函數相關資源

• 下載運行雲函數代碼所需的應用軟件環境（如操作系統、類庫）

• 執行應用程序的特定啟動任務，比如加載和初始化數據結構及類庫

資源調度和初始化以及配置 VPC 和 IAM 策略會造成很大延遲和開銷，雲供應商近期專注於通過開發輕量級隔離機制來縮短啟動時間。

一種辦法是利用單核節省開銷：

• 不像傳統操作系統一樣動態檢測硬件、應用用戶配置、分配數據結構，而是通過預配置硬件和靜態分配數據結構來壓縮這些成本

• 另外，單核只包含應用程序所必須的驅動和系統庫，比傳統操作系統空間佔用低得多

但單核是針對特定應用程序定製的，在運行多個標準內核實時，可能無法實現更進一步的效率提升，比如在同一 VM 中的不同雲函數時無法共享內核代碼分頁，或通過預緩存縮減啟動時間。

另一種方法是在應用程序實際調用時動態增量加載類庫，例如 Azure Functions 裡的共享文件系統。

特定應用程序初始化由開發者來負責，但雲供應商能夠在其 API 中提供就緒信號，以避免過早調用雲函數。另外，雲供應商可以預先執行啟動任務，尤其適用於客戶無關的任務（比如啟動 VM 和流行操作系統及相關類庫），因為多租戶之間能夠共享一個熱實例池（warm pool）。

網絡

前面提到，廣播、協調、shuffle 等流行通信機制在雲函數環境會帶來嚴重的開銷。比如把 K 個雲函數打包到一個 VM 實例上的話，雲函數版將比 VM 版多發出 K 次（甚至更多）消息，在 shuffle 場景甚至需要 K^2 次消息通信。

有 3 種方式解決這個問題：

• 給提供雲函數提供多核，類似於 VM 實例，這樣多個任務就能在發送數據之前或收到數據之後合併/共享數據了

• 允許開發者顯式把一些雲函數放到同一 VM 實例上，給應用程序提供拆箱即用的分佈式通信機制，以便雲供應商把雲函數分配給同一 VM 實例

• 讓應用程序提供計算圖，允許雲供應商將相關雲函數分配到同一 VM 實例（co-locate），從而最大限度地減少通信開銷

但前兩種方式會降低雲供應商分配雲函數的靈活性，導致數據中心的利用率減低。而且有違 Serverless Computing 精神，因為迫使雲開發者去考慮系統管理。

安全

Serverless 打亂了之前的安全責任劃分，將許多責任從雲用戶轉移到了雲供應商身上，而並沒有從根本上改變它們。然而，Serverless 還必須應對應用程序間多租戶資源共享的固有風險。

隨機調度和物理隔離

物理共同駐留（co-residency）是雲環境下硬件級邊信道和 Rowhammer 攻擊的關鍵，此類攻擊首先要與受害者處於同一物理主機上。

雲函數的短暫性能在一定程度上限制攻擊者識別並發運行的受害者的能力。隨機或對手感知（adversary-aware）調度算法能夠降低攻擊者與受害者位於同一主機的風險，讓物理共同駐留攻擊更加困難。但這些安全措施可能會與分配（VM）方式的啟動時間、資源利用和通信優化產生衝突。

細粒度的安全環境

雲函數需要細粒度配置，包括訪問私鑰、存儲對象以及本地臨時資源。需要從現有的 Serverful 應用轉換安全策略，並為雲函數中動態使用提供能夠充分表達（這些策略的）的安全 API，例如，雲函數可能不得不把一些安全特權委託給別的雲函數或雲服務。

在加密保護的安全環境中，基於功能的訪問控制機制可能是此類分佈式安全模型的自然選擇。建議在多方設置中使用信息流控制進行跨函數訪問控制，比如為雲函數動態創建短期秘鑰和證書，但安全機制分佈式管理上的其它問題（比如不對等和吊銷證書）會加劇。

從系統層面來看，用戶需要函數級的細粒度安全隔離，至少要作為可選項。而提供函數級沙盒的難點在於保證較短的啟動時間，不對重複函數調用以共享狀態的方式緩存執行環境。可以通過本地實例快照，讓每個函數都可以從乾淨的狀態開始，或者採用輕量級虛擬化技術（比如庫操作系統、單核、微 VM 等），能夠將啟動時間縮減至幾十毫秒，但不確定其安全性是否能達到傳統 VM 的程度。積極的一面是，Serverless 中的供應商管理和短期實例能夠更快地修補漏洞。

對於那些想要防護物理共同駐留攻擊的用戶，一種解決方案是要求物理隔離。雲供應商可以為客戶提供高級選項，在專用物理主機上啟動雲函數。

模糊的 Serverless

雲函數可能會在通信中洩漏訪問模式（access patterns）和時序信息（timing information）。

對於 serverful 應用，通常批量檢索數據並緩存在本地。而由於雲函數是短暫的，並且在雲環境中廣泛分佈，網絡傳輸模式可能會洩漏敏感信息（比如自家員工），即便數據是端對端加密的，把 Serverless 應用分解成許多小函數的趨勢加劇了這種安全隱患。雖然主要安全問題來自外部攻擊者，但也能通過模糊算法來防護來自員工的攻擊，然而，這樣做的開銷通常都很高。

架構

硬件異質性、定價以及易管理程度

雲計算中佔主導地位的 x86 微處理器在性能上幾乎沒有提升（2017 年單程序性能提升僅 3%），這種趨勢持續下去的話，20 年內性能都無法翻番。同樣，每個芯片的 DRAM 容量也已接近極限，目前有在售的 16Gbit DRAM，但似乎造不出 32G DRAM 的芯片。唯一值得安慰的是，這種龜速變化讓供應商能在舊機器折損時從容更換，而對 Serverless 市場幾乎沒什麼影響。

通用微處理器的性能問題並不會減少對更快速計算的需求，有兩個方向，對於用高級腳本語言（如 JavaScript 或 Python）編寫的函數，可以通過軟硬件共同設計產生語言特定的自定義處理器，其運行速度要快 1 到 3 個數量級。另一個��向是特定領域架構（DSA，Domain Specific Architectures），DSA 能夠針對特定問題領域量身定製，對該領域有顯著的性能和效率提升，但在其它領域表現不佳。圖形處理單元（GPU，Graphical Processing Units）長期以來一直用於加速圖形處理，我們開始看到機器學習領域的 DSA，比如張量處理單元（TPU，Tensor Processing Units），TPU 能比 CPU 快 30 倍。這只是很多實例中的一例，用 DSA 來增強針對單獨領域的通用處理器將成為常態。

對於硬件異質性，同樣有兩個方向：

• Serverless 雲包含多種實例類型，定價取決於所使用的具體硬件

• 雲供應商能夠自動選用基於語言的加速器和 DSA，這種自動化能夠基於雲函數所使用的的軟件庫或語言隱式完成，比如 CUDA 代碼用 GPU，而 TensorFlow 代碼用 TPU。或者，雲供應商能夠監控雲函數的性能並在下一次運行時把它們遷移到更合適的硬件上去。

對於 x86 的 SIMD 指令，Serverless 正面臨著異質性，AMD 和 Intel 通過增加每個時鐘周期執行的操作數和新增指令，來快速改進 x86 指令集中的這部分。對於使用 SIMD 指令的應用程序，在最近的 Intel Skylake 微處理器（512 位寬 SIMD 指令）上運行要比舊的 Intel Broadwell 微處理器（128 位寬 SIMD 指令）上快得多。目前 AWS Lambda 中這兩種微處理器都以相同價格供應，但 Serverless 用戶沒有辦法表明想用更快的 SIMD 硬件。在我們看來，編譯器應該給出哪種硬件最合適的建議。

隨著加速器在雲環境越來越流行，Serverless 雲供應商將無法忽視異質性的困境，尤其是因為存在合理的補救措施。

七.對 Serverless 的 6 大誤解

雲函數每分鐘的價格更貴，因此 Serverless 比 Serverful 貴

因為 Serverless 的定價不單是資源實例，還包括所有系統管理功能，比如可用性冗餘、監控、日誌記錄以及伸縮。而且，Serverless 伸縮粒度更精細，意味著實際使用的計算量可能更有效率。更重要的是，Serverless 在沒有調用雲函數時無需付費，因此可能會比 Serverful 便宜得多。

Serverless 可能會產生無法預料的成本

對某些用戶來說，即用即付也意味著成本不可預測，這與許多組織的預算管理方式相悖，比如審批預算時想要知道未來一年的 Serverless 服務成本。雲供應商可以通過提供套餐定價（bucket-based pricing）來緩解這種需求，就像電話公司為特定使用量提供固定費率套餐一樣，甚至在 Serverless 普及之後，還能根據歷史情況預測出 Serverless 服務成本。

Serverless 使用 Python 等高級語言編程，所以很容易移植到不同 Serverless 平台

不同平台下，不僅函數調用、打包的方式不同，而且許多 Serverless 應用還依賴缺乏標準化的 BaaS 產品/服務生態（比如對象存儲、KV 數據庫、日誌和監控等，要實現可移植），必須形成標準化 API，比如 Google 的 Knative 項目在朝著這個方向探索。

Serverless 下，供應商綁定（vendor lock-in）程度更強

如果應用程序移植困難就會存在與供應商的強綁定，而框架提供的跨雲支持能夠緩解這種強綁定。

雲函數無法應對有極低延遲性能要求的應用程序

Serverful 實例能夠處理此類場景是因為它們一直都在運行，能在收到請求後快速響應。但如果雲函數的啟動延遲對應用程序而言無法滿足，可以採取一些策略來緩解，比如通過定期執行雲函數來預熱。

很少有所謂的彈性服務能滿足 Serverless 的實際靈活性要求

「彈性」（elastic）在 Serverless 中指的是能夠快速變更容量、用戶干預越少越好，而且要在不用時能縮減到 0，而雲供應商所提供的通常只是有限彈性（比如只允許實例化整數個 Redis 實例、要求顯式配置容量、甚至要幾分鐘才能響應需求變化），並沒有達到這些要求，因而失去了許多 Serverless 優勢。

由於沒有明確的技術定義和指標，「彈性」一詞是模糊不清的。

八.總結和預測

通過提供簡化的編程環境，Serverless 讓雲更易於使用，從而吸引更多用戶。Serverless 包括 FaaS 和 BaaS 產品，標誌著雲編程的重要成熟。省去了如今 Serverful 給應用開發人員帶來的手動管理和優化資源的負擔，這種成熟就像 40 多年前從彙編語言走向高級語言一樣。

預測 Serverless 的應用將會暴漲，並且混合雲本地應用程序會越來越少，儘管某些部署可能會由於法規約束和數據管制規則而保持現狀。

雖然已經取得了一定成功，但還存在許多挑戰，能夠克服這些問題的話，就能讓 Serverless 在更廣泛的應用程序中流行起來。第一步是 Serverless 臨時存儲，必須以合理的成本提供低延遲、高 IOPS（的臨時存儲服務），但無需提供經濟實惠的長期存儲。第二類應用程序將受益於 Serverless 持久存儲，因為它們確實需要長期存儲，新的非易失存儲器技術可能有助於此類存儲系統。其它應用程序將會受益於低延遲的信號服務以及對流行通信機制的支持。

Serverless 未來的兩個重大挑戰是提升安全性和適應可能來自專用處理器的性價比改進，Serverless 已有的一些特性有助於應對這些挑戰，例如：

• 物理共同駐留是邊信道攻擊的必要條件，在 Serverless 中很難確認（是否處於同一物理機器上），而且很容易採取防護措施，比如隨機分佈雲函數

• 用高級語言（如 JavaScript、Python 或 TensorFlow）編程的雲函數，提升了編程抽象層級，更有利於底層硬件創新

最後，預測 Serverless Computing 在接下來的 10 年裡：

• 將出現新的 BaaS 存儲服務，讓更多類型的應用程序都能跑在 Serverless 下。此類存儲能達到本地數據塊存儲的性能，分為臨時的和持久化的兩種。與傳統的 x86 微處理器相比，serverless 下計算機硬件的異質性要大得多。

• 將比 serverful 更易於安全編程。得益於高級編程抽象，以及雲函數的細粒度隔離。

• Serverless 的計費模型將會改進，因為其成本沒有理由比 serverful 更高。所以 絕大多數以任何規模運行的應用程序在 Serverless 下成本不會更高，甚至更低。

• Serverful 將用來促進 BaaS 服務。難以在 Serverless 上實現的應用程序（比如 OLTP 數據庫或隊列等通信機制等），可能會作為雲供應商服務集的一部分提供。

• 雖然 serverful 不會消失，但其重要性會隨著 Serverless 突破目前的限制而逐漸降低。

• Serverless 將成為雲時代的默認計算模式，在很大程度上取代 serverful，從而結束 Client-Server 時代。

參考資料

• Cloud Programming Simplified: A Berkeley View on Serverless Computing