作者 | 楊航

Lambda是AWS推出的基于Function-as-a-Service(FaaS)的Serverless服務(wù)。我結(jié)合項(xiàng)目使用體驗(yàn)，發(fā)現(xiàn)Lambda不適合或者說(shuō)不能獨(dú)立支撐以下場(chǎng)景：

• 用戶期望穩(wěn)定的低延遲
• 請(qǐng)求需要在多個(gè)函數(shù)間跳轉(zhuǎn)
• 可預(yù)期的大量調(diào)用

與此同時(shí)，Lambda和其它AWS服務(wù)結(jié)合起來(lái)能為以下場(chǎng)景提供良好的解決方案：

• 作為監(jiān)聽(tīng)器異步響應(yīng)Webhook (API Gateway + SQS + Lambda)
• 處理需要延時(shí)執(zhí)行或指定時(shí)間執(zhí)行的任務(wù) (Step Functions + SQS + Lambda)

Lambda僅支持單請(qǐng)求模式，可以考慮使用AWS的App Runner或者GCP的Cloud Run替代。

背景介紹

筆者參與的項(xiàng)目大量使用Lambda進(jìn)行開(kāi)發(fā)，Lambda所承擔(dān)的角色包括：作為AppServer支撐前端功能、監(jiān)聽(tīng)第三方系統(tǒng)的Webhook，作為后臺(tái)程序執(zhí)行批處理任務(wù)，等等。在使用過(guò)程中，筆者感覺(jué)Lambda并非萬(wàn)能良方，有其設(shè)計(jì)和功能上的限制，所以根據(jù)項(xiàng)目的使用情況和體驗(yàn)，梳理了Lambda適合和不適合的場(chǎng)景，分享給大家，供大家在技術(shù)選型時(shí)進(jìn)行參考。

Lambda有什么限制

• 單請(qǐng)求模式：一個(gè)實(shí)例一次只能處理一個(gè)請(qǐng)求，如果在處理完成前又有新的請(qǐng)求需要處理，Lambda需要?jiǎng)?chuàng)建一個(gè)新的實(shí)例來(lái)處理。
• 體積：一個(gè)函數(shù)解壓后體積不能超過(guò)250MB，硬性限制;在使用Lambda時(shí)務(wù)必注意控制依賴(lài)，避免無(wú)用的依賴(lài)增大體積，并將靜態(tài)文件等從代碼庫(kù)中抽離。特別值得注意的是Lambda運(yùn)行時(shí)自帶了aws-sdk，除非需要指定SDK的版本，否則請(qǐng)勿將SDK打入部署包中。
• 并發(fā)數(shù)量：默認(rèn)的一個(gè)帳戶的區(qū)域并發(fā)限制是1000，也就是說(shuō)可以同時(shí)處理1000個(gè)請(qǐng)求;可向AWS提出申請(qǐng)擴(kuò)展到上萬(wàn)。如果到達(dá)上限，新的請(qǐng)求會(huì)被節(jié)流。在大型項(xiàng)目中不同模塊請(qǐng)務(wù)必使用不同的帳號(hào)，以隔離對(duì)并發(fā)的需求，避免單模塊workload的波動(dòng)影響到整個(gè)系統(tǒng)的穩(wěn)定性?？梢酝ㄟ^(guò)Reserved Concurrency來(lái)限制單個(gè)函數(shù)并發(fā)數(shù)量，但同時(shí)會(huì)削減未設(shè)置Reserved Concurrency函數(shù)的并發(fā)上限。
• 超時(shí)時(shí)間：最大900秒的超時(shí)時(shí)間，不可更改;如果在Happy Path時(shí)也不能判斷執(zhí)行時(shí)間少于900秒，則需要拆分Lambda或者使用其它方案。
• 工具：Lambda有特定的部署方式，需要工具來(lái)支持，才能保證完整的開(kāi)發(fā)流程;可使用的工具包括CDK、SAM、Serverless等。

Lambda的特點(diǎn)

生命周期

