簡化云編程，伯克利對serverless的看法（翻譯）

譯者言：

作為了解一個技術最好的方式之一就是對相關論文進行閱讀，比如spark論文，kafka論文，對自己的提升也是非常巨大的，由于一句話中經常涉及巨大的信息量，所以將論文徹底翻譯為中文，仔細理解閱讀是非常必要的，幾年前我曾經讀過spark論文的英文版，泛泛而看，再加上后續并沒有長期應用，其實已經忘記的差不多了。畢竟自己英文也沒那么好，如果總看英文版的長篇大論，其實并不是高效的學習方式，倒不如花幾天時間進行論文翻譯加深理解。最后也附了自己的批注希望幫助閱讀者理解。

我在19年翻譯了這篇文章，今天分享希望能夠促進大家對serverless的理解

原文https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf

Copyright ? 2019, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission.

1.介紹

2009年，為了幫助解釋云計算的好處，“伯克利對云計算的看法”，闡述了6個潛力優勢：

無限的計算資源按需使用的出現

消除了云用戶一線的承諾

根據需要短期支付計算資源使用費用的能力。

由于許多非常大的數據中心而顯著降低成本的規模經濟。

通過資源虛擬化，簡化運維，增加利用率

通過復用來自不同組織的工作負載，獲得更高的硬件利用率

在過去十年中這些優勢被大范圍的意識到，但是云用戶繼續承受 復雜操作和許多工作負載的負擔仍然不能從有效的多路復用中受益。這些不足主要與未能實現最后兩個潛在優勢有關

云計算免除了用戶的物理基礎設施管理，但留給他們的是要管理的虛擬資源。

復用很適合應用在批量處理的工作負載場景[t1]?，比如map reduce，高性能計算，這種可以充分利用被分配的資源的實例的場景。但是在有狀態服務中，工作的并不好，比如移植企業級軟件，比如數據庫到云上運行[t2]?。

2009年，在云計算虛擬化方法中有兩個相互競爭的方法，如論文中所述：

亞馬遜EC2是這一系列產品中的一個，ec2實例更像是物理硬件，用戶可以幾乎操作從內核向上的軟件的全棧。而另一個極端的系列是特定領域應用的平臺，比如GAE。強制在無狀態計算層和有狀態存儲層間，進行干凈的分離的應用結構。app engine的令人印象深刻的自動擴展和高可用性機制。。。依賴于這種限制

市場最終擁抱了亞馬遜的低層級的虛擬機方法，去上云，于是google，微軟等其他云廠商也提供了類似的接口。我們相信低層級的虛擬機的成功的主要原因是，早期云計算用戶想要完全重建和他們本地計算一樣的云環境來簡化移植工作負載的工作量。那是實際的需求，足夠的明智，比起單獨為云寫新程序優先級更高，尤其是在云有多成功還不明確的時候。

這個抉擇的缺點是，開發者不得不自己管理虛擬機，基本上通過成為系統管理員或者和系統管理員一起配合，來完成環境安裝。表1列舉操作云環境必須管理的問題。這一長串低層級虛擬機管理的責任激發了一些有著簡單應用的客戶尋求新應用程序上云的更容易的路徑。比如，假設

為可用性做到冗余，這樣一臺機器的故障不會導致服務中斷。

在發生災難時保留服務的冗余拷貝的地理分布

通過負載均衡，請求路由高效利用資源

根據負載變化自動伸縮系統

監控服務確保他們一直健康地運作

記錄日志用于debug和性能調優

系統升級，包括安全補丁

在新實例可用時遷移到新實例。

表1：為云用戶建立環境需要解決的八個問題。一些問題需要采取許多步驟。比如，自動伸縮需要決定伸縮所需；選擇服務器的大小和類型，申請服務器，等待他們上線，在之上配置應用，確保沒有錯誤發生，使用監控工具監控他們，然后發送請求測試他們。

一個應用想要從手機發送圖片到云端，云端應該先創建圖片縮略圖，把他們放到網站，完成這些任務的代碼可能有幾百行java script代碼，這些開發量比起準備好用來運行它的服務器的開發量，是可以忽略不計的。

意識到這些需求使得亞馬遜推出了一種新的選擇，叫AWS Lambda。Lambda提供云函數，為serverless計算吸引了很多的關注。盡管無服務器計算可以說是一種矛盾的說法–你仍然在使用服務器進行計算–因為它推崇云用戶只需編寫代碼并將所有服務器配置和管理任務留給云提供商。云函數被包裝為FaaS提供給用戶，代表著serverless計算的核心，云平臺也提供專門的serverless框架滿足特比定的應用需求作為BaaS提供。簡單來說Serverless計算=FaaS+BaaS

在我們的定義中，要認為服務是無服務器的，它必須自動地伸縮無需顯式地進行配置，并根據使用情況計費。在剩下的時間里 本文主要研究云函數的產生、演變和未來。云函數在當今無服務器計算中是一種泛用的元素，并引領著走向簡化和面向云的泛用編程模型。

接下來，我們定義無服務器計算，就像伯克利對云計算的看法這篇論文一樣，接著，我們列出如果無服務器計算要兌現他的承諾，所要解決的挑戰和研究機遇。我們不確定哪種解決方案會勝利，我們相信所有的問題最終都會被解決，使得無服務器成為云計算的的門面。

2.無服務器計算的誕生

在任何serverless平臺，用戶只需要用高級語言編寫云函數。選擇一個觸發函數運行的觸發器–比如加載圖片到云存儲或增加縮略圖到數據庫–讓serverless平臺處理其他的所有事：實例選擇，伸縮，部署，容錯，監控，日志，安全補丁等等。表2總結了無服務器和傳統計算方法的不同。在論文中我們稱傳統的為serverful云計算。注意到上述兩種方法代表了基于函數的／以服務器為中心的計算平臺的終點，他們都使用容器編排框架，如Kubernetes作為中間層

表2：以開發者和系統管理員2個大類分別列舉，serverless和虛擬機的特征。lambda和按需ec2的規格和價格

