1.3　Serverless的特點(diǎn)

1.3.1　優(yōu)勢(shì)與特點(diǎn)

前面已經(jīng)說(shuō)過(guò)，在云計(jì)算發(fā)展的過(guò)程中，從IaaS到PaaS再到SaaS的過(guò)程中，去服務(wù)器化已越來(lái)越明顯。

到了Serverless架構(gòu)，去服務(wù)器化已經(jīng)上升到了一個(gè)新的高度。所謂無(wú)服務(wù)器，不是說(shuō)脫離了服務(wù)器或者說(shuō)不需要服務(wù)器，而是指去除有關(guān)對(duì)服務(wù)器運(yùn)行狀態(tài)的關(guān)心和擔(dān)心。另外，Serverless架構(gòu)也一直在演進(jìn)，如圖1-14所示。

單體架構(gòu)時(shí)代的應(yīng)用比較簡(jiǎn)單，應(yīng)用的整體部署、業(yè)務(wù)的迭代更新，物理服務(wù)器的資源利用效率足以支撐業(yè)務(wù)的部署。隨著業(yè)務(wù)的復(fù)雜程度飆升，功能模塊復(fù)雜且龐大，單體架構(gòu)嚴(yán)重阻塞了開(kāi)發(fā)部署的效率，業(yè)務(wù)功能解耦，單獨(dú)模塊可并行開(kāi)發(fā)部署的微服務(wù)架構(gòu)逐漸流行開(kāi)來(lái)，業(yè)務(wù)的精細(xì)化管理不可避免地推動(dòng)著基礎(chǔ)資源利用率的提升。虛擬化技術(shù)打通了物理資源的隔閡，減輕了用戶管理基礎(chǔ)架構(gòu)的負(fù)擔(dān)。容器/PaaS平臺(tái)則進(jìn)一步抽象，提供了應(yīng)用的依賴服務(wù)、運(yùn)行環(huán)境和底層所需的計(jì)算資源，這使得應(yīng)用的開(kāi)發(fā)、部署和運(yùn)維的整體效率再度提升。Serverless架構(gòu)技術(shù)則將計(jì)算抽象得更加徹底，將應(yīng)用架構(gòu)棧中的各類資源的管理全部委托給平臺(tái)，免去基礎(chǔ)設(shè)施的運(yùn)維，使用戶能夠聚焦高價(jià)值的業(yè)務(wù)領(lǐng)域。而整個(gè)過(guò)程，實(shí)際上就是在訴求或者技術(shù)驅(qū)動(dòng)下向Serverless演進(jìn)。在伯克利團(tuán)隊(duì)發(fā)表的“Cloud Programming Simplified: A Berkeley View on Serverless Computing”一文中針對(duì)Serverful和Serverless也進(jìn)行了比較詳細(xì)的總結(jié)。

• 弱化了存儲(chǔ)和計(jì)算之間的聯(lián)系。服務(wù)的存儲(chǔ)和計(jì)算被分開(kāi)部署和收費(fèi)，存儲(chǔ)不再是服務(wù)本身的一部分，而是演變成了獨(dú)立的云服務(wù)，這使得計(jì)算變得無(wú)狀態(tài)化，更容易調(diào)度和擴(kuò)縮容，同時(shí)也降低了數(shù)據(jù)丟失的風(fēng)險(xiǎn)。
• 代碼的執(zhí)行不再需要手動(dòng)分配資源。不需要為服務(wù)的運(yùn)行指定需要的資源（比如使用幾臺(tái)機(jī)器、多大的帶寬、多大的磁盤(pán)等），只需要提供一份代碼，剩下的交由Serverless平臺(tái)去處理就行了。當(dāng)前階段實(shí)現(xiàn)平臺(tái)分配資源時(shí)還需要用戶方提供一些策略，例如單個(gè)實(shí)例的規(guī)格和最大并發(fā)數(shù)、單實(shí)例的最大CPU使用率。理想的情況是通過(guò)某些學(xué)習(xí)算法來(lái)進(jìn)行完全自動(dòng)的自適應(yīng)分配。
• 按使用量計(jì)費(fèi)。Serverless按照服務(wù)的使用量（調(diào)用次數(shù)、時(shí)長(zhǎng)等）計(jì)費(fèi)，而不是像傳統(tǒng)的Serverful服務(wù)那樣，按照使用的資源（ECS實(shí)例、VM的規(guī)格等）計(jì)費(fèi)。

