譯者言：

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

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

原文www2.eecs.berkeley.edu/Pubs/TechRp…****

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年，為了幫助解釋云計(jì)算的好處，“伯克利對云計(jì)算的看法”，闡述了6個(gè)潛力優(yōu)勢：

無限的計(jì)算資源按需使用的出現(xiàn)

消除了云用戶一線的承諾

根據(jù)需要短期支付計(jì)算資源使用費(fèi)用的能力。

由于許多非常大的數(shù)據(jù)中心而顯著降低成本的規(guī)模經(jīng)濟(jì)。

通過資源虛擬化，簡化運(yùn)維，增加利用率

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

在過去十年中這些優(yōu)勢被大范圍的意識到，但是云用戶繼續(xù)承受 復(fù)雜操作和許多工作負(fù)載的負(fù)擔(dān)仍然不能從有效的多路復(fù)用中受益。這些不足主要與未能實(shí)現(xiàn)最后兩個(gè)潛在優(yōu)勢有關(guān)

云計(jì)算免除了用戶的物理基礎(chǔ)設(shè)施管理，但留給他們的是要管理的虛擬資源。

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

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

亞馬遜EC2是這一系列產(chǎn)品中的一個(gè)，ec2實(shí)例更像是物理硬件，用戶可以幾乎操作從內(nèi)核向上的軟件的全棧。而另一個(gè)極端的系列是特定領(lǐng)域應(yīng)用的平臺，比如GAE。強(qiáng)制在無狀態(tài)計(jì)算層和有狀態(tài)存儲(chǔ)層間，進(jìn)行干凈的分離的應(yīng)用結(jié)構(gòu)。app engine的令人印象深刻的自動(dòng)擴(kuò)展和高可用性機(jī)制。。。依賴于這種限制

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

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

為可用性做到冗余，這樣一臺機(jī)器的故障不會(huì)導(dǎo)致服務(wù)中斷。

在發(fā)生災(zāi)難時(shí)保留服務(wù)的冗余拷貝的地理分布

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

根據(jù)負(fù)載變化自動(dòng)伸縮系統(tǒng)

監(jiān)控服務(wù)確保他們一直健康地運(yùn)作

記錄日志用于debug和性能調(diào)優(yōu)

系統(tǒng)升級，包括安全補(bǔ)丁

在新實(shí)例可用時(shí)遷移到新實(shí)例。

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

一個(gè)應(yīng)用想要從手機(jī)發(fā)送圖片到云端，云端應(yīng)該先創(chuàng)建圖片縮略圖，把他們放到網(wǎng)站，完成這些任務(wù)的代碼可能有幾百行java script代碼，這些開發(fā)量比起準(zhǔn)備好用來運(yùn)行它的服務(wù)器的開發(fā)量，是可以忽略不計(jì)的。

意識到這些需求使得亞馬遜推出了一種新的選擇，叫AWS Lambda。Lambda提供云函數(shù)，為serverless計(jì)算吸引了很多的關(guān)注。盡管無服務(wù)器計(jì)算可以說是一種矛盾的說法--你仍然在使用服務(wù)器進(jìn)行計(jì)算--因?yàn)樗瞥缭朴脩糁恍杈帉懘a并將所有服務(wù)器配置和管理任務(wù)留給云提供商。云函數(shù)被包裝為FaaS提供給用戶，代表著serverless計(jì)算的核心，云平臺也提供專門的serverless框架滿足特比定的應(yīng)用需求作為BaaS提供。簡單來說Serverless計(jì)算=FaaS+BaaS

在我們的定義中，要認(rèn)為服務(wù)是無服務(wù)器的，它必須自動(dòng)地伸縮無需顯式地進(jìn)行配置，并根據(jù)使用情況計(jì)費(fèi)。在剩下的時(shí)間里 本文主要研究云函數(shù)的產(chǎn)生、演變和未來。云函數(shù)在當(dāng)今無服務(wù)器計(jì)算中是一種泛用的元素，并引領(lǐng)著走向簡化和面向云的泛用編程模型。

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

2.無服務(wù)器計(jì)算的誕生

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

角色特征Aws serverlessAws serverful