圖1，展示serverless如何簡化應用部署，使得云資源更容易被使用。在云的上下文中，serverful計算就像是編程語言中的匯編語言，serverless計算像是python這樣的高級別語言。匯編程序員計算簡單的公式，比如c=a+b，得選擇1個或多個寄存器使用，加載值到寄存器中，然后計算公式，然后再存儲結果。這就好比使用serverful計算的幾個步驟，先配置資源，確定可使用的資源，然后在資源中加載代碼和數據，然后開始計算，把結果返回或者存儲起來，最終將資源釋放。Serveless計算的目標和機會是讓云編程者像使用高級語言那樣受益。其他的一些高級語言特性也可以天然的對應到serverless計算中。自動化的內存管理解放了開發者，不需要在管理內存資源，serverless computing解放了開發者，不必再管理服務器資源。

準確地說，serverful和serverless計算有3個關鍵的區別：

計算存儲解耦。存儲和計算分別伸縮，獨立配置和計算。存儲由獨立的云服務提供，計算則是無狀態的。

執行代碼而無需管理資源分配。不用請求資源，用戶提供代碼片段，云負責自動配置資源并執行代碼。

按使用的資源支付而不是按分配的資源支付。按照執行來計費，比如執行時間，而不是基礎云平臺，比如被分配的vm的規格。

通過這些區別，接下來我們解釋為何serveless不同于一些相似的解決方案，包括以前的和現在的。

圖1：serverless的架構，serverless層在應用層和基礎云平臺之間，簡化云編程。云函數（比如FaaS）提供通用計算并且由專門的BaaS補足生態系統，比如對象存儲，數據庫，消息。具體地，一個在AWS上的serverless應用可能會使用lambda，同時使用S3（對象存儲）和dynamoDB（kv數據庫）。一個在google上運行的serverless應用則使用cloud function，同時使用cloud firestore（移動應用后臺數據庫），cloud Pub/Sub（消息）。Serverless還有大數據的服務，比如AWS Athena和google BigQuery（big data query），google cloud DataFlow和AWS Glue（big data transform）。下邊的基礎云平臺包括VM，VPC，塊存儲，IAM，還有計費，監控

2.1 Serverless的語境場景

要使severless計算成為可能需要怎樣的技術突破？有些人認為無服務器計算僅僅是對先前產品的重新命名，可能就是個泛用PaaS平臺比如heroku，Firebase或者Parse。有些人指出90年代提供的共享web托管環境提供的和現在serverless計算提供的差不多。比如這些方案都有無狀態的編程模型，用于多租，彈性響應請求，標準的函數調用API，通用的網關接口（CGI）等高層級，甚至允許高級別語言編寫的源代碼直接進行部署，比如PHP,Perl。Google原先的App Engine幾年前在serverless流行之前就被市場拒絕了，它也允許開發者部署代碼，將大部分其他操作丟給云提供商。我們相信serverless計算相對PaaS和其他模型有著顯著的創新。

如今的云函數severless在以下幾個重要方面區別于他的前身們：更好的伸縮，強隔離性，平臺靈活性，服務生態系統支持。在這些因素中，AWS Lambda提供的自動伸縮與以前的方案完全背道而馳。不同于serverful的自動伸縮技術，它更準確的跟蹤工作負載。當需要時能快速的響應伸縮，沒有需求時甚至可以縮到0資源，0開銷。它以更細粒度的方式產生成本。提供最小的計費，每增加100ms收一次費，而其他的自動甚多服務都是按照小時收費。最關鍵的不同，用戶只需要為執行代碼的時間支付開銷。而不是所有它為程序預留的資源。這種區別確保了云提供商在自動縮放時獲得利益同時承擔風險[t3]?，也因此他們提供激勵措施[t4]?，以確保高效的資源分配。

Severless計算依賴強大的性能和安全隔離使多租戶，硬件共享成為可能。類VM的隔離是目前標準云函數的多租硬件共享方案，但由于VM的配置時間需要會長達數秒，serverless提供商使用復雜的技術來加速創建函數執行環境。一種方法反映在AWS Lambda, 它維護一個VM實例warm pool，需要時分配給租戶，一個active pool用來運行函數并服務后續的調用。資源生命周期管理和多租裝箱打包需要達到一個高利用率，這是severless計算成功的關鍵技術。我們認識到幾個最近的proposal目標都是減少多租隔離引起的開銷，他們通過容器，unikernal，library OSes或者language VMs。比如google宣布app engine，cloud functions，cloud ML engine采用gvisor。Amazon發布Firecracker VMs用于lambda和 fargate。CloudFlare workers serverless平臺，在使用瀏覽器沙盒技術的javascript云函數之間提供多租隔離

幾個其他的區別幫助serverless成功。通過允許用戶帶入自己的庫，serverless計算相對PaaS服務能夠幫助更廣泛的應用，后者只能支持特定的使用場景。Serverless計算跑在現代化數據中心中，比起老的web托管環境有著更大的規模。

如第1節所述，cloud function（即FaaS）使serverless模式變得流行。必須認識到他們的成功部分歸功于BaaS的產品，自公有云開始以來就一直存在服務，比如AWS S3。在我們看來，這些服務都是領域相關，高優化度的serverless計算的實現。云函數表示serverless計算的通用形式。通過對比幾個服務的編程接口和成本模型，我們把這些看法總結在了表3

表3： serverless計算服務與他們相應的編程接口和消費模型。注意上述的bigquery，athena，cloud functions，用戶需要分別地為他們消耗的存儲再付錢（比如google cloud storage，AWS S3或者Azure Blob Storage）。

一種用于部署微服務的容器編排技術。不像serverless計算，k8s是一種簡化Serverful計算的技術。得益于google內部多年的使用和開發，它獲得了大量系統快速的采用，k8s提供短生存周期的計算環境，就像serverless計算那樣，且有著更少的限制，比如，在硬件資源，執行時間，網絡通信方面。它還可以以極小的適配，部署原本部署在公有云的應用。而serverless計算引入了規范轉變，它完全卸下了操作類的職責，并轉嫁給了提供商，細粒度[t5]?的多租復用成為可能。K8s托管服務，比如GKE，EKS提供中間層：他們卸下了管理k8s的工作，并使開發者可以靈活的配置任意的容器。K8s和serverless計算的關鍵不同是計費模型。前者按保留資源收費，后者按功能執行持續時間收費。