Serverless架構(gòu)的優(yōu)點(diǎn)主要包括降低運(yùn)營(yíng)成本、降低開(kāi)發(fā)成本以及擁有優(yōu)秀的擴(kuò)展能力，更簡(jiǎn)單的管理以及符合“綠色”計(jì)算的思想。

在使用傳統(tǒng)服務(wù)器時(shí)可以發(fā)現(xiàn)，服務(wù)器每時(shí)每刻的用戶量是不同的，資源使用率也是不同的，可能白天資源使用率比較合理，夜間的時(shí)候就會(huì)出現(xiàn)大量的資源閑置問(wèn)題。按照《福布斯》雜志的統(tǒng)計(jì)，在商業(yè)和企業(yè)數(shù)據(jù)中心的典型服務(wù)器僅提供5%～15%的平均最大處理能力的輸出。這無(wú)疑是一種資源的巨大浪費(fèi)。而Serverless架構(gòu)的出現(xiàn)，則可以讓用戶委托服務(wù)提供商管理服務(wù)器、數(shù)據(jù)庫(kù)和應(yīng)用程序甚至邏輯，這樣一方面減少了用戶自己維護(hù)的麻煩，另一方面用戶可以根據(jù)自己實(shí)際使用函數(shù)的粒度進(jìn)行成本的支付。對(duì)于服務(wù)商而言，他們可以將更多的閑置資源進(jìn)行額外的處理，這從成本的角度、“綠色”計(jì)算的角度來(lái)說(shuō)，都是非常不錯(cuò)的。

如圖1-15所示，對(duì)于用戶和開(kāi)發(fā)者而言，Serverless架構(gòu)有降低人力成本、降低風(fēng)險(xiǎn)、減少資源開(kāi)銷(xiāo)、增加縮放靈活性、縮短創(chuàng)新周期等優(yōu)點(diǎn)，使用Serverless架構(gòu)，用戶不需要自己維護(hù)服務(wù)器，也不需要自己操心服務(wù)器的各種性能指標(biāo)和資源利用率，而是可以付出更多的時(shí)間和精力去關(guān)心和關(guān)注應(yīng)用程序本身的狀態(tài)和邏輯。同時(shí)Serverless應(yīng)用本身的部署十分容易，只要上傳基本的代碼即可，例如Python程序只需要上傳其邏輯與依賴包，C/C++、Go等語(yǔ)言只需上傳其二進(jìn)制文件，Java只需要上傳其Jar包等，無(wú)須使用Puppet、Chef、Ansible或Docker來(lái)進(jìn)行配置管理，這大大降低了運(yùn)維成本。對(duì)于運(yùn)維來(lái)說(shuō)，Serverless架構(gòu)也不再需要監(jiān)控底層的數(shù)據(jù)，例如磁盤(pán)使用量、CPU使用率等，可以更加專注地將監(jiān)控目光放到監(jiān)控應(yīng)用程序本身的度量。同時(shí)在Serverless架構(gòu)下，運(yùn)維人員的工作角色會(huì)有所轉(zhuǎn)變，部署將更加自動(dòng)化，監(jiān)控將更加面向應(yīng)用程序本身。

