Serverless計算應(yīng)該是什么樣的
現(xiàn)在讓我們把目光投向未來，分析如何將severless的優(yōu)勢帶給更多的應(yīng)用。研究者們已經(jīng)開始解決我們之前提到的諸多問題，并且嘗試去探索如何進一步改進serverless平臺和運行在它之上的工作負(fù)載。下面我們將給出困擾serverless計算應(yīng)用于更廣泛的硬件和軟件范圍的五大挑戰(zhàn)：抽象、系統(tǒng)、網(wǎng)絡(luò)、安全以及架構(gòu)。
4.1 抽象挑戰(zhàn)
資源需求： 今天的serverless平臺給開發(fā)者提供的cloud functions只包含內(nèi)存大小和執(zhí)行時間的限制，但是其他的資源是無法調(diào)控的。這對于那些想要控制更多指定資源（如CPU數(shù)，GPU數(shù)或加速器類型）的開發(fā)者來說是一個很大的阻礙。如果允許開發(fā)者明確地指定各種資源的需求，又會導(dǎo)致云供應(yīng)商無法很好的實現(xiàn)資源的高利用率，因為這會給函數(shù)的調(diào)度增加許多限制。而且這也違背了serverlss本身降低開發(fā)人員對服務(wù)器關(guān)注度的初衷。
一個更好的可選方案是提高抽象的層級，讓云供應(yīng)商來推斷函數(shù)服務(wù)的資源需求，而不是由開發(fā)者手動去聲明。要實現(xiàn)這一點，云供應(yīng)商可以使用很多手段，比如靜態(tài)代碼分析，歷史運行記錄分析，或者是動態(tài)地調(diào)整代碼運行的架構(gòu)。
給正在運行的程序自動分配適量的內(nèi)存是一個極具吸引力的終極目標(biāo)，然而要實現(xiàn)它卻充滿了挑戰(zhàn)性，因為必須和高級語言運行時環(huán)境的GC系統(tǒng)進行交互。有些研究表明這些語言的運行時環(huán)境(runtime)可以完全下沉到serverless平臺中，使二者成為一個整體。
數(shù)據(jù)依賴： 如今的云平臺還無法感知不同cloud functions之間的數(shù)據(jù)依賴，更不用說它們之間交互的數(shù)據(jù)量了。這種缺陷可能會通信模式的低效率，就像我們在第3部分中提到的那樣。
一種解決方案是由云供應(yīng)商來提供允許應(yīng)用聲明它們計算圖譜 (computation graph) 的API，來推斷能夠使通信成本最小化的放置方案。我們注意到許多通用的分布式框架（如MapReduce，Apache Spark，Apache Beam 和 Cloud Dataflow）、并行SQL引擎（如BigQUery，Azure CosmosDB）和一些調(diào)度框架（如Apache Airflow）早就在它們內(nèi)部應(yīng)用了計算圖譜。原則上來說，這些系統(tǒng)經(jīng)過改造后都可以運行在cloud functions上，并且向云供應(yīng)商暴露它們的計算圖譜。AWS Step Functions在此領(lǐng)域已經(jīng)有了一定的進展，它通過提供一種機器狀態(tài)語言和API的方式來解決此類問題。
4.2 系統(tǒng)挑戰(zhàn)
高性能，可負(fù)擔(dān)，可透明配置的儲存： 我們在第3部分中討論過兩類不同的無地址儲存訴求：Serverless短期儲存和Serverles持久儲存。
短期儲存：
在第3部分中提到的前四個應(yīng)用都受到了儲存系統(tǒng)的速度和延遲限制，盡管它們所需要的能力各有不同，但都需要一種在整個應(yīng)用聲明周期中維持應(yīng)用狀態(tài)的儲存。這樣的短期儲存在其他應(yīng)用中可能以緩存的方式存在，一旦應(yīng)用運行完畢，這些狀態(tài)就可以被銷毀。
一種給serverlss應(yīng)用提供短期儲存能力的方案是構(gòu)建一個分布式的內(nèi)存緩存服務(wù)，我們需要優(yōu)化網(wǎng)絡(luò)堆棧來保證毫秒級別的延遲，這樣系統(tǒng)就可以允許應(yīng)用函數(shù)在其生命周期內(nèi)更有效的儲存和交換狀態(tài)。對于這個內(nèi)存緩存服務(wù)，需要實現(xiàn)自動的縮擴容，并提供滿足應(yīng)用需求的IO吞吐能力。一種獨特的觀點是：通過它應(yīng)用不僅可以透明地分配內(nèi)存，也可以透明地釋放內(nèi)存。特別地，當(dāng)某個應(yīng)用終止或異常退出時，為其分配的短期儲存應(yīng)該被立刻釋放。這種管理手段和操作系統(tǒng)為進程自動分配和釋放內(nèi)存的功能有點類似。進一步地，這樣的儲存還必須為應(yīng)用提供訪問權(quán)限保護，并且對跨應(yīng)用的數(shù)據(jù)進行隔離。
RAMCloud 和 FaRM 已經(jīng)向我們展示了構(gòu)建具有毫米級延遲和萬級IOPS能力的內(nèi)存緩存系統(tǒng)的可能性，他們通過對整個系統(tǒng)進行精細(xì)優(yōu)化和RDMA技術(shù)的使用最大化的降低了延遲。不過仍然需要應(yīng)用提供儲存使用的聲明，而且也未能保證不同租戶之間的儲存強隔離。另一個產(chǎn)品Pocket目前正發(fā)力解決短期儲存的抽象問題，但也還是不能夠提供自動縮擴容的特性。
通過利用統(tǒng)計復(fù)用 (statistical multiplexing) 技術(shù)，serverless計算的短期儲存可以改造的比現(xiàn)在更加有效率。在serverful計算中，如果一個應(yīng)用使用的緩存空間只是為它分配的VM實例上內(nèi)存的一小部分，其余的內(nèi)存空間就都被浪費掉了。相對的，在serverless計算中，如果我們使用共享的內(nèi)存服務(wù) (shared in-memory service)，那么這些未被利用的內(nèi)存就可以被其他的應(yīng)用所使用。實際上，即便只有一個應(yīng)用在運行，它也可以從統(tǒng)計復(fù)用技術(shù)中獲利：在serverful計算中，一個VM上未被利用的內(nèi)存是不能夠被運行在其他VM上的程序所使用的，但如果使用共享的內(nèi)存服務(wù)，情況就不一樣了。當(dāng)然，在serverlss計算中，如果cloud functions不能很好地利用它們的本地內(nèi)存，也會產(chǎn)生許多的內(nèi)存碎片，在某些場景下，把cloud functions的應(yīng)用狀態(tài)存放在共享內(nèi)的存服務(wù)中可以緩解內(nèi)存碎片的問題。