K8s還完美匹配了混合應用，部分跑在本地硬件，部分跑在云上。我們的看法是這種混合應用在向云過渡中是有道理的。然而長期來看，我們相信云規模上升后的經濟成本、更快的網絡帶寬、增長的云服務和通過serverless計算簡化云管理將降低這種混合應用的重要性。

邊緣計算在后PC時代是云計算的好伙伴，我們本篇專注在serverless計算如何在數據中心中轉變編程習慣，有趣的潛在趨勢是這也會影響到邊緣。幾個CDN提供商使用戶能在最接近他們的設施里執行他們的函數，不論用戶在哪，AWS IoT greengrass甚至在邊緣設備集成了serverless執行

既然我們已經定義并決定了serverless計算的語境場景，讓我們看看為什么它對云提供商，用戶，研究者那么有吸引力

2.2 Serverless計算的吸引力

對于提供商來說，serverless通過開發簡化吸引新的客戶，幫助現有客戶更多的使用云資源（譯者： BaaS）提升了商業增長。例如最近的調查發現，24%的serverless用戶都是云計算新用戶，30%現有的Serverful客戶也使用Serverless計算。另外短運行時間、小內存占用和無狀態天然改進了復用，通過更容易的使提供商找到不在使用中的資源并執行這些任務。提供商也可以利用不太受歡迎的計算節點—實例類型完全由提供商決定—比如舊的服務器也許已經對serverful用戶沒什么吸引力了。這些都增加了現有資源的收入。

表4：serverless計算的使用場景受歡迎程度，2018年調查

客戶的收益是編程生產力提升，同時在許多應用場景都可以節省成本，這是底層服務器利用率更高的結果。即便serverless使客戶更高效了，然而杰文斯悖論[t6]?說的是高效的使用只會增加使用者和需求量，最終擴大使用量而不是縮減。

Serverless 提升了云部署層級從x86機器代碼到高級編程語言—99%的云計算機使用x86指令集，使得架構改革。如果ARM和RISC-V提供更好的性價比，Serverless計算可以很容易的切換指令集。云提供商還能去研究面向語言的優化和領域相關的特定架構[t7]?來加速某種語言編寫的程序的執行速度，比如python。

用戶喜歡Severless，因為能夠在不了解云基礎設施的情況下進行函數部署，專家節省了部署的時間，集中精力在應用獨有的問題上。既然函數只在執行時計費，且是細粒度的計費，那么Serverless用戶可以節省金錢，這意味著他們只付他們使用的東西，而不是他們保留的東西，表格4展示了目前歡迎度高的serverless使用場景。

研究者都被吸引到了serverless計算，尤其是在云函數方面，因為它是一種新的通用計算抽象，很可能成為云計算的未來，因為還有很多加速性能，克服限制的可能性。

3.如今Serverless計算平臺的限制

云函數已經成功應用到多種工作負載，包括API服務，事件流處理，特定ETL（表3）。

為了看看是什么阻礙了他應用于一般的工作負載，我們嘗試創建我們感興趣的應用的serverless版本，并研究其他人發布的樣例。它們并不代表當前無服務器計算生態系統之外的其他信息技術；它們只是一些簡單的例子，用來揭示可能會阻礙許多其他應用的serverless版本發展的共通弱點。

在本章中，我們展示5個研究項目的概覽，并討論阻礙serverless平臺實現最先進的性能的障礙，比如,匹配serverful部署下的工作負載的性能。我們特別關注使用通用云函數的方法，而不是依賴于其他特定serverless應用（BaaS）。然而在我們最后的例子中，SQLLite，我們識別一個use case映射到FaaS后非常糟糕，我們得出結論，數據庫和嚴重依賴狀態的應用還是適合作為BaaS提供，一個附件在論文最后，有著每個應用更詳細的信息。

有趣的是，即使是折衷[t8]?的應用程序組合也暴露了類似的弱點，我們在描述應用程序之后列出了這些弱點。表5總結了五個應用程序。

ExCamera：視頻實時編碼。提供實時的編碼服務，比如youtube，取決于視頻大小，如今的編碼方案可以花費幾十分鐘甚至數小時。為了能夠實時編碼，ExCamera將慢速的編碼部分并行化，串行執行快速的部分。ExCamera暴露內部的編解碼狀態，允許編解碼任務以純粹的函數語義執行。特別地，每個任務需要以有著視頻幀的內部狀態做為輸入，并將修改后的內部狀態作為輸出。

MapReduce：分析框架如MapReduce，Hadoop，Spark，部署在傳統的管理集群中。而有些分析的工作負載已經開始遷移到serverless，這些工作負載大多由Map作業組成，下一步自然是支持全面的MapReduce作業。這個努力背后的驅動力是利用serverless計算的靈活性高效的支持作業，這些作業在執行期間所需的消耗各有不同。

Numpywren：線性代數。大規模線性代數計算是一種傳統的部署在超算或者由高速低時延的網絡連接的高性能計算集群。在這樣的歷史背景下，serverless看上去不適合這個場景[t9]?，但是有兩個理由說明為什么serverless可能在線性代數計算中是有道理的。第一，管理集群是一些沒有CS背景的科學家的巨大障礙。第二，并行的量會在計算期間顯著地變化。配置一個節點數量恒定的集群要不就是會拖慢作業速度，要不就是沒法充分利用集群性能。

Cirrus：機器學習訓練。機器學習的研究者使用VM集群來執行不同的ML工作流任務，比如預處理，模型訓練，超參優化。這種方法的一個挑戰是，流水線的不同階段需要不同的資源，如同線性代數一樣，一個固定大小的集群，會導致嚴重的利用不足或嚴重降速。Serverless計算可以通過為不同階段分配合理資源來克服這個挑戰，還可以解放開發者不再維護集群。