在降低風(fēng)險(xiǎn)層面，組件越多、結(jié)構(gòu)越復(fù)雜，系統(tǒng)出故障的風(fēng)險(xiǎn)就越大。而在Serverless架構(gòu)中，很多模塊都可以托管給服務(wù)商，例如存儲(chǔ)系統(tǒng)、API網(wǎng)關(guān)系統(tǒng)等，那些以前要自己維護(hù)的觸發(fā)模塊、路由模塊、存儲(chǔ)模塊也不再直接維護(hù)，如果出現(xiàn)問(wèn)題，可以交給服務(wù)商來(lái)處理，讓服務(wù)商的專業(yè)人員來(lái)處理有時(shí)候比自己來(lái)處理更可靠，利用專業(yè)人員的知識(shí)來(lái)降低停機(jī)的風(fēng)險(xiǎn)，縮短故障修復(fù)的時(shí)間，可以讓系統(tǒng)的穩(wěn)定性更高。當(dāng)然，這一點(diǎn)也充分說(shuō)明找到一個(gè)專業(yè)的服務(wù)商是非常有必要的。

亞馬遜AWS首席云計(jì)算技術(shù)顧問(wèn)費(fèi)良宏曾說(shuō)：今天大多數(shù)公司在開(kāi)發(fā)應(yīng)用程序并將其部署在服務(wù)器上的時(shí)候，無(wú)論是選擇公有云還是私有的數(shù)據(jù)中心，都需要提前了解究竟需要多少臺(tái)服務(wù)器、多大容量的存儲(chǔ)和什么樣的數(shù)據(jù)庫(kù)功能等，并需要部署運(yùn)行應(yīng)用程序和依賴的軟件到基礎(chǔ)設(shè)施之上。假設(shè)不想在這些細(xì)節(jié)上花費(fèi)精力，是否有一種簡(jiǎn)單的架構(gòu)模型能夠滿足這種想法？這個(gè)答案已經(jīng)存在，這就是今天軟件架構(gòu)世界中新鮮且熱門(mén)的一個(gè)話題——Serverless架構(gòu)。確實(shí)如此，在傳統(tǒng)項(xiàng)目上線過(guò)程中，需要申請(qǐng)主機(jī)資源，這時(shí)候一般會(huì)非常花時(shí)間和精力去評(píng)估一個(gè)峰值最大開(kāi)銷(xiāo)來(lái)申請(qǐng)資源，即使某些服務(wù)按照最大消耗去申請(qǐng)資源，也要有專人在不同時(shí)間段進(jìn)行資源的擴(kuò)容或縮容，以達(dá)到保障業(yè)務(wù)穩(wěn)定且降低成本的效果；而對(duì)于另一些服務(wù)來(lái)說(shuō)，有些時(shí)候申請(qǐng)的資源還需要在最大開(kāi)銷(xiāo)基礎(chǔ)上評(píng)估，即使可能出現(xiàn)很多流量波谷，并產(chǎn)生大量的資源浪費(fèi)，也不得不這樣去做，比如數(shù)據(jù)庫(kù)這種很難擴(kuò)展的應(yīng)用就是“盡管很多時(shí)候都覺(jué)得浪費(fèi)資源也比當(dāng)峰值到來(lái)時(shí)應(yīng)用程序因?yàn)橘Y源不足而無(wú)法服務(wù)好”。正如費(fèi)良宏所說(shuō)，在Serverless架構(gòu)下，這個(gè)問(wèn)題得到了比較好的解決，不計(jì)劃到底需要使用多少資源，而是根據(jù)實(shí)際需要來(lái)請(qǐng)求資源；根據(jù)使用時(shí)間來(lái)付費(fèi)，根據(jù)每次申請(qǐng)的計(jì)算資源來(lái)付費(fèi)，讓計(jì)費(fèi)的粒度更小，將更有利于降低資源的開(kāi)銷(xiāo)。這是對(duì)應(yīng)用程序本身的優(yōu)化，例如讓每次請(qǐng)求耗時(shí)更短，讓每次消耗的資源更少，能夠顯著節(jié)省成本。

CNCF也對(duì)Serverless架構(gòu)的優(yōu)點(diǎn)進(jìn)行了總結(jié)，認(rèn)為Serverless架構(gòu)擁有零服務(wù)器運(yùn)維和空閑時(shí)無(wú)計(jì)算成本兩個(gè)優(yōu)點(diǎn)，其中零服務(wù)器運(yùn)維指不需要配置、更新和管理服務(wù)器基礎(chǔ)架構(gòu)，并具有靈活的可擴(kuò)展性。

