什麼是AWS Lambda

AWS Lambda 是一項計算服務，可使您無需預配置或管理伺服器即可執行程式碼。AWS Lambda 只在需要時執行您的程式碼並自動縮放，從每天幾個請求到每秒數千個請求。您只需按消耗的計算時間付費 – 程式碼未執行時不產生費用。藉助 AWS Lambda，您幾乎可以為任何型別的應用程式或後端服務執行程式碼，並且不必進行任何管理。AWS Lambda 在可用性高的計算基礎設施上執行您的程式碼，執行計算資源的所有管理工作，其中包括伺服器和作業系統維護、容量預置和自動擴充套件、程式碼監控和記錄。您只需要以 AWS Lambda 支援的一種語言 (目前為 Node.js、Java、C#、Go 和 Python) 提供您的程式碼。

您可以使用 AWS Lambda 執行程式碼以響應事件，例如更改 Amazon S3 儲存桶或 Amazon DynamoDB 表中的資料；以及使用 Amazon API Gateway 執行程式碼以響應 HTTP 請求；或者使用通過 AWS SDK 完成的 API 呼叫來呼叫您的程式碼。藉助這些功能，您可以使用 Lambda 輕鬆地為 Amazon S3 和 Amazon DynamoDB 等 AWS 服務構建資料處理觸發程式，處理 Kinesis 中儲存的流資料，或建立您自己的按 AWS 規模、效能和安全性執行的後端。

您也可以構建由事件觸發的函式組成的無伺服器應用程式，並使用 CodePipeline 和 AWS CodeBuild 自動部署這些應用程式。

使用 AWS Lambda，您無需預置或管理伺服器即可執行程式碼。您只需為使用的計算時間付費，在程式碼未執行期間不產生任何費用。您可以為幾乎任何型別的應用程式或後端服務執行程式碼，而無需任何管理。只需上傳您的程式碼，Lambda 會處理執行和擴充套件高可用性程式碼所需的一切工作。您可以將您的程式碼設定為自動從其他 AWS 產品觸發，或者直接從任何 Web 或移動應用程式呼叫。

特點

更快的開發和部署。區別於整體(monolith)結構的構建方式，FaaS提供了更靈活的替代方案。開發人員可以編寫一組，由不同功能函式所組成的程式碼，而不是將整體應用的程式碼上傳到伺服器上。因此，這使得整個結構更易於除錯、更新和新增新的功能。
減少人力資源的支出。企業不必僱用DevOps工程師來進行運維，當然也不必購買特定的硬體。
高可用性和自動擴充套件。只有在客戶端發出請求時，功能函式才會被啟用並執行，而在不需要的時候，它們處於關閉狀態。同時，隨著流量的增長，FaaS能夠自動擴充套件，它們通過為特定功能函式分配更多的資源，以實現高可用性，和在高負載下的平穩效能。
專注於業務需求。通過讓開發人員從伺服器端(server-side)的工作抽象出來，您的團隊會更專注於應用的業務邏輯。
降低成本和具有可擴充套件性。如前所述，與傳統方法相比，無伺服器架構降低了伺服器運營和維護的成本。而與其他型別的雲端計算服務相比，大多數FaaS提供商都能夠貫徹按請求付費的定價機制。這就意味著您只需要為呼叫功能函式的時間和次數買單。此外，您還可以靈活地為功能函式分配一定數量的記憶體和CPU，並按需擴縮容。

適用場景

低頻請求場景

物聯網行業中，由於物聯網裝置傳輸資料量小，且往往是固定時間間隔進行資料傳輸，因此經常涉及低頻請求場景。例如：物聯網應用程式每分鐘僅執行一次，每次執行50ms，這意味著CPU的使用率為0.1%/小時，這也意味著其實有1000個相同的應用可以共享計算資源。而Serverless架構下，使用者可以購買每分鐘100ms的資源來滿足計算需求，通過這種方式就能夠有效解決效率問題，降低使用成本。

流量突發場景

移動網際網路應用經常會面對突發流量場景，例如：移動應用的通常流量情況是QPS 20，但每隔五分鐘會有一個持續10s的QPS 200流量（10倍於通常流量），傳統架構下企業必須擴充套件QPS 200的硬體能力來應對業務高峰，即使高峰時間僅佔整個執行時間的4%；而在Serverless架構下，使用者可以利用彈性擴充套件特性，快速構建新的計算能力來滿足當前需求，當業務高峰後，資源能夠自動釋放，有效節省成本。

從 AWS Lambda 提供的各種介紹來看，我腦補一下 Serverless 適用場景：

運算密集 —— 如圖片壓縮、資料分析。因為使用 Serverless 方案同一秒裡可以執行千上萬個 Lambda，能輕易實現傳統架構無法實現的超強處理能力，並且只在使用時收費。
為其它服務提供程式設計支援 —— 例如，當 AWS DynamoDB 資料發生變化時，呼叫 AWS Lambda 生成 PDF 報表。再如，為 AWS API Gateway 提供自定義許可權驗證指令碼。
定時任務 —— 以往使用 cron 編寫的定時任務可以改用 AWS Lambda 實現，很明顯的好處是任務不執行的時候完全不收費。
瘦容器 —— 因為 AWS Lambda 本身基於 Docker 容器實現，Lambda 方法跑在 Amazon Linux AMI 中，雖然官方支援的程式語言只有 NodeJS、Java、Python，但其實可以用 NodeJS 的 shim 執行大部分能在 Linux 下執行的程式。
無人運維 —— Serverless 的核心優勢就是不需要管理伺服器，自伸縮的特性如果用傳統方案解決會相對複雜很多。如果你需要一個服務為你跑好幾年，期間完全不需要擔心它的伺服器執行情況，Serverless 會是最好的選擇。

侷限性

首次啟動響應時間

專案中啟動Spring boot的專案的時候，有些服務啟動延時多達10秒以上
AWS lambda在一段閒置狀態後（4小時內，這個資料是與AWS諮詢師確認後得知，官網沒有），一般會收回計算資源。
基於動態語言的服務，比如nodejs或者python，沒有這個問題，一般延時在幾百毫秒。

強第三方依賴

Serverless框架本身是平臺託管的，比如AWS Lambda與AWS繫結，事件源也和平臺相關。
轉化平臺的代價大。

不適合所有場景

有狀態的服務
長時間執行的服務（lambda的最長執行時間為5分鐘）

環境資源的限制

AWS Lambda成功案例

可口可樂與Serverless

美國跨國飲料公司可口可樂公司使用 AWS Lambda 和 AWS Step Functions 構建了經濟高效的無伺服器解決方案。讓我們看看可口可樂是如何使用Serverless技術來改善他們的服務。

可口可樂公司在全球範圍內的自動售貨機與可口可樂總部有一個整合的通訊系統。為這些機器提供服務的人員通過這系統知道特定機器是否會存在飲料庫存不足或者是否會發生其他問題。營銷團隊使用相同的系統，可建立諸如“買一送一”之類的活動，或者購買可樂產品獲取信用點數的活動。

為了開始比較兩種選擇，即基礎設施即服務與功能即服務，讓我解釋一下可口可樂在採用Serverless之前所做的事情。他們最古老的自動售貨機（具有上述功能的自動售貨機）大約有10到12年的歷史。直到2016年，他們一直在使用6臺EC2 T2.Medium機器，每年執行費用為12,864美元。這包括自動化，Ealastic負載均衡器，管理，安全等。在這方面，他們執行這些自動售貨機一年所需的一切花費將近13,000美元。

遷移到Serverless框架之後，將所需功能的成本加起來，每年成本降至4,490美元。這是根據他們當時面臨的3000萬個請求計算出來的。Connor在AWS re:invent上表示，基礎設施作為服務假如要轉虧為盈的話，每月大約要有8000萬次呼叫。這是他們當時期望值的3倍。

總體流程

自動售貨機背後的邏輯很簡單。客戶購買飲料，機器呼叫支付閘道器（恰好是可口可樂的合作伙伴）來驗證購買，該購買對AWS API閘道器進行Rest API呼叫，觸發Lambda。AWS Lambda將處理事務背後的所有業務邏輯（該函式處理所有的業務邏輯：交易、信用、借記等）。如果使用者通過移動裝置發起了交易，則涉及第五步，即向他們的電話傳送推送通知，將資訊提交給Android Pay或Apple Pay。通過Apple/Android推送通知服務把通知傳送回使用者。相應的將其提交回Apple Pay/Android Pay，因此您可以在您手機錢包中看到有一筆支出。在這些交易之前還可能會有“買10免費送一”和其他促銷。

可口可樂公司的Serverless實施的另一個令人印象深刻的方面是所有的通訊都在不到1秒的時間內完成，並且只有在有實際請求時才需要付費。

AWS Step Functions與AWS Lambda結合

可口可樂自動售賣機使用 AWS Step Functions 和其他 AWS 服務支援 Coke.com Vending Pass 計劃。此計劃包括，在支援使用可口可樂 Vending Pass 進行移動支付的自動販售機上購買產品可以贏得飲品獎勵。參與者可輕掃已啟用 NFC 的手機，完成 Apple Pay 或 Android Pay 購買，同時向自動販售機表明身份，並贏取積分，將來即可在自動販售機上免費獲得飲品。

輕掃之後，SNS 主題和 AWS Lambda 函式的組合會對部分現有後端程式碼啟動兩次呼叫，以計算販售點數並更新參與者的記錄。遺憾的是，後端程式碼響應太慢，還有一些計時依賴性，從而導致漏掉更新，並有可能使 Vending Pass 參與者覺得很困惑。解決這個問題的最初方案非常簡單：修改 Lambda 程式碼，在兩次呼叫之間加入 90 秒延遲。這樣確實可以解決問題，但平白消耗了處理時間 (對 Lambda 函式的使用計費取決於請求的持續時間，以 100 毫秒為間隔；因為同一個lambda函式中間加了延遲，那麼此次請求持續時間需要加90秒)。

為了使解決方案更加經濟高效，團隊轉而使用 AWS Step Functions，並構建了非常簡單的狀態機。Step Functions 能夠使用易於構建的視覺化工作流，大規模協調分散式應用程式的元件和微服務。

可口可樂構建了非常簡單的狀態機來簡化業務邏輯並降低成本。您的狀態機也可以同樣簡單，還可以利用其他 Step Function 功能，例如順序執行和並行執行，以及做出決策和選擇備用狀態的能力。可口可樂狀態機如下圖所示：

FirstState 和 SecondState 狀態 (Task 狀態) 會呼叫相應的 Lambda 函式，同時 Step Functions 會實施 90 秒的延遲 (Wait 狀態)。這種修改可以簡化邏輯並降低成本。下圖說明了這些功能是如何結合在一起的：

Netflix案例

Netflix（官方中文名：網飛）是一間在世界多國提供網路視訊點播的OTT服務公司^[7]，並同時在美國經營單一費率郵寄DVD出租服務。許多推薦系統架構參照他們的推薦系統架構：

Netflix 目前正廣泛地使用 AWS Lambda 這類 FaaS（函式即服務）來構建 Serverless 應用。FaaS 的關鍵特徵是：事件驅動、細粒度呼叫、實時彈性伸縮，無需管理伺服器等底層資源。然而使用 FaaS 對 Netflix 來說是有代價的，FaaS 對於延遲要求不嚴格的應用 (latency insensitive tasks) 效果顯著，但對一些諸如延遲要求、可靠性以及彈性要求高的複雜應用而言，仍顯得過於超前。