開發(fā)者程序運(yùn)行用戶選擇的事件持續(xù)地運(yùn)行，直到明確指出需要停止

編程語言Js，python，java，go，c#等任意

程序狀態(tài)持久化到存儲(chǔ)中（無狀態(tài)）任意（無狀態(tài)或有狀態(tài)）

最大內(nèi)存0.125到3g0.5-1952g

本地存儲(chǔ)0.5g0-3600g

最大運(yùn)行時(shí)間900s無

最小計(jì)費(fèi)單元0.1s60s

每個(gè)計(jì)費(fèi)單元的價(jià)格0.0000002美元0.0000867-0.408美元

操作系統(tǒng)和庫云廠商選擇用戶選擇

系統(tǒng)管理服務(wù)實(shí)例云提供商選擇用戶選擇

伸縮云提供商選擇用戶選擇

部署云提供商職責(zé)用戶職責(zé)

容錯(cuò)云提供商職責(zé)用戶職責(zé)

監(jiān)控云提供商職責(zé)用戶職責(zé)

日志云提供商職責(zé)用戶職責(zé)

表2：以開發(fā)者和系統(tǒng)管理員2個(gè)大類分別列舉，serverless和虛擬機(jī)的特征。lambda和按需ec2的規(guī)格和價(jià)格

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

準(zhǔn)確地說，serverful和serverless計(jì)算有3個(gè)關(guān)鍵的區(qū)別：

計(jì)算存儲(chǔ)解耦。存儲(chǔ)和計(jì)算分別伸縮，獨(dú)立配置和計(jì)算。存儲(chǔ)由獨(dú)立的云服務(wù)提供，計(jì)算則是無狀態(tài)的。

執(zhí)行代碼而無需管理資源分配。不用請求資源，用戶提供代碼片段，云負(fù)責(zé)自動(dòng)配置資源并執(zhí)行代碼。

按使用的資源支付而不是按分配的資源支付。按照執(zhí)行來計(jì)費(fèi)，比如執(zhí)行時(shí)間，而不是基礎(chǔ)云平臺，比如被分配的vm的規(guī)格。

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

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

2.1 Serverless的語境場景

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

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

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

幾個(gè)其他的區(qū)別幫助serverless成功。通過允許用戶帶入自己的庫，serverless計(jì)算相對PaaS服務(wù)能夠幫助更廣泛的應(yīng)用，后者只能支持特定的使用場景。Serverless計(jì)算跑在現(xiàn)代化數(shù)據(jù)中心中，比起老的web托管環(huán)境有著更大的規(guī)模。

如第1節(jié)所述，cloud function（即FaaS）使serverless模式變得流行。必須認(rèn)識到他們的成功部分歸功于BaaS的產(chǎn)品，自公有云開始以來就一直存在服務(wù)，比如AWS S3。在我們看來，這些服務(wù)都是領(lǐng)域相關(guān)，高優(yōu)化度的serverless計(jì)算的實(shí)現(xiàn)。云函數(shù)表示serverless計(jì)算的通用形式。通過對比幾個(gè)服務(wù)的編程接口和成本模型，我們把這些看法總結(jié)在了表3

服務(wù)編程接口消費(fèi)模型

Cloud Functions任意代碼函數(shù)執(zhí)行時(shí)間

BigQuery/Athena類Sql查詢查詢到的數(shù)據(jù)數(shù)量

DynamoDBPuts() and gets()每個(gè)get put操作以及存儲(chǔ)

SQSEnqueque/Dequeue 事件API調(diào)用

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

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

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

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

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

2.2 Serverless計(jì)算的吸引力

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

百分比場景

32Web和API

21數(shù)據(jù)處理，比如ETL（抽取，轉(zhuǎn)換，加載）

17集成三方應(yīng)用

16內(nèi)部工具

8聊天機(jī)器人 比如Alex Skills（Alexa AI助手的SDK）

6IoT

表4：serverless計(jì)算的使用場景受歡迎程度，2018年調(diào)查

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

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