綜上所述，Serverless架構(gòu)的優(yōu)勢(shì)非常明顯。

• 降本提效。云廠商為使用者提供服務(wù)器的管理和運(yùn)維工作，為使用者提供數(shù)據(jù)庫(kù)、對(duì)象存儲(chǔ)等BaaS服務(wù)，讓用戶將更多的注意力放在自身的業(yè)務(wù)邏輯上，提升研發(fā)效率，縮短項(xiàng)目的創(chuàng)新周期。同時(shí)Serverless的使用者不用擔(dān)心服務(wù)器運(yùn)維、基礎(chǔ)設(shè)施運(yùn)維等工作，更不用承擔(dān)相應(yīng)的成本等。Serverless架構(gòu)提供了較為完善、全面的按量付費(fèi)模型，使用者只需按照自己實(shí)際使用的資源量付費(fèi)即可。
• 安全、方便、可靠。把更專業(yè)的事情交給更專業(yè)的人去做，Serverless架構(gòu)將更多服務(wù)器運(yùn)維、安全相關(guān)的事情交給云廠商來(lái)做，大規(guī)模提升項(xiàng)目整體的安全性。Serverless架構(gòu)明顯比其他架構(gòu)更簡(jiǎn)單，因?yàn)楦嗟腂aaS服務(wù)都是云廠商提供的，使用者將會(huì)管理更少的組件，這意味著Serverless的使用者可以更簡(jiǎn)單更方便地管理項(xiàng)目。另外，Serverless架構(gòu)擁有彈性能力，即自動(dòng)伸縮的能力，讓項(xiàng)目在流量增加的時(shí)候可自動(dòng)擴(kuò)容，在流量降低的時(shí)候可自動(dòng)縮容，進(jìn)而保證整個(gè)業(yè)務(wù)的安全、穩(wěn)定。

1.3.2　面臨的挑戰(zhàn)

當(dāng)然，事物并沒(méi)有十全十美的，Serverless架構(gòu)也不例外，在Serverless架構(gòu)為使用者提供全新的編程范式的同時(shí)，當(dāng)用戶在享受Serverless帶來(lái)的第一波技術(shù)紅利的時(shí)候，Serverless的缺點(diǎn)也逐漸地暴露了出來(lái)，例如函數(shù)的冷啟動(dòng)問(wèn)題，就是如今頗為嚴(yán)峻且備受關(guān)注的問(wèn)題。

由于Serverless架構(gòu)具有彈性伸縮的能力，Serverless服務(wù)的供應(yīng)商會(huì)根據(jù)用戶服務(wù)的流量波動(dòng)進(jìn)行實(shí)例的增加或縮減，其示意圖如圖1-16所示。

以阿里云函數(shù)計(jì)算為例，當(dāng)系統(tǒng)接收到第一個(gè)觸發(fā)函數(shù)的事件時(shí)，它將啟動(dòng)一個(gè)容器來(lái)運(yùn)行代碼。如果此時(shí)收到了新的事件，而第一個(gè)容器仍在處理上一個(gè)事件，平臺(tái)將啟動(dòng)第二個(gè)代碼實(shí)例來(lái)處理第二個(gè)事件，Serverless架構(gòu)的這種自動(dòng)的零管理水平縮放，將持續(xù)到有足夠的代碼實(shí)例來(lái)處理所有的工作負(fù)載為止。當(dāng)然，不僅僅是并發(fā)情況下會(huì)比較容易觸發(fā)函數(shù)冷啟動(dòng)，在函數(shù)的前后兩次觸發(fā)時(shí)間間隔超過(guò)了實(shí)例釋放時(shí)間的閾值時(shí)，也會(huì)觸發(fā)函數(shù)的冷啟動(dòng)，如圖1-17所示。

