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