用戶喜歡Severless，因?yàn)槟軌蛟诓涣私庠苹A(chǔ)設(shè)施的情況下進(jìn)行函數(shù)部署，專家節(jié)省了部署的時(shí)間，集中精力在應(yīng)用獨(dú)有的問題上。既然函數(shù)只在執(zhí)行時(shí)計(jì)費(fèi)，且是細(xì)粒度的計(jì)費(fèi)，那么Serverless用戶可以節(jié)省金錢，這意味著他們只付他們使用的東西，而不是他們保留的東西，表格4展示了目前歡迎度高的serverless使用場景。

研究者都被吸引到了serverless計(jì)算，尤其是在云函數(shù)方面，因?yàn)樗且环N新的通用計(jì)算抽象，很可能成為云計(jì)算的未來，因?yàn)檫€有很多加速性能，克服限制的可能性。

3.如今Serverless計(jì)算平臺的限制

云函數(shù)已經(jīng)成功應(yīng)用到多種工作負(fù)載，包括API服務(wù)，事件流處理，特定ETL（表3）。

為了看看是什么阻礙了他應(yīng)用于一般的工作負(fù)載，我們嘗試創(chuàng)建我們感興趣的應(yīng)用的serverless版本，并研究其他人發(fā)布的樣例。它們并不代表當(dāng)前無服務(wù)器計(jì)算生態(tài)系統(tǒng)之外的其他信息技術(shù)；它們只是一些簡單的例子，用來揭示可能會(huì)阻礙許多其他應(yīng)用的serverless版本發(fā)展的共通弱點(diǎn)。

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

有趣的是，即使是折衷[t8]的應(yīng)用程序組合也暴露了類似的弱點(diǎn)，我們在描述應(yīng)用程序之后列出了這些弱點(diǎn)。表5總結(jié)了五個(gè)應(yīng)用程序。

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

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

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

Cirrus：機(jī)器學(xué)習(xí)訓(xùn)練。機(jī)器學(xué)習(xí)的研究者使用VM集群來執(zhí)行不同的ML工作流任務(wù)，比如預(yù)處理，模型訓(xùn)練，超參優(yōu)化。這種方法的一個(gè)挑戰(zhàn)是，流水線的不同階段需要不同的資源，如同線性代數(shù)一樣，一個(gè)固定大小的集群，會(huì)導(dǎo)致嚴(yán)重的利用不足或嚴(yán)重降速。Serverless計(jì)算可以通過為不同階段分配合理資源來克服這個(gè)挑戰(zhàn)，還可以解放開發(fā)者不再維護(hù)集群。

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

這些應(yīng)用希望使用Serverless的一個(gè)關(guān)鍵理由是細(xì)粒度的自動(dòng)伸縮，這樣資源利用率就可以匹配每個(gè)應(yīng)用不同的需求，表格5總結(jié)了這5個(gè)應(yīng)用的特征，挑戰(zhàn)和workaround。我們利用他們來識別當(dāng)前serverless計(jì)算的4個(gè)局限性

應(yīng)用描述挑戰(zhàn)Workarounds性價(jià)比

實(shí)時(shí)視頻壓縮視頻編碼對象存儲(chǔ)太慢無法支持細(xì)粒度通信；函數(shù)對于任務(wù)來說太粗粒度函數(shù)到函數(shù)通信，避免對象存儲(chǔ)；函數(shù)執(zhí)行替代任務(wù)VM的60倍速度，6分之一價(jià)格

MapReduce大數(shù)據(jù)處理（100TB）Shuffle不會(huì)因?yàn)閷ο蟠驽e(cuò)的延遲和IO的限制而伸縮低延遲，高IOPS的小存儲(chǔ)來加速shuffle比VM排序100TB快1%，花費(fèi)多15%

線性代數(shù)大規(guī)模線性代數(shù)需要很大的問題規(guī)模來克服存儲(chǔ)延遲，很難實(shí)現(xiàn)高效的廣播使用低延遲高吞吐的存儲(chǔ)處理小規(guī)模問題比原本慢3倍，但是CPU消耗節(jié)省1.26到2.5倍

ML 流水線規(guī)模化的ML訓(xùn)練缺少告訴存儲(chǔ)來實(shí)現(xiàn)參數(shù)服務(wù)器，很難實(shí)現(xiàn)高效廣播，聚合低延遲存儲(chǔ)，高IOPS的參數(shù)服務(wù)比VM快3-5倍，成本高7倍

