作者 | 楊航

Lambda是AWS推出的基于Function-as-a-Service(FaaS)的Serverless服務。我結合項目使用體驗，發現Lambda不適合或者說不能獨立支撐以下場景：

• 用戶期望穩定的低延遲
• 請求需要在多個函數間跳轉
• 可預期的大量調用

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

• 作為監聽器異步響應Webhook (API Gateway + SQS + Lambda)
• 處理需要延時執行或指定時間執行的任務 (Step Functions + SQS + Lambda)

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

背景介紹

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

Lambda有什么限制

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

Lambda的特點

生命周期

Lambda作為一種Serverless的計算服務，一個很重要的特點就是按需創建實例，即在請求到來時創建實例來處理(冷啟動)。當實例處理完成請求后，會保留一段時間，可以響應后續請求(熱啟動)。如果實例空閑超過一段時間，就會被Lambda回收(AWS未明確提及回收的等待時間)。AWS官方沒有給出狀態的標準名稱，我們這里用非標準的術語來描述生命周期，如下圖：

同步 vs 異步

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

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

Lambda不適合的場景

用戶期望穩定的低延遲

基于Lambda的生命周期，當有請求需要處理時，如果此時無可用實例，Lambda會初始化一個新實例并使用，也就是冷啟動。結合Lambda單請求模式的特點，意味著一定會出現相當數量的冷啟動，請求的響應時間會摻雜著實例初始化時間，出現延遲的波動。以項目經驗來看，一個不復雜的NodeJS實現的函數，啟動時間大概在1-3秒區間內波動;這個區間數值來自于CloudWatch的日志輸出，實際體感時間可能更長，這部分時間會直接暴露給調用方。所以當一個場景需要提供持續穩定的低延遲響應時，以同步方式調用Lambda并不合適。

順帶一提，實例的啟動時間是很重要的，如有些傳統Java應用啟動就需要幾分鐘的，建議不要直接放上Lambda。

請求需要在多個實例間跳轉

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

以網狀結構設計的微服務模式應用，服務之間需要頻繁同步通信，放上Lambda需慎重。

可預期的大量調用

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

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

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

• Lambda: 基于128M內存的配置，每天有600*60*60*3 + 60*60*60*12 = 9072000次調用，那么每月費用為$335.76。感興趣的讀者可以使用AWS Pricing Calculator自行計算。
• App Runner: 基于1 vCPU和2G內存的配置，假設每個實例可以同時處理60個請求，當超出60個請求后會創建新實例來處理。那么每天繁忙時段的花費是 $2.30，非繁忙時段的花費是$0.77，沒有調用時段的費用是$0.34，每月總費用是$102。對費用詳情感興趣的讀者請移步App Runner Pricing頁面的Example3: High volume production app。

Lambda適合的場景

作為監聽器異步響應Webhook

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

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

• Reliability: API Gateway加上SQS能夠保證足夠的高可用性，并且提供穩定的低延遲，這對Webhook的監聽器來說相當重要，在Webhook設計里，如果監聽器不能在短時間內提供響應，可能會被認為是不健康的，導致對監聽器進行限流或屏蔽。
• Performance Efficiency: 上述服務提供了足夠的可擴展性，保證監聽器能夠應對較大流量的變化，一般情況下無需提前預測流量來準備基礎設施。
• Cost Optimization: 上述服務都是Serverless的服務，能夠做到按實際使用付費，而無需為基礎設施付費。
• Security: API Gateway和SQS自動提供了HTTPS協議，保證數據傳輸安全;SQS和Lambda可通過IAM確保訪問控制，API Gateway可通過Authorizer或API Key來進行訪問控制。
• Operational Excellence: 上述設計可完全通過Infrastructure as Code進行部署，無需手動操作。

處理需要延時執行或指定時間執行的任務

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

前述的優點不再重復提及，這里補充一些對Step Functions的說明。Step Functions是AWS提供的Serverless的狀態機服務，其中包含了等待的狀態，最長可等待1年的時間；AWS保證了等待的可靠性。Step Functions結合Lambda，可以針對單個任務去設置處理時間，不再需要批量掃描處理任務。Step Functions按照狀態變化收費，等待時狀態并沒有發生變化，無需付費，可有效降低費用開銷。

寫在最后

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

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

Lambda有一套獨立的生態系統，對代碼和部署都有特定的要求，降低了代碼可移植性。

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