Serverless SQLLite：數據庫。自動伸縮的數據庫服務已經存在了，但是要更好的理解Serverless的局限性，那么理解是什么使得數據庫工作負載這么的有挑戰是十分重要的。在這個上下文中，我們考慮是否有第三方可以直接使用云函數來實現一個Serverless Database，一個解決方案是在云函數中運行通用事務型數據庫，例如PostgresSQL，Oracle，mysql。然而這就會面臨幾個挑戰，第一，Serverless計算沒有內置的持久化存儲，所以我們需要利用遠程的，這會造成巨大的延遲。第二，數據庫采用面向連接的協議，比如，數據庫作為server運行接收客戶端的連接。這種方案與運行在網絡地址轉換后面的云函數沖突，因此不能支持這些鏈接。最后，許多高性能數據庫依賴于共享內存，云函數是隔離的，無法共享內存。一些不分享內存的數據庫希望節點一直在線，可以直接定位到。全部這些問題對在無服務器上運行傳統數據庫軟件或實現等效功能提出了重大挑戰，所以我們希望數據庫就放在BaaS。

這些應用希望使用Serverless的一個關鍵理由是細粒度的自動伸縮，這樣資源利用率就可以匹配每個應用不同的需求，表格5總結了這5個應用的特征，挑戰和workaround。我們利用他們來識別當前serverless計算的4個局限性

表5：Serverless新應用領域的需求總結

3.1 細粒度操作場景下存儲的不足

Serverless平臺天然的無狀態使它很難支持應用進行細粒度狀態分享。這主要是由于現在的云提供商提供的存儲服務的限制引起的。表6總結了云存儲服務的特點。

表6：理想的serverless存儲和云提供商存儲服務特性。綠色表示好，橙色中等，紅色為糟糕。

持久性和可用性保證描述了系統對故障的容忍程度：

Local表示只能保證一個地區的可靠，distributed確保能夠多個地區可靠，ephemeral表示數據存在內存中，應用崩潰，數據就會丟失。理想的Serverless存儲提供與塊存儲相當的性價比，同時可以透明的讓云函數配置并訪問存儲

對象存儲比如S3，Azure Blob Storage，有著高可擴展性，提供便宜的長期對象存儲。但是卻有著高訪問成本和延遲。根據最近的測試，所有這種服務花費至少10微秒讀或寫小對象。S3提供高吞吐，但是他變得更貴了。維持10萬IOPS, 需要花費每分鐘30美元，比運行ElastiCache多3到4個數量級。ElastiCache提供高性能，讀寫延遲小于毫秒，并且一個redis sever一個線程可提供超過10w IOPS的吞吐。

Key value數據庫，例如DynamoDB，Google cloud Datastore提供高IOPS，但是非常貴，而且需要較長時間啟動。最后，云廠商還提供內存存儲實例，比如memcached，redis，但是他們不能容錯，也不能像Severless平臺那樣自動伸縮。

如我們再表5看到的，構建在Serverless的應用需要透明化配置的存儲服務，與計算的伸縮相匹配的存儲量。不同的應用推動不同的持久化和可用性保證，還可能推動延遲或其他性能測量方法。我們相信這需要開發一種短暫的和持久的serverless存儲，我們會進一步在第4部分討論。

3.2 缺少細粒度協調器

為了擴展支持有狀態應用，serverless框架需要提供一種方法，可以讓任務協作。比如，如果任務A需要任務B的輸出，必須有一種方法讓A知道輸入已經準備好了，甚至A和B在不同的節點中。許多協議[t10]?的目的都是確保數據的一致性，也需要類似的協調者。

現在的云存儲服務都沒有通知能力。但是云廠商提供獨立的通知服務，比如SNS和SQS，這些服務顯著地增加了延遲，有時達到幾百毫秒。此外，當用于細粒度的協調時，它們可能代價高昂。已經有了一些相關的研究，比如Pocket，它沒有很多的缺點，但是還沒有云廠商去采用它。

如前所述，應用沒有選擇，只能選擇基于VM管理的系統，這些系統內提供通知，如ElastiCache和SAND，或者實現自己的通知機制比如ExCamera，它讓云函數之間通過一個長期運行的基于虛擬機的服務器相互通信。這種局限性還表明一種新的Serverless計算變種可能值得探索，比如給函數實例命名并允許直接尋址以訪問其內部狀態（Actor as a service）

3.3 糟糕的性能和標準通信模式

廣播，聚合，和shuffle在分布式系統中是一些最通用的通信原語。這些操作被應用到機器學習和大數據分析。圖2展示了這幾種原語在基于VM的和函數解決方案的通信模式。

圖2,：3種分布式系統通用通信模式：a表示VM實例，每個實例運行2個函數或是任務。B表示同樣的模式但換成了云函數實例。注意VM方案有更少的遠程通信。這是因為

VM實例在發送前或收到后提供了大量的機會點，可以跨任務在本地共享、聚合或組合數據

使用VM方案，所有運行在一個實例中的任務可以在發送結果到其他實例前，共享data的復制用于廣播，本地聚合。所以廣播和聚合的復雜度是O(N)，N是VM實例數。然而云函數的復雜度是O(NK),K是每個VM中的函數實例。而shuffle操作更具戲劇性。VM方案，本地任務可以組合數據所以2個VM實例間只有一條消息。假設同樣數量的發送者和接受者就是N的平方條消息。對比看，云函數需要NK的平方條消息。函數比VM有更小的核心數，K一般從10到100。既然應用沒法控制函數的位置，一個serverless應用可能比VM方案多發送2到4個數量級的數據

3.4 可預測的性能

即便云函數比起傳統VM實例有著更低的啟動延遲，但是對于某些應用程序，在啟動新實例時發生的延遲可能很高。有三個影響冷啟動延遲的因素：

啟動云函數的時間

初始化軟件環境的實踐，比如，python庫

用戶自己的代碼

后兩者可以使前者相形見絀。花費1秒的可以可以啟動函數，但是可能需要10多秒來加載應用的庫。[t11]

