作者 | 楊航

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

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

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

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

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

背景介紹

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

Lambda有什么限制

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

Lambda的特點(diǎn)

生命周期

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

同步 vs 異步

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

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

Lambda不適合的場景

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

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

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

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

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

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

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

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

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

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

• 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è)請求，當(dāng)超出60個(gè)請求后會創(chuàng)建新實(shí)例來處理。那么每天繁忙時(shí)段的花費(fèi)是 $2.30，非繁忙時(shí)段的花費(fèi)是$0.77，沒有調(diào)用時(shí)段的費(fèi)用是$0.34，每月總費(fèi)用是$102。對費(fèi)用詳情感興趣的讀者請移步App Runner Pricing頁面的Example3: High volume production app。

Lambda適合的場景

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

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

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

• Reliability: API Gateway加上SQS能夠保證足夠的高可用性，并且提供穩(wěn)定的低延遲，這對Webhook的監(jiān)聽器來說相當(dāng)重要，在Webhook設(shè)計(jì)里，如果監(jiān)聽器不能在短時(shí)間內(nèi)提供響應(yīng)，可能會被認(rèn)為是不健康的，導(dǎo)致對監(jiān)聽器進(jìn)行限流或屏蔽。
• Performance Efficiency: 上述服務(wù)提供了足夠的可擴(kuò)展性，保證監(jiān)聽器能夠應(yīng)對較大流量的變化，一般情況下無需提前預(yù)測流量來準(zhǔn)備基礎(chǔ)設(shè)施。
• Cost Optimization: 上述服務(wù)都是Serverless的服務(wù)，能夠做到按實(shí)際使用付費(fèi)，而無需為基礎(chǔ)設(shè)施付費(fèi)。
• Security: API Gateway和SQS自動(dòng)提供了HTTPS協(xié)議，保證數(shù)據(jù)傳輸安全;SQS和Lambda可通過IAM確保訪問控制，API Gateway可通過Authorizer或API Key來進(jìn)行訪問控制。
• Operational Excellence: 上述設(shè)計(jì)可完全通過Infrastructure as Code進(jìn)行部署，無需手動(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ǔ)充一些對Step Functions的說明。Step Functions是AWS提供的Serverless的狀態(tài)機(jī)服務(wù)，其中包含了等待的狀態(tài)，最長可等待1年的時(shí)間；AWS保證了等待的可靠性。Step Functions結(jié)合Lambda，可以針對單個(gè)任務(wù)去設(shè)置處理時(shí)間，不再需要批量掃描處理任務(wù)。Step Functions按照狀態(tài)變化收費(fèi)，等待時(shí)狀態(tài)并沒有發(fā)生變化，無需付費(fèi)，可有效降低費(fèi)用開銷。

寫在最后

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

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

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

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