Lambda作為一種Serverless的計(jì)算服務(wù)，一個(gè)很重要的特點(diǎn)就是按需創(chuàng)建實(shí)例，即在請(qǐng)求到來(lái)時(shí)創(chuàng)建實(shí)例來(lái)處理(冷啟動(dòng))。當(dāng)實(shí)例處理完成請(qǐng)求后，會(huì)保留一段時(shí)間，可以響應(yīng)后續(xù)請(qǐng)求(熱啟動(dòng))。如果實(shí)例空閑超過(guò)一段時(shí)間，就會(huì)被Lambda回收(AWS未明確提及回收的等待時(shí)間)。AWS官方?jīng)]有給出狀態(tài)的標(biāo)準(zhǔn)名稱(chēng)，我們這里用非標(biāo)準(zhǔn)的術(shù)語(yǔ)來(lái)描述生命周期，如下圖：

同步 vs 異步

Lambda的函數(shù)有同步和異步兩種執(zhí)行模式。在同步模式下，當(dāng)我們執(zhí)行函數(shù)時(shí)，Lambda會(huì)創(chuàng)建/復(fù)用實(shí)例，并等待實(shí)例執(zhí)行完成后再返回結(jié)果;在異步模式下，Lambda會(huì)將請(qǐng)求加入隊(duì)列并立即返回，然后在后臺(tái)創(chuàng)建/復(fù)用實(shí)例進(jìn)行處理。使用異步模式時(shí)可以設(shè)置重試次數(shù)，并且如果重試后仍然不能成功，可以通過(guò)設(shè)置將失敗的請(qǐng)求發(fā)送到另外的地方，比如SNS的Topic。

很多AWS服務(wù)都能與Lambda進(jìn)行集成，需要查文檔來(lái)明確調(diào)用Lambda的方式，比如API Gateway是以同步模式調(diào)用Lambda，CloudWatch Event是以異步模式調(diào)用Lambda。

Lambda不適合的場(chǎng)景

用戶期望穩(wěn)定的低延遲

基于Lambda的生命周期，當(dāng)有請(qǐng)求需要處理時(shí)，如果此時(shí)無(wú)可用實(shí)例，Lambda會(huì)初始化一個(gè)新實(shí)例并使用，也就是冷啟動(dòng)。結(jié)合Lambda單請(qǐng)求模式的特點(diǎn)，意味著一定會(huì)出現(xiàn)相當(dāng)數(shù)量的冷啟動(dòng)，請(qǐng)求的響應(yīng)時(shí)間會(huì)摻雜著實(shí)例初始化時(shí)間，出現(xiàn)延遲的波動(dòng)。以項(xiàng)目經(jīng)驗(yàn)來(lái)看，一個(gè)不復(fù)雜的NodeJS實(shí)現(xiàn)的函數(shù)，啟動(dòng)時(shí)間大概在1-3秒?yún)^(qū)間內(nèi)波動(dòng);這個(gè)區(qū)間數(shù)值來(lái)自于CloudWatch的日志輸出，實(shí)際體感時(shí)間可能更長(zhǎng)，這部分時(shí)間會(huì)直接暴露給調(diào)用方。所以當(dāng)一個(gè)場(chǎng)景需要提供持續(xù)穩(wěn)定的低延遲響應(yīng)時(shí)，以同步方式調(diào)用Lambda并不合適。

順帶一提，實(shí)例的啟動(dòng)時(shí)間是很重要的，如有些傳統(tǒng)Java應(yīng)用啟動(dòng)就需要幾分鐘的，建議不要直接放上Lambda。

請(qǐng)求需要在多個(gè)實(shí)例間跳轉(zhuǎn)

如果一個(gè)請(qǐng)求需要以同步的形式在多個(gè)實(shí)例中跳轉(zhuǎn)，在最壞情況下，會(huì)成倍放大請(qǐng)求的延遲，并且成倍消耗并發(fā)數(shù)量。以項(xiàng)目經(jīng)驗(yàn)為例，有一個(gè)API Gateway -> Function A -> Function B -> 第三方系統(tǒng)的訪問(wèn)鏈路，在測(cè)試環(huán)境(用的人少，流量波動(dòng)大)中，從頁(yè)面調(diào)用這個(gè)接口的時(shí)間基本上在8秒以上，有時(shí)會(huì)超過(guò)10秒，讓客戶懷疑系統(tǒng)的性能有問(wèn)題。