另一個阻礙預測性能的是硬件資源的可變性，這是云提供商可以靈活地來選擇底層服務器的結果。在我們的實驗中，我們有時占用的CPU是不同的時代的產品。這種不確定性暴露了云提供商在希望最大限度地利用其資源和可預測性之間進行了基本的取舍權衡。

4 Serverless計算會變得怎么樣

既然我們已經解釋了如今的serverless計算和他的局限性，讓我們看看未來，了解如何將他的優勢利用到更多的應用。研究者已經開始著手解決上述的問題，并且探索如何改進serverless平臺和跑在其上的工作負載。伯克利同事和我們的一些人所做的額外工作重視以數據為中心，分布式系統，機器學習，編程模型在serverless計算的機遇和挑戰。在這里，我們廣泛的看看增加在serverless計算中運行良好的應用程序和硬件的類型，識別5個領域的研究挑戰：抽象，系統，網絡，安全和架構

4.1 抽象

資源需求： 現在serverless允許開發者指定函數的內存大小和執行時間限制，但沒有其他的資源需求。這種抽象阻礙了那些想要更多地控制指定資源的人，比如CPU，GPU。一種可以讓開發者明確指定這些資源需求的方法。然而這將使云提供商更難通過復用實現高利用率，因為他為函數調度增加了更多的限制。它還違背了無服務器的精神，增加了云應用程序開發者的管理開銷

更好的選擇是提高抽象級別，讓云提供商推斷資源需求，而不是讓開發人員指定它們。為此，云提供商可以使用多種方法，從靜態代碼分析到分析以前的運行，再到動態（重新）編譯，將代碼重新定位到其他機器架構。自動提供適當的內存量特別有吸引力，但是當方案必須與自動垃圾回收合作時是非常有挑戰的。有些研究提議這些語言運行時能被serverless平臺集成。

數據依賴： 如今的云函數平臺不會感知函數間的數據依賴，更不用說這些函數可能交換的數據量了。這種忽視會導致次優的系統布局，從而導致低效的通信模式，如我們前述的MapReduce和numpywren

一種解決這個挑戰的方法是，云提供商暴露API讓應用指定他的計算圖，通過更好的位置決策，最小化通信并改進性能。我們注意到許多通用的分布式框架（例如MapReduce,Spark, Beam, Cloud Datafow）,并行數據庫（BigQuery，Cosmos DB），還有編排框架（Airflow）可以在內部產生一個圖。原則上這些系統內可以在修改后跑在蘊含出上并暴露圖給云提供商[t12]?。注意AWS Step Functions代表著這個發展方向的進步，它提供有狀態機器語言和API

4.2系統挑戰

高性能，價格合理，透明配置的存儲： 如表3和5所討論的，我們2個不同的未解決的存儲需求：serverless臨時存儲和持久存儲

臨時存儲。在第三部分的前4個應用被存儲的速度和延遲限制了，存儲用于在云函數間傳送狀態。同時需要的容量也是不同的，他們都需要這樣的一種存儲來維護應用存活期間的狀態。一旦應用結束，狀態就可以被丟棄。這樣的短暫存儲也許可以使用其他應用的緩存來進行配置。[t13]

一種提供短暫存儲的方法是構建一個網絡棧優化的分布式內存服務，確保微秒級延遲。這種系統確保應用的函數在應用生存期間能夠高效的存儲交換狀態。這種內存服務需要根據應用需求自動伸縮存儲容量和IOPS。這種服務的一個獨特點在于，它不只需要透明分配內存，還要透明的釋放內存。特別地，當應用終止或者失敗，存儲需要被自動釋放。這種管理類似于操作系統自動釋放進程完成（或崩潰）時由進程分配的資源。進一步，這樣的存儲必須提供應用間的訪問保護和性能隔離。

RAMCloud和FaRM展示了提供微秒級的實驗并支持一個實例幾百幾千IOPS的內存存儲服務也是可能的。他們通過優化整個軟件棧并利用RDMA來最小化延遲來達到這個效果。然而他們需要應用指明配置存儲。他們也不為多租提供強隔離。另外一個最近的，Pocket，目標是提供短暫存儲的抽象，但是也缺少自動伸縮，要求應用預先分配存儲。

通過利用多路復用，臨時存儲比如今Serverless計算更高效的利用內存。使用Serverless，如果應用需要的內存少于分配的VM實例內存，那么內存就會浪費，相反，使用共享內存服務，一個無服務器應用未使用的任何內存都可以分配給另一個應用。實際上，即便一個應用也可以通過多路復用獲得收益：使用Serverless，VM不使用的內存不會被跑在其他VM上的程序使用，他們都屬于同一個應用。而共享內存服務可以。當然，即使使用Serverless計算如果云函數不使用它全部的本地內存，也會造成內部的內存碎片。在某些情況下，在共享內存服務中存儲云函數的應用狀態可以減輕內存碎片化。

持久存儲。就像個其他應用一樣，serverless數據庫應用的試驗受限于存儲系統內的延遲和IOPS，他也需要長期的數據存儲和文件系統可變狀態語義。而數據庫的功能包括OLTP可能會越來越多的作為BaaS提供[t14]?。我們將此應用視為幾個應用程序的代表，這些應用需要比serverless提供給的臨時存儲更長的保留期和更高的持久性。為了實現高性能serverless持久化存儲。一種方法是利用基于SSD的分布式存儲對，配合分布式內存緩存。一個最近的系統認識到需要這些目標，那就是Anna Key value數據庫，他通過結合多個現有的云存儲達成了成本效益和高性能。這個設計的一個關鍵挑戰是在重尾訪問分布[t15]?中達成low tail latency[t16]?，基于這個事實，內存緩存容量可能會被SSD容量低很多很多[t17]?。利用新的存儲技術[t18]?，承諾微秒級訪問時間，正在成為解決這一挑戰的一個有前途的辦法。

類似Serverless臨時存儲，服務必須是透明配置的，并且應該確保應用間隔離和租戶安全并且性能可預測。然而，當應用程序終止時，serverless的臨時存儲將回收資源，持久存儲必須只是釋放資源（比如remove或者delete命令造成的終止），就像傳統存儲系統一樣。另外，它必須確保持久性，這樣寫入的數據才能被保存下來。

