建站
咨詢
售后
建站咨詢
新聞中心
Lambda是AWS推出的基于Function-as-a-Service(FaaS)的Serverless服務。我結(jié)合項目使用體驗，發(fā)現(xiàn)Lambda不適合或者說不能獨立支撐以下場景：
- 用戶期望穩(wěn)定的低延遲
- 請求需要在多個函數(shù)間跳轉(zhuǎn)
- 可預期的大量調(diào)用
與此同時，Lambda和其它AWS服務結(jié)合起來能為以下場景提供良好的解決方案：
- 作為監(jiān)聽器異步響應Webhook (API Gateway + SQS + Lambda)
- 處理需要延時執(zhí)行或指定時間執(zhí)行的任務 (Step Functions + SQS + Lambda)
Lambda僅支持單請求模式，可以考慮使用AWS的App Runner或者GCP的Cloud Run替代。
背景介紹
筆者參與的項目大量使用Lambda進行開發(fā)，Lambda所承擔的角色包括：作為AppServer支撐前端功能、監(jiān)聽第三方系統(tǒng)的Webhook，作為后臺程序執(zhí)行批處理任務，等等。在使用過程中，筆者感覺Lambda并非萬能良方，有其設(shè)計和功能上的限制，所以根據(jù)項目的使用情況和體驗，梳理了Lambda適合和不適合的場景，分享給大家，供大家在技術(shù)選型時進行參考。
Lambda有什么限制
- 單請求模式：一個實例一次只能處理一個請求，如果在處理完成前又有新的請求需要處理，Lambda需要創(chuàng)建一個新的實例來處理。
- 體積：一個函數(shù)解壓后體積不能超過250MB，硬性限制;在使用Lambda時務必注意控制依賴，避免無用的依賴增大體積，并將靜態(tài)文件等從代碼庫中抽離。特別值得注意的是Lambda運行時自帶了aws-sdk，除非需要指定SDK的版本，否則請勿將SDK打入部署包中。
- 并發(fā)數(shù)量：默認的一個帳戶的區(qū)域并發(fā)限制是1000，也就是說可以同時處理1000個請求;可向AWS提出申請擴展到上萬。如果到達上限，新的請求會被節(jié)流。在大型項目中不同模塊請務必使用不同的帳號，以隔離對并發(fā)的需求，避免單模塊workload的波動影響到整個系統(tǒng)的穩(wěn)定性。可以通過Reserved Concurrency來限制單個函數(shù)并發(fā)數(shù)量，但同時會削減未設(shè)置Reserved Concurrency函數(shù)的并發(fā)上限。
- 超時時間：最大900秒的超時時間，不可更改;如果在Happy Path時也不能判斷執(zhí)行時間少于900秒，則需要拆分Lambda或者使用其它方案。
- 工具：Lambda有特定的部署方式，需要工具來支持，才能保證完整的開發(fā)流程;可使用的工具包括CDK、SAM、Serverless等。
Lambda的特點
生命周期
Lambda作為一種Serverless的計算服務，一個很重要的特點就是按需創(chuàng)建實例，即在請求到來時創(chuàng)建實例來處理(冷啟動)。當實例處理完成請求后，會保留一段時間，可以響應后續(xù)請求(熱啟動)。如果實例空閑超過一段時間，就會被Lambda回收(AWS未明確提及回收的等待時間)。AWS官方?jīng)]有給出狀態(tài)的標準名稱，我們這里用非標準的術(shù)語來描述生命周期，如下圖：
同步 vs 異步
Lambda的函數(shù)有同步和異步兩種執(zhí)行模式。在同步模式下，當我們執(zhí)行函數(shù)時，Lambda會創(chuàng)建/復用實例，并等待實例執(zhí)行完成后再返回結(jié)果;在異步模式下，Lambda會將請求加入隊列并立即返回，然后在后臺創(chuàng)建/復用實例進行處理。使用異步模式時可以設(shè)置重試次數(shù)，并且如果重試后仍然不能成功，可以通過設(shè)置將失敗的請求發(fā)送到另外的地方，比如SNS的Topic。
很多AWS服務都能與Lambda進行集成，需要查文檔來明確調(diào)用Lambda的方式，比如API Gateway是以同步模式調(diào)用Lambda，CloudWatch Event是以異步模式調(diào)用Lambda。
Lambda不適合的場景
用戶期望穩(wěn)定的低延遲
基于Lambda的生命周期，當有請求需要處理時，如果此時無可用實例，Lambda會初始化一個新實例并使用，也就是冷啟動。結(jié)合Lambda單請求模式的特點，意味著一定會出現(xiàn)相當數(shù)量的冷啟動，請求的響應時間會摻雜著實例初始化時間，出現(xiàn)延遲的波動。以項目經(jīng)驗來看，一個不復雜的NodeJS實現(xiàn)的函數(shù)，啟動時間大概在1-3秒?yún)^(qū)間內(nèi)波動;這個區(qū)間數(shù)值來自于CloudWatch的日志輸出，實際體感時間可能更長，這部分時間會直接暴露給調(diào)用方。所以當一個場景需要提供持續(xù)穩(wěn)定的低延遲響應時，以同步方式調(diào)用Lambda并不合適。
順帶一提，實例的啟動時間是很重要的，如有些傳統(tǒng)Java應用啟動就需要幾分鐘的，建議不要直接放上Lambda。
請求需要在多個實例間跳轉(zhuǎn)
如果一個請求需要以同步的形式在多個實例中跳轉(zhuǎn)，在最壞情況下，會成倍放大請求的延遲，并且成倍消耗并發(fā)數(shù)量。以項目經(jīng)驗為例，有一個API Gateway -> Function A -> Function B -> 第三方系統(tǒng)的訪問鏈路，在測試環(huán)境(用的人少，流量波動大)中，從頁面調(diào)用這個接口的時間基本上在8秒以上，有時會超過10秒，讓客戶懷疑系統(tǒng)的性能有問題。
以網(wǎng)狀結(jié)構(gòu)設(shè)計的微服務模式應用，服務之間需要頻繁同步通信，放上Lambda需慎重。
可預期的大量調(diào)用
如果一個接口有大量的調(diào)用，那么基于Efficiency和Cost的考慮，Lambda未必是合適的選擇。
從一般性原則來講，如果一個接口存在大量調(diào)用，那么為每次調(diào)用分配一個獨占的實例顯然不是一種明智的選擇，這樣會顯著放大單個實例的邊際開銷。這種情況下，增加單個實例同時能處理的調(diào)用數(shù)量，能夠有效提高系統(tǒng)吞吐量，提升系統(tǒng)的整體效率。
從價格方面來考慮，Lambda使用的是基于調(diào)用次數(shù)計費的模型，當調(diào)用次數(shù)增長到一定的閾值以上，其成本有效性必定會低于基于使用資源時長計費的模型。讓我們用一個虛擬的場景來對比Lambda和App Runner：假設(shè)有一個接口，每天有3個小時的繁忙時段處理600 RPS的調(diào)用，另有12個小時非繁忙時段處理60 RPS的調(diào)用，其余時間沒有調(diào)用;每次調(diào)用持續(xù)時間500ms。兩種服務的價格對比如下：
- Lambda: 基于128M內(nèi)存的配置，每天有600*60*60*3 + 60*60*60*12 = 9072000次調(diào)用，那么每月費用為$335.76。感興趣的讀者可以使用AWS Pricing Calculator自行計算。
- App Runner: 基于1 vCPU和2G內(nèi)存的配置，假設(shè)每個實例可以同時處理60個請求，當超出60個請求后會創(chuàng)建新實例來處理。那么每天繁忙時段的花費是 $2.30，非繁忙時段的花費是$0.77，沒有調(diào)用時段的費用是$0.34，每月總費用是$102。對費用詳情感興趣的讀者請移步App Runner Pricing頁面的Example3: High volume production app。
Lambda適合的場景
作為監(jiān)聽器異步響應Webhook
很多第三方系統(tǒng)提供Webhook來進行通知，并且一般Webhook的設(shè)計都是異步模式。這種場景可通過API Gateway，SQS和Lambda提供解決方案。
讓我們按照AWS的5 Pillars來分析為什么這是一個良好的解決方案：
- Reliability: API Gateway加上SQS能夠保證足夠的高可用性，并且提供穩(wěn)定的低延遲，這對Webhook的監(jiān)聽器來說相當重要，在Webhook設(shè)計里，如果監(jiān)聽器不能在短時間內(nèi)提供響應，可能會被認為是不健康的，導致對監(jiān)聽器進行限流或屏蔽。
- Performance Efficiency: 上述服務提供了足夠的可擴展性，保證監(jiān)聽器能夠應對較大流量的變化，一般情況下無需提前預測流量來準備基礎(chǔ)設(shè)施。
- Cost Optimization: 上述服務都是Serverless的服務，能夠做到按實際使用付費，而無需為基礎(chǔ)設(shè)施付費。
- Security: API Gateway和SQS自動提供了HTTPS協(xié)議，保證數(shù)據(jù)傳輸安全;SQS和Lambda可通過IAM確保訪問控制，API Gateway可通過Authorizer或API Key來進行訪問控制。
- Operational Excellence: 上述設(shè)計可完全通過Infrastructure as Code進行部署，無需手動操作。
處理需要延時執(zhí)行或指定時間執(zhí)行的任務
有時候一個任務需要等待一段時間之后才執(zhí)行，或者到了一個特定的時間才執(zhí)行，相比用一個Long-run的服務去定時掃描處理，Step Functions、SQS加上Lambda提供了一種更高效的解決方案。
前述的優(yōu)點不再重復提及，這里補充一些對Step Functions的說明。Step Functions是AWS提供的Serverless的狀態(tài)機服務，其中包含了等待的狀態(tài)，最長可等待1年的時間；AWS保證了等待的可靠性。Step Functions結(jié)合Lambda，可以針對單個任務去設(shè)置處理時間，不再需要批量掃描處理任務。Step Functions按照狀態(tài)變化收費，等待時狀態(tài)并沒有發(fā)生變化，無需付費，可有效降低費用開銷。
寫在最后
Serverless的特性決定了實例無法避免冷啟動。Lambda支持同步和異步兩種調(diào)用模式，以項目經(jīng)驗來看，同步調(diào)用模式受冷啟動影響更大，有時會通過SQS將調(diào)用封裝成異步模式。在Serverless工具中甚至提供了Serverless WarmUp Plugin插件，通過定時調(diào)用避免冷啟動。AWS也提供了Provisioned Concurrency特性來維持熱實例，減少冷啟動的次數(shù)。
Lambda的單請求模式是一個很大的限制，既限制了實例的性能(比如使用NIO)，又導致實例需要更頻繁初始化。如果能夠改變單請求模式，讓一個實例接受更多的請求，將會是一個很好的特性。
Lambda有一套獨立的生態(tài)系統(tǒng)，對代碼和部署都有特定的要求，降低了代碼可移植性。
有沒有更好的選擇呢？筆者推薦讀者參考下GCP的Cloud Run服務，提供了Container-as-a-Service(CaaS)解決方案，能夠?qū)㈢R像以Serverless形式部署上去，通過指定實例的請求并發(fā)度，能顯著減少初始化新實例的次數(shù)。AWS也提供了類似的服務App Runner，不過目前只在美國、愛爾蘭和日本區(qū)域提供。
分享標題：什么場景（不）適合使用Lambda
文章鏈接：http://www.5511xx.com/article/dhhspeg.html