然而這里就涉及一個(gè)問(wèn)題，當(dāng)新的請(qǐng)求或者說(shuō)是事件到來(lái)時(shí)，在廣義上可能出現(xiàn)以下兩種情況。

• 存在空閑且可以直接復(fù)用的實(shí)例：熱啟動(dòng)。
• 不存在空閑且可以直接復(fù)用的實(shí)例：冷啟動(dòng)。

在本地執(zhí)行一個(gè)函數(shù)，通常情況下是環(huán)境都已經(jīng)準(zhǔn)備妥當(dāng)，每次執(zhí)行只需要執(zhí)行函數(shù)對(duì)應(yīng)的方法即可，但是Serverless架構(gòu)下并不是，本地與FaaS的函數(shù)調(diào)用區(qū)別示意圖如圖1-18所示。

在Serverless架構(gòu)下，開(kāi)發(fā)者提交代碼之后，通常情況下，代碼只會(huì)被持久化，并不會(huì)為其準(zhǔn)備執(zhí)行環(huán)境，所以當(dāng)函數(shù)第一次被觸發(fā)時(shí)會(huì)有一個(gè)比較漫長(zhǎng)的準(zhǔn)備環(huán)境的過(guò)程，這個(gè)過(guò)程包括把網(wǎng)絡(luò)的環(huán)境全部打通、將所需的文件和代碼等資源準(zhǔn)備好，這個(gè)從準(zhǔn)備環(huán)境開(kāi)始到函數(shù)被執(zhí)行的過(guò)程被稱為函數(shù)的冷啟動(dòng)。

New Relic網(wǎng)站上曾發(fā)表過(guò)一篇研究AWS Lambda冷啟動(dòng)時(shí)間的文章，其分析圖如圖1-19所示。

研究結(jié)果表明，當(dāng)對(duì)AWS Lambda發(fā)起請(qǐng)求時(shí)，大部分的請(qǐng)求都落在了50ms以內(nèi)，但還是有很多請(qǐng)求超過(guò)100ms甚至是150ms，這也充分說(shuō)明了冷啟動(dòng)的存在。不同廠商對(duì)于冷啟動(dòng)的優(yōu)化程度是不同的，曾有人對(duì)AWS Lambda、Azure Function以及Google Cloud Function三個(gè)工業(yè)級(jí)的Serverless架構(gòu)產(chǎn)品進(jìn)行過(guò)冷啟動(dòng)測(cè)試，并將函數(shù)啟動(dòng)劃分成四個(gè)部分，如圖1-20所示。

通過(guò)這四個(gè)部分，其實(shí)可以簡(jiǎn)單地區(qū)分出冷啟動(dòng)和熱啟動(dòng)的區(qū)別。冷啟動(dòng)包括準(zhǔn)備環(huán)境的過(guò)程，就是當(dāng)請(qǐng)求或者事件到來(lái)但沒(méi)有可復(fù)用的實(shí)例資源時(shí)，系統(tǒng)將會(huì)初始化環(huán)境，包括網(wǎng)絡(luò)環(huán)境、實(shí)例資源等，之后進(jìn)行一些文件的下載、系統(tǒng)配置，然后再裝載代碼和一些依賴，最后執(zhí)行代碼。而熱啟動(dòng)流程更短，它更多出現(xiàn)在廠商完成了實(shí)例的預(yù)熱或?qū)嵗膹?fù)用的情況下，相對(duì)冷啟動(dòng)而言，它的環(huán)境、配置、代碼都是準(zhǔn)備好的，只需要執(zhí)行代碼即可。通常情況下，熱啟動(dòng)都是毫秒級(jí)啟動(dòng)，而冷啟動(dòng)可能是百毫秒級(jí)、秒級(jí)。不僅不同廠商對(duì)于冷啟動(dòng)的優(yōu)化程度不同，同一廠商對(duì)不同語(yǔ)言的冷啟動(dòng)優(yōu)化、對(duì)同一種語(yǔ)言下不同依賴的優(yōu)化都是不同的，這也充分說(shuō)明各廠商也在通過(guò)一些規(guī)則和策略努力降低冷啟動(dòng)率。