協調器/ 信號服務： 在函數間分享狀態經常使用生產者消費者模式，這需要消費者在數據可用時就知道這件事。同樣地，當某個條件變化時，一個函數可能想要發信號給另一個函數或者多個函數共同協調，比如為了實現數據一致性機制。這樣的信號系統可以從微秒延遲，可靠消息和廣播，組通信中受益。我們也注意到，既然云函數實例不是獨立可尋址的，那么他們就不能被用于實現標準的分布式系統算法，如共識或leader選舉

最小化啟動時間： 啟動時間由3部分組成

1． 調度和啟動資源用戶用于運行函數

2． 下載應用環境（OS，庫）用于運行函數代碼

3． 應用啟動，比如加載，初始化數據結構，庫。

資源調度和初始化會引起明顯的延遲和負擔，因為他會創建隔離的執行環境，配置客戶的VPC和IAM策略。云提供商最近已經專注于開發新的輕量化隔離機制來減少啟動時間。

一種減少2的方法是利用unikernal。Unikerna用兩種方法消除傳統操作系統帶來的開銷。第一，不像傳統OS動態探測硬件，應用用戶配置，分配數據結構，unikernal通過為運行它們的硬件預先配置并靜態分配數據結構，來壓縮這些成本。第二，unikernal只包括應用需要的驅動和系統庫，這比傳統系統的占用低許多。值得注意的是，由于unikernels是為特定的應用程序定制的，當運行標準內核的許多實例時，可能無法實現高效。比如不同云函數在同VM共享內核頁，或者通過預緩存減少啟動時間。另一種減少2的方法是當應用調用時動態并增量的加載庫，比如Azure Functions使用共享文件系統。

特定應用初始化（3）是程序員的職責，但是云提供商可以包含一個準備就緒信號在他們的API里來避免云函數在實例沒啟動前就收到工作。更寬泛的說，云提供商可以尋求提前執行啟動任務的方法[t19]?。對于與客戶無關的任務，比如用流行的操作系統和一系列庫引導VM，這一功能尤其強大。如warm pool[t20]?可以在租戶間共享。

4.3 網絡挑戰

如第三章圖2所說，云函數可以引起及明顯的通信負擔，這些通信原語都是非常流行的如廣播，聚合，shuffle。尤其是假設我們打包K個函數在同一個VM實例，云函數版相對單實例版會發K倍的消息，在shuffle則是K平方。

有幾種方法可以解決這個挑戰：

l 提供給函數大量的cores，類似VM實例，這樣在網絡上發送消息前和接受后，多個任務可以在他們之間組合和共享數據。

l 允許開發者明確的把函數部署到同一個VM，提供分布式通信原語，應用可以開箱即用，這樣云提供商可以分配函數到同一個VM實例。

l 讓應用提供計算圖，云提供商對函數進行定位最小化通信負擔（參考抽象挑戰）

注意前兩個proposal可能減少云提供商放置函數的靈活性，導致減少數據中心利用率。爭議地是，他們也通過逼迫開發者思考系統管理，違背了Serverless精神

4.4.安全挑戰

Serverless計算洗牌了安全職責，將他們從用戶轉嫁給了提供商，沒有從根本上改變他們。然而serverless計算還必須處理應用和多租戶資源共享中內在的風險。

隨機調度和物理隔離： 物理共存是在云內部硬件級別側信道或Rowhammer[t21]?攻擊的中心。攻擊的第一步，攻方租戶需要確認與受害人在同一物理主機上，而不是隨機攻擊陌生人。云函數的短暫性可能會限制攻擊者識別受害者（兩方的函數同時運行）的能力。一種隨機化的敵方感知調度算法可以減少攻擊方和受害者定位在一起的風險，使攻擊變得困難。然而，特意阻止物理上的共同放置，可能會與優化啟動時間、資源利用或通信的安排相沖突

細粒度安全上下文：云函數需要細粒度配置，包括秘鑰訪問，存儲對象，甚至本地臨時資源。需要翻譯已經存在的Serverful應用的安全策略，提供高表達能力的安全API給云函數動態使用。比如函數可能委托安全權限給其他函數或云服務。使用加密保護基于功能的訪問控制機制的安全上下文天然適合這種分布式安全模型。最近的工作提議，使用信息流在多方配置中控制跨函數訪問控制。其他的提供安全原語的分布式管理，例如non-equivocation和revocation會使情況惡化，如果函數動態創建秘鑰和證書。

在系統級別，用戶需要每個函數有更細粒度的安全隔離，至少是可選的。提供函數級沙箱的挑戰是以一種方法在不緩存執行環境的情況下保持短啟動時間，在重復的函數調用之間共享狀態的，一種可能是對實例進行本地快照，以便每個函數都可以從干凈狀態開始。或者輕量級虛擬化技術開始被serverless提供商采用：library OSes 包括gVisor，在用戶空間“shim layer”實現系統API，而unikernal和microVMs，包括AWS firecracker，優化guest內核并幫助最小化主機攻擊面。這些隔離技術減少了啟動時間到了幾十微秒，相對的，VM啟動時間是以秒度量。這些解決方案是否在安全性方面與傳統vm實現了對等，還有待證明。我們期望，尋找具有低啟動開銷的強隔離機制成為研究和開發的一個活躍領域。從積極的一面來看，提供商管理和短期實例可以更快地修補漏洞。

用戶系統避免共住攻擊，一種解決方案是要求物理隔離。最近的硬件攻擊也利用保留核心甚至整個機器來吸引用戶。提供商可以提供高級選項給客戶在物理宿主機啟動函數，宿主機完全歸屬于他們使用[t22]?。