數(shù)據(jù)庫有主狀態(tài)的應(yīng)用缺少共享內(nèi)存，對象存儲(chǔ)延遲太高，缺少鏈接管理的支持如果沒有過多的寫入操作，可以通過共享文件系統(tǒng)解決每個(gè)事務(wù)的成本高3倍，讀規(guī)模相當(dāng)?shù)菍懖皇?/p>

表5：Serverless新應(yīng)用領(lǐng)域的需求總結(jié)

3.1 細(xì)粒度操作場景下存儲(chǔ)的不足

Serverless平臺天然的無狀態(tài)使它很難支持應(yīng)用進(jìn)行細(xì)粒度狀態(tài)分享。這主要是由于現(xiàn)在的云提供商提供的存儲(chǔ)服務(wù)的限制引起的。表6總結(jié)了云存儲(chǔ)服務(wù)的特點(diǎn)。

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

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

Local表示只能保證一個(gè)地區(qū)的可靠，distributed確保能夠多個(gè)地區(qū)可靠，ephemeral表示數(shù)據(jù)存在內(nèi)存中，應(yīng)用崩潰，數(shù)據(jù)就會(huì)丟失。理想的Serverless存儲(chǔ)提供與塊存儲(chǔ)相當(dāng)?shù)男詢r(jià)比，同時(shí)可以透明的讓云函數(shù)配置并訪問存儲(chǔ)

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

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

如我們再表5看到的，構(gòu)建在Serverless的應(yīng)用需要透明化配置的存儲(chǔ)服務(wù)，與計(jì)算的伸縮相匹配的存儲(chǔ)量。不同的應(yīng)用推動(dòng)不同的持久化和可用性保證，還可能推動(dòng)延遲或其他性能測量方法。我們相信這需要開發(fā)一種短暫的和持久的serverless存儲(chǔ)，我們會(huì)進(jìn)一步在第4部分討論。

3.2 缺少細(xì)粒度協(xié)調(diào)器

為了擴(kuò)展支持有狀態(tài)應(yīng)用，serverless框架需要提供一種方法，可以讓任務(wù)協(xié)作。比如，如果任務(wù)A需要任務(wù)B的輸出，必須有一種方法讓A知道輸入已經(jīng)準(zhǔn)備好了，甚至A和B在不同的節(jié)點(diǎn)中。許多協(xié)議[t10]的目的都是確保數(shù)據(jù)的一致性，也需要類似的協(xié)調(diào)者。

現(xiàn)在的云存儲(chǔ)服務(wù)都沒有通知能力。但是云廠商提供獨(dú)立的通知服務(wù)，比如SNS和SQS，這些服務(wù)顯著地增加了延遲，有時(shí)達(dá)到幾百毫秒。此外，當(dāng)用于細(xì)粒度的協(xié)調(diào)時(shí)，它們可能代價(jià)高昂。已經(jīng)有了一些相關(guān)的研究，比如Pocket，它沒有很多的缺點(diǎn)，但是還沒有云廠商去采用它。

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

3.3 糟糕的性能和標(biāo)準(zhǔn)通信模式

廣播，聚合，和shuffle在分布式系統(tǒng)中是一些最通用的通信原語。這些操作被應(yīng)用到機(jī)器學(xué)習(xí)和大數(shù)據(jù)分析。圖2展示了這幾種原語在基于VM的和函數(shù)解決方案的通信模式。

圖2,：3種分布式系統(tǒng)通用通信模式：a表示VM實(shí)例，每個(gè)實(shí)例運(yùn)行2個(gè)函數(shù)或是任務(wù)。B表示同樣的模式但換成了云函數(shù)實(shí)例。注意VM方案有更少的遠(yuǎn)程通信。這是因?yàn)?/p>

VM實(shí)例在發(fā)送前或收到后提供了大量的機(jī)會(huì)點(diǎn)，可以跨任務(wù)在本地共享、聚合或組合數(shù)據(jù)

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

3.4 可預(yù)測的性能