如圖1-21所示，通常情況下，冷啟動(dòng)的解決方案包括幾個(gè)部分：實(shí)例復(fù)用、實(shí)例預(yù)熱以及資源池化。

從資源復(fù)用層面來(lái)說(shuō)，對(duì)實(shí)例的復(fù)用相對(duì)來(lái)說(shuō)比較重要，一個(gè)實(shí)例并不是在觸發(fā)完成之后就結(jié)束其生命周期，而是會(huì)繼續(xù)保留一段時(shí)間。在這段時(shí)間內(nèi)如果函數(shù)再次被觸發(fā)，那么可以優(yōu)先分配該實(shí)例來(lái)完成相應(yīng)的觸發(fā)請(qǐng)求。在這種情況下可以認(rèn)為函數(shù)的所有資源是準(zhǔn)備妥當(dāng)?shù)模恍枰賵?zhí)行對(duì)應(yīng)的方法即可，所以實(shí)例復(fù)用是大多數(shù)廠商都會(huì)采取的一個(gè)降低冷啟動(dòng)率的措施。在實(shí)例資源復(fù)用的方案中，實(shí)例靜默狀態(tài)下要被保留多久取決于廠商對(duì)成本的考量。保留時(shí)間過(guò)短會(huì)導(dǎo)致請(qǐng)求出現(xiàn)較為嚴(yán)重的冷啟動(dòng)問(wèn)題，影響用戶體驗(yàn)；實(shí)例長(zhǎng)期不被釋放則很難被合理地利用起來(lái)，會(huì)大幅度提高平臺(tái)整體成本。

從預(yù)熱層面來(lái)說(shuō)，解決函數(shù)冷啟動(dòng)問(wèn)題可以通過(guò)某些手段判斷用戶的函數(shù)在下一個(gè)時(shí)間段可能需要多少實(shí)例，并且進(jìn)行實(shí)例資源的提前準(zhǔn)備。函數(shù)預(yù)熱的方案是大部分云廠商所重視并不斷深入探索的方向，常見(jiàn)的預(yù)熱方案如圖1-22所示。

1）被動(dòng)預(yù)熱通常指的是非用戶主動(dòng)行為預(yù)熱，是系統(tǒng)自動(dòng)預(yù)熱函數(shù)的行為，主要包括規(guī)則預(yù)熱、算法預(yù)熱以及混合預(yù)熱，所謂的規(guī)則預(yù)熱是指設(shè)定一個(gè)實(shí)例數(shù)量范圍（例如每個(gè)函數(shù)同一時(shí)間點(diǎn)最低0個(gè)實(shí)例，最多300個(gè)實(shí)例），然后通過(guò)一個(gè)或幾個(gè)比例關(guān)系進(jìn)行函數(shù)下一時(shí)間段的實(shí)例數(shù)量的擴(kuò)縮。例如設(shè)定某個(gè)比例為1.3倍，當(dāng)前實(shí)例數(shù)量為110，實(shí)際活躍實(shí)例數(shù)量為100，那么實(shí)際活躍數(shù)量乘以所設(shè)定的比例的結(jié)果為130個(gè)實(shí)例，與當(dāng)前實(shí)際存在時(shí)110個(gè)實(shí)例相比需要額外擴(kuò)容20個(gè)實(shí)例，那么系統(tǒng)就會(huì)自動(dòng)將實(shí)例數(shù)量從110個(gè)提升到130個(gè)。這種做法在實(shí)例數(shù)量較多和較少的情況下會(huì)出現(xiàn)闊縮數(shù)量過(guò)大或過(guò)小的問(wèn)題（所以有部分廠商引入不同實(shí)例范圍內(nèi)采用不同的比例來(lái)解決這個(gè)問(wèn)題），在流量波動(dòng)較頻繁且波峰波谷相差較大的時(shí)候，該方案會(huì)出現(xiàn)預(yù)熱滯后的問(wèn)題。算法預(yù)熱實(shí)際上是根據(jù)函數(shù)之間的關(guān)系、函數(shù)的歷史特征進(jìn)行，通過(guò)深度學(xué)習(xí)等算法進(jìn)行下一時(shí)間段的實(shí)例的擴(kuò)縮操作，但是在實(shí)際生產(chǎn)過(guò)程中，環(huán)境是非常復(fù)雜的，對(duì)流量進(jìn)行一個(gè)較為精確的預(yù)測(cè)非常困難，所以算法預(yù)測(cè)的方案是很多人在探索但卻遲遲沒(méi)有落地的一個(gè)重要原因。還有一種方案是混合預(yù)熱，即將規(guī)則預(yù)熱與算法預(yù)熱進(jìn)行一個(gè)權(quán)重劃分，共同預(yù)測(cè)下一時(shí)間段的實(shí)例數(shù)量，并提前決定擴(kuò)縮行為和擴(kuò)縮數(shù)量等。