以網(wǎng)狀結(jié)構(gòu)設(shè)計(jì)的微服務(wù)模式應(yīng)用，服務(wù)之間需要頻繁同步通信，放上Lambda需慎重。

可預(yù)期的大量調(diào)用

如果一個(gè)接口有大量的調(diào)用，那么基于Efficiency和Cost的考慮，Lambda未必是合適的選擇。

從一般性原則來(lái)講，如果一個(gè)接口存在大量調(diào)用，那么為每次調(diào)用分配一個(gè)獨(dú)占的實(shí)例顯然不是一種明智的選擇，這樣會(huì)顯著放大單個(gè)實(shí)例的邊際開(kāi)銷(xiāo)。這種情況下，增加單個(gè)實(shí)例同時(shí)能處理的調(diào)用數(shù)量，能夠有效提高系統(tǒng)吞吐量，提升系統(tǒng)的整體效率。

從價(jià)格方面來(lái)考慮，Lambda使用的是基于調(diào)用次數(shù)計(jì)費(fèi)的模型，當(dāng)調(diào)用次數(shù)增長(zhǎng)到一定的閾值以上，其成本有效性必定會(huì)低于基于使用資源時(shí)長(zhǎng)計(jì)費(fèi)的模型。讓我們用一個(gè)虛擬的場(chǎng)景來(lái)對(duì)比Lambda和App Runner：假設(shè)有一個(gè)接口，每天有3個(gè)小時(shí)的繁忙時(shí)段處理600 RPS的調(diào)用，另有12個(gè)小時(shí)非繁忙時(shí)段處理60 RPS的調(diào)用，其余時(shí)間沒(méi)有調(diào)用;每次調(diào)用持續(xù)時(shí)間500ms。兩種服務(wù)的價(jià)格對(duì)比如下：

• Lambda: 基于128M內(nèi)存的配置，每天有600*60*60*3 + 60*60*60*12 = 9072000次調(diào)用，那么每月費(fèi)用為$335.76。感興趣的讀者可以使用AWS Pricing Calculator自行計(jì)算。
• App Runner: 基于1 vCPU和2G內(nèi)存的配置，假設(shè)每個(gè)實(shí)例可以同時(shí)處理60個(gè)請(qǐng)求，當(dāng)超出60個(gè)請(qǐng)求后會(huì)創(chuàng)建新實(shí)例來(lái)處理。那么每天繁忙時(shí)段的花費(fèi)是 $2.30，非繁忙時(shí)段的花費(fèi)是$0.77，沒(méi)有調(diào)用時(shí)段的費(fèi)用是$0.34，每月總費(fèi)用是$102。對(duì)費(fèi)用詳情感興趣的讀者請(qǐng)移步App Runner Pricing頁(yè)面的Example3: High volume production app。

Lambda適合的場(chǎng)景

作為監(jiān)聽(tīng)器異步響應(yīng)Webhook

很多第三方系統(tǒng)提供Webhook來(lái)進(jìn)行通知，并且一般Webhook的設(shè)計(jì)都是異步模式。這種場(chǎng)景可通過(guò)API Gateway，SQS和Lambda提供解決方案。

讓我們按照AWS的5 Pillars來(lái)分析為什么這是一個(gè)良好的解決方案：