即便云函數(shù)比起傳統(tǒng)VM實(shí)例有著更低的啟動(dòng)延遲，但是對于某些應(yīng)用程序，在啟動(dòng)新實(shí)例時(shí)發(fā)生的延遲可能很高。有三個(gè)影響冷啟動(dòng)延遲的因素：

啟動(dòng)云函數(shù)的時(shí)間

初始化軟件環(huán)境的實(shí)踐，比如，python庫

用戶自己的代碼

后兩者可以使前者相形見絀。花費(fèi)1秒的可以可以啟動(dòng)函數(shù)，但是可能需要10多秒來加載應(yīng)用的庫。[t11]

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

4 Serverless計(jì)算會(huì)變得怎么樣

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

4.1 抽象

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

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

數(shù)據(jù)依賴：如今的云函數(shù)平臺不會(huì)感知函數(shù)間的數(shù)據(jù)依賴，更不用說這些函數(shù)可能交換的數(shù)據(jù)量了。這種忽視會(huì)導(dǎo)致次優(yōu)的系統(tǒng)布局，從而導(dǎo)致低效的通信模式，如我們前述的MapReduce和numpywren

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

4.2系統(tǒng)挑戰(zhàn)

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

臨時(shí)存儲(chǔ)。在第三部分的前4個(gè)應(yīng)用被存儲(chǔ)的速度和延遲限制了，存儲(chǔ)用于在云函數(shù)間傳送狀態(tài)。同時(shí)需要的容量也是不同的，他們都需要這樣的一種存儲(chǔ)來維護(hù)應(yīng)用存活期間的狀態(tài)。一旦應(yīng)用結(jié)束，狀態(tài)就可以被丟棄。這樣的短暫存儲(chǔ)也許可以使用其他應(yīng)用的緩存來進(jìn)行配置。[t13]

一種提供短暫存儲(chǔ)的方法是構(gòu)建一個(gè)網(wǎng)絡(luò)棧優(yōu)化的分布式內(nèi)存服務(wù)，確保微秒級延遲。這種系統(tǒng)確保應(yīng)用的函數(shù)在應(yīng)用生存期間能夠高效的存儲(chǔ)交換狀態(tài)。這種內(nèi)存服務(wù)需要根據(jù)應(yīng)用需求自動(dòng)伸縮存儲(chǔ)容量和IOPS。這種服務(wù)的一個(gè)獨(dú)特點(diǎn)在于，它不只需要透明分配內(nèi)存，還要透明的釋放內(nèi)存。特別地，當(dāng)應(yīng)用終止或者失敗，存儲(chǔ)需要被自動(dòng)釋放。這種管理類似于操作系統(tǒng)自動(dòng)釋放進(jìn)程完成（或崩潰）時(shí)由進(jìn)程分配的資源。進(jìn)一步，這樣的存儲(chǔ)必須提供應(yīng)用間的訪問保護(hù)和性能隔離。

RAMCloud和FaRM展示了提供微秒級的實(shí)驗(yàn)并支持一個(gè)實(shí)例幾百幾千IOPS的內(nèi)存存儲(chǔ)服務(wù)也是可能的。他們通過優(yōu)化整個(gè)軟件棧并利用RDMA來最小化延遲來達(dá)到這個(gè)效果。然而他們需要應(yīng)用指明配置存儲(chǔ)。他們也不為多租提供強(qiáng)隔離。另外一個(gè)最近的，Pocket，目標(biāo)是提供短暫存儲(chǔ)的抽象，但是也缺少自動(dòng)伸縮，要求應(yīng)用預(yù)先分配存儲(chǔ)。

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

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

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

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

最小化啟動(dòng)時(shí)間：啟動(dòng)時(shí)間由3部分組成

1． 調(diào)度和啟動(dòng)資源用戶用于運(yùn)行函數(shù)

2． 下載應(yīng)用環(huán)境（OS，庫）用于運(yùn)行函數(shù)代碼

3． 應(yīng)用啟動(dòng)，比如加載，初始化數(shù)據(jù)結(jié)構(gòu)，庫。