2）主動(dòng)預(yù)熱通常指的是用戶主動(dòng)進(jìn)行預(yù)熱的行為。由于被動(dòng)預(yù)熱在復(fù)雜環(huán)境下的不準(zhǔn)確性，所以很多云廠商提供了用戶手動(dòng)預(yù)留的能力，目前來(lái)說(shuō)主要分為簡(jiǎn)單配置和指標(biāo)配置兩種。所謂的簡(jiǎn)單配置就是設(shè)定預(yù)留的實(shí)例數(shù)量，或者某個(gè)時(shí)間范圍內(nèi)的預(yù)留實(shí)例數(shù)量，所預(yù)留的實(shí)例將會(huì)一直保持存活狀態(tài)，不會(huì)被釋放掉。另一種是指標(biāo)配置，即在簡(jiǎn)單配置基礎(chǔ)上，可以增加一些指標(biāo)，例如當(dāng)前預(yù)留的空閑容器數(shù)量小于某個(gè)值時(shí)進(jìn)行某個(gè)規(guī)律的擴(kuò)容，反之進(jìn)行某個(gè)規(guī)律的縮容等。通常情況下，用戶主動(dòng)預(yù)留模式比較適用于有計(jì)劃的活動(dòng)，例如某平臺(tái)在雙十一期間要進(jìn)行促銷(xiāo)活動(dòng)，那么可以設(shè)定雙十一期間的預(yù)留資源以保證高并發(fā)下系統(tǒng)良好的穩(wěn)定性和優(yōu)秀的響應(yīng)速度，通常情況下主動(dòng)預(yù)留可能會(huì)產(chǎn)生額外的費(fèi)用。

3）混合預(yù)熱，即將被動(dòng)預(yù)熱和主動(dòng)預(yù)熱按照一個(gè)權(quán)重關(guān)系進(jìn)行結(jié)合。如果用戶配置了主動(dòng)預(yù)熱規(guī)則，就執(zhí)行主動(dòng)預(yù)熱規(guī)則，輔助被動(dòng)預(yù)熱規(guī)則；如果用戶沒(méi)有配置主動(dòng)預(yù)熱規(guī)則，就使用默認(rèn)的被動(dòng)預(yù)熱規(guī)則。

最后一種解決冷啟動(dòng)問(wèn)題的方法是資源池化，但是通常情況下這種所謂的資源池化帶來(lái)的效果可能不是熱啟動(dòng)，可能是溫啟動(dòng)。所謂的溫啟動(dòng)是指實(shí)例所需要的相關(guān)資源已經(jīng)提前準(zhǔn)備了，但是并沒(méi)有完全準(zhǔn)備好的情況。所謂的池化就是在實(shí)例從零到一的過(guò)程中所進(jìn)行的每一步準(zhǔn)備工作，如圖1-23所示。

