Lambda是AWS推出的基于Function-as-a-Service(FaaS)的Serverless服務卿捎。我結合項目使用體驗，發(fā)現(xiàn)Lambda不適合或者說不能獨立支撐以下場景：
- 用戶期望穩(wěn)定的低延遲
- 請求需要在多個函數間跳轉
- 可預期的大量調用
與此同時，Lambda和其它AWS服務結合起來能為以下場景提供良好的解決方案：
- 作為監(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并非萬能良方疼阔，有其設計和功能上的限制戒劫，所以根據項目的使用情況和體驗，梳理了Lambda適合和不適合的場景竿开，分享給大家谱仪，供大家在技術選型時進行參考。
Lambda有什么限制
- 單請求模式：一個實例一次只能處理一個請求否彩，如果在處理完成前又有新的請求需要處理疯攒，Lambda需要創(chuàng)建一個新的實例來處理。
- 體積：一個函數解壓后體積不能超過250MB列荔，硬性限制敬尺；在使用Lambda時務必注意控制依賴枚尼，避免無用的依賴增大體積，并將靜態(tài)文件等從代碼庫中抽離砂吞。特別值得注意的是Lambda運行時自帶了aws-sdk署恍，除非需要指定SDK的版本，否則請勿將SDK打入部署包中蜻直。
- 并發(fā)數量：默認的一個帳戶的區(qū)域并發(fā)限制是1000盯质，也就是說可以同時處理1000個請求；可向AWS提出申請擴展到上萬概而。如果到達上限呼巷，新的請求會被節(jié)流。在大型項目中不同模塊請務必使用不同的帳號赎瑰，以隔離對并發(fā)的需求王悍，避免單模塊workload的波動影響到整個系統(tǒng)的穩(wěn)定性。可以通過Reserved Concurrency來限制單個函數并發(fā)數量餐曼，但同時會削減未設置Reserved Concurrency函數的并發(fā)上限压储。
- 超時時間：最大900秒的超時時間，不可更改源譬；如果在Happy Path時也不能判斷執(zhí)行時間少于900秒集惋，則需要拆分Lambda或者使用其它方案。
- 工具：Lambda有特定的部署方式瓶佳，需要工具來支持芋膘，才能保證完整的開發(fā)流程；可使用的工具包括CDK霸饲、SAM为朋、Serverless等。
Lambda的特點
生命周期
Lambda作為一種Serverless的計算服務厚脉，一個很重要的特點就是按需創(chuàng)建實例习寸，即在請求到來時創(chuàng)建實例來處理（冷啟動）。當實例處理完成請求后傻工，會保留一段時間霞溪，可以響應后續(xù)請求（熱啟動）。如果實例空閑超過一段時間中捆，就會被Lambda回收（AWS未明確提及回收的等待時間）鸯匹。AWS官方沒有給出狀態(tài)的標準名稱，我們這里用非標準的術語來描述生命周期泄伪，如下圖
同步 vs 異步
Lambda的函數有同步和異步兩種執(zhí)行模式殴蓬。在同步模式下，當我們執(zhí)行函數時蟋滴，Lambda會創(chuàng)建/復用實例染厅，并等待實例執(zhí)行完成后再返回結果痘绎；在異步模式下，Lambda會將請求加入隊列并立即返回肖粮，然后在后臺創(chuàng)建/復用實例進行處理孤页。使用異步模式時可以設置重試次數，并且如果重試后仍然不能成功涩馆，可以通過設置將失敗的請求發(fā)送到另外的地方行施，比如SNS的Topic。
很多AWS服務都能與Lambda進行集成凌净，需要查文檔來明確調用Lambda的方式悲龟，比如API Gateway是以同步模式調用Lambda，CloudWatch Event是以異步模式調用Lambda冰寻。
Lambda不適合的場景
用戶期望穩(wěn)定的低延遲
基于Lambda的生命周期，當有請求需要處理時皿渗，如果此時無可用實例斩芭，Lambda會初始化一個新實例并使用，也就是冷啟動乐疆。結合Lambda單請求模式的特點划乖，意味著一定會出現(xiàn)相當數量的冷啟動，請求的響應時間會摻雜著實例初始化時間挤土，出現(xiàn)延遲的波動琴庵。以項目經驗來看，一個不復雜的NodeJS實現(xiàn)的函數仰美，啟動時間大概在1-3秒區(qū)間內波動迷殿；這個區(qū)間數值來自于CloudWatch的日志輸出，實際體感時間可能更長咖杂，這部分時間會直接暴露給調用方庆寺。所以當一個場景需要提供持續(xù)穩(wěn)定的低延遲響應時，以同步方式調用Lambda并不合適诉字。
順帶一提懦尝，實例的啟動時間是很重要的，如有些傳統(tǒng)Java應用啟動就需要幾分鐘的壤圃，建議不要直接放上Lambda陵霉。
請求需要在多個實例間跳轉
如果一個請求需要以同步的形式在多個實例中跳轉，在最壞情況下伍绳，會成倍放大請求的延遲踊挠，并且成倍消耗并發(fā)數量。以項目經驗為例墨叛，有一個API Gateway -> Function A -> Function B -> 第三方系統(tǒng)的訪問鏈路止毕，在測試環(huán)境（用的人少模蜡，流量波動大）中，從頁面調用這個接口的時間基本上在8秒以上扁凛，有時會超過10秒忍疾，讓客戶懷疑系統(tǒng)的性能有問題。
以網狀結構設計的微服務模式應用谨朝，服務之間需要頻繁同步通信卤妒，放上Lambda需慎重。
可預期的大量調用
如果一個接口有大量的調用字币，那么基于Efficiency和Cost的考慮则披，Lambda未必是合適的選擇。
從一般性原則來講洗出，如果一個接口存在大量調用士复，那么為每次調用分配一個獨占的實例顯然不是一種明智的選擇，這樣會顯著放大單個實例的邊際開銷翩活。這種情況下阱洪，增加單個實例同時能處理的調用數量，能夠有效提高系統(tǒng)吞吐量菠镇，提升系統(tǒng)的整體效率冗荸。
從價格方面來考慮，Lambda使用的是基于調用次數計費的模型利耍，當調用次數增長到一定的閾值以上蚌本，其成本有效性必定會低于基于使用資源時長計費的模型。讓我們用一個虛擬的場景來對比Lambda和App Runner：假設有一個接口隘梨，每天有3個小時的繁忙時段處理600 RPS的調用刀诬，另有12個小時非繁忙時段處理60 RPS的調用澈蚌，其余時間沒有調用笔链；每次調用持續(xù)時間500ms纱注。兩種服務的價格對比如下：
Lambda: 基于128M內存的配置，每天有600x60x60x3 + 60x60x60x12 = 9072000次調用税稼，那么每月費用為$335.76烦秩。感興趣的讀者可以使用AWS Pricing Calculator自行計算。
App Runner: 基于1 vCPU和2G內存的配置郎仆，假設每個實例可以同時處理60個請求只祠，當超出60個請求后會創(chuàng)建新實例來處理。那么每天繁忙時段的花費是
0.77抛寝，沒有調用時段的費用是
102。對費用詳情感興趣的讀者請移步Example3: High volume production app盗舰。
Lambda適合的場景
作為監(jiān)聽器異步響應Webhook
很多第三方系統(tǒng)提供Webhook來進行通知晶府，并且一般Webhook的設計都是異步模式。這種場景可通過API Gateway钻趋，SQS和Lambda提供解決方案川陆。
讓我們按照AWS的5 Pillars來分析為什么這是一個良好的解決方案：
- Reliability: API Gateway加上SQS能夠保證足夠的高可用性，并且提供穩(wěn)定的低延遲蛮位，這對Webhook的監(jiān)聽器來說相當重要较沪，在Webhook設計里，如果監(jiān)聽器不能在短時間內提供響應失仁，可能會被認為是不健康的尸曼，導致對監(jiān)聽器進行限流或屏蔽。
- Performance Efficiency: 上述服務提供了足夠的可擴展性萄焦，保證監(jiān)聽器能夠應對較大流量的變化控轿，一般情況下無需提前預測流量來準備基礎設施。
- Cost Optimization: 上述服務都是Serverless的服務楷扬，能夠做到按實際使用付費解幽，而無需為基礎設施付費。
- Security: API Gateway和SQS自動提供了HTTPS協(xié)議烘苹，保證數據傳輸安全；SQS和Lambda可通過IAM確保訪問控制片部，API Gateway可通過Authorizer或API Key來進行訪問控制镣衡。
- Operational Excellence: 上述設計可完全通過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結合Lambda拙寡，可以針對單個任務去設置處理時間授滓，不再需要批量掃描處理任務。Step Functions按照狀態(tài)變化收費，等待時狀態(tài)并沒有發(fā)生變化般堆，無需付費在孝，可有效降低費用開銷。
寫在最后
Serverless的特性決定了實例無法避免冷啟動淮摔。Lambda支持同步和異步兩種調用模式私沮，以項目經驗來看，同步調用模式受冷啟動影響更大噩咪，有時會通過SQS將調用封裝成異步模式顾彰。在Serverless工具中甚至提供了Serverless WarmUp Plugin插件，通過定時調用避免冷啟動胃碾。AWS也提供了Provisioned Concurrency特性來維持熱實例涨享，減少冷啟動的次數。
Lambda的單請求模式是一個很大的限制仆百，既限制了實例的性能（比如使用NIO）厕隧，又導致實例需要更頻繁初始化。如果能夠改變單請求模式俄周，讓一個實例接受更多的請求吁讨，將會是一個很好的特性。
Lambda有一套獨立的生態(tài)系統(tǒng)峦朗，對代碼和部署都有特定的要求建丧，降低了代碼可移植性。
有沒有更好的選擇呢波势？筆者推薦讀者參考下GCP的Cloud Run服務翎朱，提供了Container-as-a-Service(CaaS)解決方案，能夠將鏡像以Serverless形式部署上去尺铣，通過指定實例的請求并發(fā)度拴曲，能顯著減少初始化新實例的次數。AWS也提供了類似的服務App Runner凛忿，不過目前只在美國澈灼、愛爾蘭和日本區(qū)域提供。
文/Thoughtworks楊航
原文鏈接： https://insights.thoughtworks.cn/lambda
更多精彩洞見店溢，請關注微信公眾號Thoughtworks洞見叁熔。