資源調(diào)度和初始化會(huì)引起明顯的延遲和負(fù)擔(dān)，因?yàn)樗麜?huì)創(chuàng)建隔離的執(zhí)行環(huán)境，配置客戶的VPC和IAM策略。云提供商最近已經(jīng)專注于開發(fā)新的輕量化隔離機(jī)制來減少啟動(dòng)時(shí)間。

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

特定應(yīng)用初始化（3）是程序員的職責(zé)，但是云提供商可以包含一個(gè)準(zhǔn)備就緒信號在他們的API里來避免云函數(shù)在實(shí)例沒啟動(dòng)前就收到工作。更寬泛的說，云提供商可以尋求提前執(zhí)行啟動(dòng)任務(wù)的方法[t19]。對于與客戶無關(guān)的任務(wù)，比如用流行的操作系統(tǒng)和一系列庫引導(dǎo)VM，這一功能尤其強(qiáng)大。如warm pool[t20]可以在租戶間共享。

4.3 網(wǎng)絡(luò)挑戰(zhàn)

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

有幾種方法可以解決這個(gè)挑戰(zhàn)：

l 提供給函數(shù)大量的cores，類似VM實(shí)例，這樣在網(wǎng)絡(luò)上發(fā)送消息前和接受后，多個(gè)任務(wù)可以在他們之間組合和共享數(shù)據(jù)。

l 允許開發(fā)者明確的把函數(shù)部署到同一個(gè)VM，提供分布式通信原語，應(yīng)用可以開箱即用，這樣云提供商可以分配函數(shù)到同一個(gè)VM實(shí)例。

l 讓應(yīng)用提供計(jì)算圖，云提供商對函數(shù)進(jìn)行定位最小化通信負(fù)擔(dān)（參考抽象挑戰(zhàn)）

注意前兩個(gè)proposal可能減少云提供商放置函數(shù)的靈活性，導(dǎo)致減少數(shù)據(jù)中心利用率。爭議地是，他們也通過逼迫開發(fā)者思考系統(tǒng)管理，違背了Serverless精神

4.4.安全挑戰(zhàn)

Serverless計(jì)算洗牌了安全職責(zé)，將他們從用戶轉(zhuǎn)嫁給了提供商，沒有從根本上改變他們。然而serverless計(jì)算還必須處理應(yīng)用和多租戶資源共享中內(nèi)在的風(fēng)險(xiǎn)。

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

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

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

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

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

4.5 計(jì)算架構(gòu)挑戰(zhàn)

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

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

如4.1提到的，我們看到serverless計(jì)算支持異構(gòu)硬件2條路：

Serverless擁抱多種實(shí)例類型，根據(jù)使用的硬件提供不同的計(jì)費(fèi)方式。

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

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

當(dāng)加速器變得更流行時(shí)，serverless提供商將不能夠忽視異構(gòu)的兩難境地，尤其是因?yàn)榇嬖诤侠淼难a(bǔ)償措施。

5.謬論和陷阱

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

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

陷阱計(jì)算可能會(huì)產(chǎn)生不可預(yù)測的成本。

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

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

不只是函數(shù)的調(diào)用原語和打包方式不同，而且serverless應(yīng)用還依賴于缺乏標(biāo)準(zhǔn)化的專有的BaaS產(chǎn)品生態(tài)系統(tǒng)。對象存儲(chǔ)，key value數(shù)據(jù)庫，認(rèn)證，日志和監(jiān)控這些是突出的例子。為了實(shí)現(xiàn)可移植性，用戶必須采用某種標(biāo)準(zhǔn)API，比如POSIX試圖為操作系統(tǒng)提供的API。來自Google的Knative項(xiàng)目是朝這個(gè)方向邁出的一步，旨在為應(yīng)用開發(fā)人員跨部署環(huán)境使用統(tǒng)一的原語

陷阱比起Serverful計(jì)算，serverless廠商鎖定可能非常強(qiáng)

這個(gè)陷阱是先前謬論的結(jié)果；如果移植很困難，那么很可能會(huì)出現(xiàn)供應(yīng)商鎖定。一些框架承諾通過跨云支持來減輕這種鎖定

謬論云函數(shù)不能處理需要能預(yù)測性能的低延遲應(yīng)用