不留意的Serverless計算：函數可能通過通信泄漏訪問模式和時間信息。對于serverful應用程序，數據通常是在批處理中檢索的，并在本地緩存。相反，因為云函數是短暫的，分布廣泛在云中，網絡傳輸模式可以向云中的網絡攻擊者泄漏更敏感的信息（比如員工就是攻擊者），即使payload是端到端加密的。將無服務器應用程序分解為許多小函數的趨勢加劇了這種安全暴露。雖然主要的安全問題是來自外部攻擊者，但是可以通過采用不經意的算法[t23]?來保護網絡模式不受雇員的攻擊。不幸的是，這些往往有很高的開銷

4.5 計算架構挑戰

異構硬件，價格，易于管理：x86微處理器作為在云計算中占主導地位的技術在性能上幾乎沒有提高。2017年一個程序的性能提升只有3%。如果這種趨勢繼續下去，20年內性能不會翻番。同樣，每個芯片的DRAM容量也接近極限；現在在賣16gbit的DRAM，但是要制造一個32gbit的DRAM芯片似乎是不可行的。這種緩慢變化的一個好兆頭是，供應商可以將磨損的舊電腦不受干擾[t24]?的投入到Serverless市場。

通用微處理器的性能問題并不能降低對更快計算的需求。有兩條路，對于用高級腳本語言（如JavaScript或Python）編寫的函數，軟硬件協同設計可以使特定于語言的運行速度快一到三個數量級的定制處理器，另一個前進的路徑是特定領域的體系結構[t25]?。DSA針對特定的問題領域進行了定制，并提供顯著的性能和效率提高，但該域以外的應用程序的性能較差。GPU一直被用來加速圖形，我們開始將DSAs用于機器學習，如TPU。TPU的性能可以超過CPU 30倍。這些示例是許多示例中的第一個，針對不同領域使用DSA增強的通用處理器將成為常態

如4.1提到的，我們看到serverless計算支持異構硬件2條路：

Serverless擁抱多種實例類型，根據使用的硬件提供不同的計費方式。

提供商能夠基于語言自動選擇加速器和DSA。這種自動化可以隱式地基于在函數中使用的軟件庫或語言來實現，比如GPU硬件用于CUDA 代碼，TPU用于TensorFlow代碼。可選地，提供商監控函數的性能，下次運行時將他們遷移到個更適合的硬件。

Severless計算現在需要面對x86中的SIMD指令集的異構。AMD和Intel通過增加每個時鐘周期執行的操作數和添加新的指令，迅速發展了x86指令集的這一部分。對于使用SIMD指令的程序，在最新的Intel Skylake微處理器上運行512位寬的SIMD指令比在舊的Intel Broadwell微處理器上運行128位寬的SIMD指令要快得多。如今AWS Lambda以同樣的價格提供所有的微處理器，但是用戶目前沒辦法指定他們想要更快的SIMD。在我們看來，編譯器[t26]?應該建議使用哪種硬件會是最好的搭配。

當加速器變得更流行時，serverless提供商將不能夠忽視異構的兩難境地，尤其是因為存在合理的補償措施。

5.謬論和陷阱

**謬論 ： **既然Lambda 云函數實例有著和t3.nano 相等的內存容量，而價格是7.5 倍每分鐘，那么severless 的價格更貴。

Severless計算的美妙之處在于價格中包含的所有系統管理功能，包括可用性冗余、監視、日志記錄和伸縮。云提供商報告說，當將應用遷移到Serverless時，客戶看到成本節約了4-10倍。功能要比一個t3.nano實例多很多，除了單點故障外，信用系統還將其限制為每小時最多6分鐘的CPU使用時間（兩個vCPUs中的5%），所以它可能在負載高峰期間拒絕服務，而Serverless卻可以輕松處理。Serverless在更細的邊界進行資源占用，包括伸縮，因此使用的計算資源可能更高效。因為沒有觸發函數調用的事件時就不會收費，serverless可能便宜許多。

陷阱 計算可能會產生不可預測的成本。

對有些用戶來說，一個用多少花多少的缺點是無法預測成本，這與許多組織管理預算的方式不一致。在批準預算（通常每年進行一次）時，組織希望知道下一年serverless服務的成本是多少，這種期望是合理的，云提供商可以通過提供基于bucket的定價來緩解，類似于電話公司為一定量的使用提供固定費率計劃的方式。我們還相信，隨著組織越來越多地使用serverless，他們將能夠根據歷史預測其serverless計算成本，類似于他們今天對電力等其他公用事業服務的方式。

謬論 既然serverless 計算編程是高級別語言就像python ，那就很容易在不同serverless 提供商間移植。

不只是函數的調用原語和打包方式不同，而且serverless應用還依賴于缺乏標準化的專有的BaaS產品生態系統。對象存儲，key value數據庫，認證，日志和監控這些是突出的例子。為了實現可移植性，用戶必須采用某種標準API，比如POSIX試圖為操作系統提供的API。來自Google的Knative項目是朝這個方向邁出的一步，旨在為應用開發人員跨部署環境使用統一的原語

陷阱?比起Serverful 計算，serverless 廠商鎖定可能非常強

這個陷阱是先前謬論的結果；如果移植很困難，那么很可能會出現供應商鎖定。一些框架承諾通過跨云支持來減輕這種鎖定

謬論?云函數不能處理需要能預測性能的低延遲應用

serverful實例之所以能很好地處理這種低延遲的應用程序，是因為它們總是處于打開狀態，因此它們可以在收到請求時快速響應請求。我們注意到，如果云功能的啟動延遲對于給定的應用程序來說不夠好，那么可以使用類似的策略：通過定期運行來預熱云函數，以確保在給定時間內有充足的運行實例來處理請求。

陷阱?幾乎沒有所謂“彈性”的服務能比得上無服務器計算的真正的靈活性需求

如今彈性這個詞是個流行術語，但這個名字被應用在那些不如serverless計算服務的服務上。

我們對能迅速改變容量的服務感興趣，只需最少的用戶干預，就可以在不使用時“伸縮到零”。例如，盡管它的名字是AWS ElastiCache，但它只允許你實例化固定的數量的Redis實例。其他“彈性”服務需要顯式的容量配置，有些服務需要花費數分鐘來響應需求的變化，或者只能在一個限制的范圍伸縮。當用戶構建的應用將高度彈性的云函數與只有有限彈性的數據庫、搜索索引或服務器級應用程序結合起來時，他們將失去serverless計算的許多好處。