池化的好處是可以降低實(shí)例啟動(dòng)的鏈路出現(xiàn)完全冷啟動(dòng)的概率，例如VPC層面的池化，可以避免底層資源準(zhǔn)備時(shí)產(chǎn)生的時(shí)間消耗，讓啟動(dòng)速度更快。同時(shí)池化也可以更加靈活地面對(duì)更多情況，例如在運(yùn)行時(shí)層面的池化，可以將池化的實(shí)例分配給不同的函數(shù)，不同函數(shù)被觸發(fā)的時(shí)候，可以優(yōu)先使用池化資源，達(dá)到更快的啟動(dòng)速度。當(dāng)然池化也是一門(mén)學(xué)問(wèn)，例如池化的資源規(guī)格、運(yùn)行時(shí)的種類、池化的數(shù)量以及資源的分配和調(diào)度等。

通常情況下，在冷啟動(dòng)的過(guò)程中，比較耗時(shí)的環(huán)節(jié)包括網(wǎng)絡(luò)資源的打通、實(shí)例的底層資源的準(zhǔn)備以及運(yùn)行時(shí)等準(zhǔn)備。除此之外，對(duì)一個(gè)實(shí)例冷啟動(dòng)有一定影響的還有代碼包的大小，過(guò)大的代碼包可能會(huì)導(dǎo)致下載代碼時(shí)間變長(zhǎng)，進(jìn)一步導(dǎo)致冷啟動(dòng)現(xiàn)象嚴(yán)重。

除了冷啟動(dòng)之外，Serverless架構(gòu)還存在著廠商鎖定等比較嚴(yán)重的問(wèn)題。廠商鎖定問(wèn)題是很多人非常在意的，由于函數(shù)計(jì)算需要依靠事件觸發(fā)，所以事件源以及函數(shù)本身與事件源規(guī)約的數(shù)據(jù)結(jié)構(gòu)就顯得格外重要。以對(duì)象存儲(chǔ)為例，對(duì)象存儲(chǔ)與函數(shù)計(jì)算所規(guī)約的數(shù)據(jù)結(jié)構(gòu)，不同廠商的數(shù)據(jù)格式就是不同的。

這就意味著業(yè)務(wù)邏輯可能需要針對(duì)不同廠商進(jìn)行適配，除此之外很多事件源是不能跨運(yùn)營(yíng)商觸發(fā)的，所以這對(duì)業(yè)務(wù)遷移、多云部署等操作實(shí)際上是有一定影響的。

除了廠商鎖定之外，Serverless目前缺少完備的開(kāi)發(fā)者工具，這也是比較大的問(wèn)題，會(huì)在不同程度上影響函數(shù)的調(diào)試和部署、依賴的安裝、相關(guān)日志的查看以及函數(shù)資源的管理。為了改善這個(gè)問(wèn)題，目前各個(gè)云廠商都在針對(duì)自身產(chǎn)品的特點(diǎn)建立自己的工具鏈體系，例如AWS Lambda的SAM、阿里云函數(shù)計(jì)算的Funcraft等。當(dāng)然，除了各個(gè)廠商自己針對(duì)自身所推出的開(kāi)發(fā)者工具，也有一些通用性比較強(qiáng)的多云Serverless開(kāi)發(fā)者工具，例如阿里云開(kāi)源的Serverless Devs等。

綜上所述，Serverless架構(gòu)擁有諸多優(yōu)點(diǎn)，也面臨一些困難和挑戰(zhàn)，包括但不限于函數(shù)冷啟動(dòng)問(wèn)題嚴(yán)重、開(kāi)發(fā)工具不完善、廠商鎖定嚴(yán)重等問(wèn)題。Serverless架構(gòu)雖然已出現(xiàn)了很多年，但是真正步入“元年”并得以快速發(fā)展的時(shí)間其實(shí)還是比較短的，但不可否認(rèn)的是，近些年Serverless架構(gòu)的熱度在持續(xù)上升，人們對(duì)它寄予厚望，各個(gè)廠商對(duì)其投入也非常大，目前所遇到的問(wèn)題也都是短暫的，Serverless架構(gòu)會(huì)朝著更好用、更易用的方向不斷演進(jìn)。