serverful實(shí)例之所以能很好地處理這種低延遲的應(yīng)用程序，是因?yàn)樗鼈兛偸翘幱诖蜷_狀態(tài)，因此它們可以在收到請求時(shí)快速響應(yīng)請求。我們注意到，如果云功能的啟動(dòng)延遲對于給定的應(yīng)用程序來說不夠好，那么可以使用類似的策略：通過定期運(yùn)行來預(yù)熱云函數(shù)，以確保在給定時(shí)間內(nèi)有充足的運(yùn)行實(shí)例來處理請求。

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

如今彈性這個(gè)詞是個(gè)流行術(shù)語，但這個(gè)名字被應(yīng)用在那些不如serverless計(jì)算服務(wù)的服務(wù)上。

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

如果沒有一個(gè)量化的、被廣泛接受的技術(shù)定義或度量標(biāo)準(zhǔn)，用于幫助對比和構(gòu)成系統(tǒng)，那么彈性就還是一種不明確的描述。

6總結(jié)和預(yù)測

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

我們預(yù)測serverless的使用將激增，我們還預(yù)計(jì)，隨著時(shí)間的推移，混合云中的本地應(yīng)用程序?qū)⒅饾u減少。盡管由于監(jiān)管約束和數(shù)據(jù)治理規(guī)則，一些部署可能會(huì)持續(xù)保持現(xiàn)狀。[t27]

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

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

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

我們對serverless計(jì)算的下一個(gè)10年作了以下預(yù)測：

l 我們期望新的BaaS存儲(chǔ)服務(wù)，以擴(kuò)展在serverless計(jì)算上運(yùn)行良好的應(yīng)用類型。這樣的存儲(chǔ)將匹配本地塊的性能，有短暫和持久兩種。我們將看到用于serverless計(jì)算的異構(gòu)硬件遠(yuǎn)遠(yuǎn)超過今天為其提供動(dòng)力的傳統(tǒng)x86微處理器。

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

l 我們看不出serverless計(jì)算的成本高于serverful計(jì)算的基礎(chǔ)，所以我們預(yù)測計(jì)費(fèi)模型將會(huì)變化，任何規(guī)模的應(yīng)用消耗的成本都會(huì)更少。

l serverful計(jì)算的未來將是促進(jìn)BaaS的發(fā)展。在severless計(jì)算上很難編寫的應(yīng)用程序，比如OLTP數(shù)據(jù)庫和通過信原語如隊(duì)列，可能會(huì)是這種服務(wù)的一部分。

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

l serverless計(jì)算將成為云時(shí)代的默認(rèn)計(jì)算模式，在很大程度上取代了serverful計(jì)算，從而結(jié)束了客戶端-服務(wù)端時(shí)代

[t1]譯者：只要運(yùn)行便是在滿速運(yùn)轉(zhuǎn)的，跑在同一個(gè)資源池里進(jìn)行資源復(fù)用就行了

[t2]譯者：獨(dú)占資源池，平時(shí)閑置比較多，隨時(shí)待用，資源難以復(fù)用

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

[t4]譯者：新的收費(fèi)形式

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

[t6]譯者：這也是為啥早期云計(jì)算剛興起時(shí)，oracle等傳統(tǒng)服務(wù)器廠商搶著做云計(jì)算，VM的高效使得服務(wù)器可以大賣

[t7]譯者：領(lǐng)域相關(guān)，比如安防領(lǐng)域

[t8]譯者：不是無狀態(tài)，但也不是像數(shù)據(jù)庫那樣的重依賴于狀態(tài)的應(yīng)用

[t9]譯者：指的網(wǎng)絡(luò)延遲和高性能不適合

[t10]譯者：比如raft

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

[t12]譯者：這樣的話標(biāo)準(zhǔn)誰制定還是云廠商主動(dòng)適配？

[t13]譯者：Redis？

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

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

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

可能[t17]如重尾分布所說，呈現(xiàn)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]譯者：非常不錯(cuò)的收費(fèi)模式和安全策略，雖然違背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]譯者：這也阻礙一些業(yè)務(wù)向service mesh的轉(zhuǎn)型