如果沒有一個量化的、被廣泛接受的技術定義或度量標準，用于幫助對比和構成系統，那么彈性就還是一種不明確的描述。

6總結和預測

通過提供一種簡化的編程環境，serveless使云更容易使用，因此吸引更多人可以和愿意使用它。Serverless計算承諾FaaS和BaaS交付，是云編程的重要成熟標志。它消除了當今serverful計算對應用開發人員的手動資源管理和優化的需要。類似于過去40年匯編語言向高級語言的演變。

我們預測serverless的使用將激增，我們還預計，隨著時間的推移，混合云中的本地應用程序將逐漸減少。盡管由于監管約束和數據治理規則，一些部署可能會持續保持現狀。[t27]

雖然已經取得了成功，但我們發現了一些挑戰，如果克服了這些挑戰，服務器將在更廣泛的應用中變得受歡迎。第一步是Serverless臨時存儲，他必須提供低延遲，高IOPS，且價格合理，但是不需要提供實惠的長期儲存。第二類應用需要持久存儲，可按需長期存儲。新的非易失性內存技術可能有助于這樣的一種存儲系統。其他應用程序可以從低延遲信號服務和對流行通信原語的支持中獲益。

無服務器計算未來面臨的兩個改進挑戰是安全性和性價比優勢（性價比可能來自于特殊用途的處理器）。在這兩種情況下，serverless計算的特性有可能有助于解決這些挑戰。物理共住是側信道攻擊的條件，但是在serverless計算中很難確定，而且可以很容易地隨機放置云函數。 云函數高級語言編程如JavaScript, Python, TensorFlow提升了編程抽象層級，使創新變得容易，這樣可以交付具有性價比的硬件。

伯克利對serverless計算的看法論文預測2009年云計算面臨的挑戰將得到解決，并將蓬勃發展，這已經成真了。云營業額年增長50%，已經被證明對提供商來說是高盈利的。

我們對serverless計算的下一個10年作了以下預測：

l 我們期望新的BaaS存儲服務，以擴展在serverless計算上運行良好的應用類型。這樣的存儲將匹配本地塊的性能，有短暫和持久兩種。我們將看到用于serverless計算的異構硬件遠遠超過今天為其提供動力的傳統x86微處理器。

l 我們期望serverless計算比serverful計算更容易安全地編程，這得益于高層級編程抽象和云函數的細粒度隔離。

l 我們看不出serverless計算的成本高于serverful計算的基礎，所以我們預測計費模型將會變化，任何規模的應用消耗的成本都會更少。

l serverful計算的未來將是促進BaaS的發展。在severless計算上很難編寫的應用程序，比如OLTP數據庫和通過信原語如隊列，可能會是這種服務的一部分。

l serverful計算不會消失，隨著serverless計算克服了他的諸多局限性，他在云的重要性將下降

l serverless計算將成為云時代的默認計算模式，在很大程度上取代了serverful計算，從而結束了客戶端-服務端時代

[t1]譯者：只要運行便是在滿速運轉的，跑在同一個資源池里進行資源復用就行了

[t2]譯者：獨占資源池，平時閑置比較多，隨時待用，資源難以復用

[t3]譯者：高效利用資源，而對于用戶來說，則是把資源管理等多種風險都給了云提供商

[t4]譯者：新的收費形式

[t5]譯者：相對的，粗粒度指虛機級別的資源分配，而serverless卻使共享虛機成為可能

[t6]譯者：這也是為啥早期云計算剛興起時，oracle等傳統服務器廠商搶著做云計算，VM的高效使得服務器可以大賣

[t7]譯者：領域相關，比如安防領域

[t8]譯者：不是無狀態，但也不是像數據庫那樣的重依賴于狀態的應用

[t9]譯者：指的網絡延遲和高性能不適合

[t10]譯者：比如raft

[t11]譯者：所以java需要一種方案，否則Serverless在國內很難打動市場，比如Graal和Quarkus

[t12]譯者：這樣的話標準誰制定還是云廠商主動適配？

[t13]譯者：Redis？

[t14]One recent example is Amazon Aurora Serverless (https://aws.amazon.com/rds/aurora/serverless/). Services such as Google’s BigQuery and AWS Athena are basically serverless query engines rather than fully fledged databases.

[t15]每種云存儲的延遲,速度是完全不同的，呈重尾分布

[t16]比如P99 1ms，但是p99.9高達2s，說的是這部分延遲需要被降低

可能?[t17]如重尾分布所說，呈現2/8分布

[t18]An Chen. A review of emerging non-volatile memory (NVM) technologies and applications. Solid-State Electronics, 125:25–38, 2016.

[t19]Edward Oakes, Leon Yang, Dennis Zhou, Kevin Houck, Tyler Harter, Andrea Arpaci-Dusseau, and Remzi Arpaci-Dusseau. SOCK: Rapid task provisioning with serverless-optimized containers. In 2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 57–70, 2018.

[t20]Timothy A. Wagner. Acquisition and maintenance of compute capacity, September 4 2018. US Patent 10067801B1.

[t21]Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu. Flipping bits in memory without accessing them: An experimental study of dram disturbance errors. In ACM SIGARCH Computer Architecture News, volume 42, pages 361–372. IEEE Press, 2014.

[t22]譯者：非常不錯的收費模式和安全策略，雖然違背Serverless精神

[t23]?An algorithm whose behavior, by design, is independent of some property that influences a typical algorithm for the same problem…

Elaine Shi, T-H Hubert Chan, Emil Stefanov, and Mingfei Li. Oblivious RAM with O((log N) 3 ) worst-case cost. In International Conference on The Theory and Application of Cryptology and Information Security, pages 197–214. Springer, 2011.

[t24]譯者：用戶感知不到便是沒有干擾？

[t26]譯者：Serverless平臺中的編譯器

[t27]譯者：這也阻礙一些業務向service mesh的轉型

機器翻譯 上云必讀 Serverless

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。