• Reliability: API Gateway加上SQS能夠保證足夠的高可用性，并且提供穩(wěn)定的低延遲，這對(duì)Webhook的監(jiān)聽(tīng)器來(lái)說(shuō)相當(dāng)重要，在Webhook設(shè)計(jì)里，如果監(jiān)聽(tīng)器不能在短時(shí)間內(nèi)提供響應(yīng)，可能會(huì)被認(rèn)為是不健康的，導(dǎo)致對(duì)監(jiān)聽(tīng)器進(jìn)行限流或屏蔽。
• Performance Efficiency: 上述服務(wù)提供了足夠的可擴(kuò)展性，保證監(jiān)聽(tīng)器能夠應(yīng)對(duì)較大流量的變化，一般情況下無(wú)需提前預(yù)測(cè)流量來(lái)準(zhǔn)備基礎(chǔ)設(shè)施。
• Cost Optimization: 上述服務(wù)都是Serverless的服務(wù)，能夠做到按實(shí)際使用付費(fèi)，而無(wú)需為基礎(chǔ)設(shè)施付費(fèi)。
• Security: API Gateway和SQS自動(dòng)提供了HTTPS協(xié)議，保證數(shù)據(jù)傳輸安全;SQS和Lambda可通過(guò)IAM確保訪問(wèn)控制，API Gateway可通過(guò)Authorizer或API Key來(lái)進(jìn)行訪問(wèn)控制。
• Operational Excellence: 上述設(shè)計(jì)可完全通過(guò)Infrastructure as Code進(jìn)行部署，無(wú)需手動(dòng)操作。

處理需要延時(shí)執(zhí)行或指定時(shí)間執(zhí)行的任務(wù)

有時(shí)候一個(gè)任務(wù)需要等待一段時(shí)間之后才執(zhí)行，或者到了一個(gè)特定的時(shí)間才執(zhí)行，相比用一個(gè)Long-run的服務(wù)去定時(shí)掃描處理，Step Functions、SQS加上Lambda提供了一種更高效的解決方案。

前述的優(yōu)點(diǎn)不再重復(fù)提及，這里補(bǔ)充一些對(duì)Step Functions的說(shuō)明。Step Functions是AWS提供的Serverless的狀態(tài)機(jī)服務(wù)，其中包含了等待的狀態(tài)，最長(zhǎng)可等待1年的時(shí)間；AWS保證了等待的可靠性。Step Functions結(jié)合Lambda，可以針對(duì)單個(gè)任務(wù)去設(shè)置處理時(shí)間，不再需要批量掃描處理任務(wù)。Step Functions按照狀態(tài)變化收費(fèi)，等待時(shí)狀態(tài)并沒(méi)有發(fā)生變化，無(wú)需付費(fèi)，可有效降低費(fèi)用開(kāi)銷(xiāo)。

寫(xiě)在最后

Serverless的特性決定了實(shí)例無(wú)法避免冷啟動(dòng)。Lambda支持同步和異步兩種調(diào)用模式，以項(xiàng)目經(jīng)驗(yàn)來(lái)看，同步調(diào)用模式受冷啟動(dòng)影響更大，有時(shí)會(huì)通過(guò)SQS將調(diào)用封裝成異步模式。在Serverless工具中甚至提供了Serverless WarmUp Plugin插件，通過(guò)定時(shí)調(diào)用避免冷啟動(dòng)。AWS也提供了Provisioned Concurrency特性來(lái)維持熱實(shí)例，減少冷啟動(dòng)的次數(shù)。

Lambda的單請(qǐng)求模式是一個(gè)很大的限制，既限制了實(shí)例的性能(比如使用NIO)，又導(dǎo)致實(shí)例需要更頻繁初始化。如果能夠改變單請(qǐng)求模式，讓一個(gè)實(shí)例接受更多的請(qǐng)求，將會(huì)是一個(gè)很好的特性。

Lambda有一套獨(dú)立的生態(tài)系統(tǒng)，對(duì)代碼和部署都有特定的要求，降低了代碼可移植性。

有沒(méi)有更好的選擇呢？筆者推薦讀者參考下GCP的Cloud Run服務(wù)，提供了Container-as-a-Service(CaaS)解決方案，能夠?qū)㈢R像以Serverless形式部署上去，通過(guò)指定實(shí)例的請(qǐng)求并發(fā)度，能顯著減少初始化新實(shí)例的次數(shù)。AWS也提供了類(lèi)似的服務(wù)App Runner，不過(guò)目前只在美國(guó)、愛(ài)爾蘭和日本區(qū)域提供。