本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

設計 Lambda 應用程式

架構良好的事件驅動應用程式使用 AWS 服務和自訂程式碼的組合來處理和管理請求和資料。本章著重於應用程式設計中的 Lambda 特定主題。在為忙碌的生產系統設計應用程式時，無伺服器架構師有許多重要的考量。

許多適用於軟體開發和分散式系統的最佳實務，也適用於無伺服器應用程式開發。整體目標是開發符合下列條件的工作負載：

下列設計原則可協助您建置符合這些目標的工作負載。並非每個原則都適用於每個架構，但它們應在一般架構決策中引導您。

使用服務而非自訂程式碼

無伺服器應用程式通常包含數個 AWS 服務，與 Lambda 函數中執行的自訂程式碼整合。雖然 Lambda 可以與大多數 AWS 服務整合，但無伺服器應用程式中最常使用的服務如下：

您可以在分散式架構中建立或使用 AWS 服務實作許多建立良好的常見模式。對於大多數客戶，投資時間從頭開始開發這些模式幾乎沒有商業價值。當您的應用程式需要其中一個模式時，請使用對應的 AWS 服務：

這些服務旨在與 Lambda 整合，您可以使用基礎設施即程式碼 (IaC) 來建立和捨棄服務中的資源。您可以透過 AWS SDK 使用其中任何服務，而無需安裝應用程式或設定伺服器。熟悉透過 Lambda 函數中的程式碼使用這些服務，是生產設計良好的無伺服器應用程式的重要步驟。

了解 Lambda 抽象層級

Lambda 服務會限制您對執行 Lambda 函數和基礎作業系統、Hypervisor 和硬體的存取。此服務會持續改善和變更基礎設施，以新增功能、降低成本，並提高服務效能。您的程式碼應假設不了解 Lambda 的架構方式，且假設沒有硬體親和性。

同樣地，Lambda 與其他 服務的整合是由 管理 AWS，只有少量的組態選項會公開給您。例如，當 API Gateway 和 Lambda 互動時，沒有負載平衡的概念，因為它完全由 服務管理。您也無法直接控制服務在任何時間點調用函數時使用的可用區域，或 Lambda 如何決定何時擴展或縮減執行環境的數量。

此抽象概念可協助您專注於應用程式的整合層面、資料流程，以及工作負載為最終使用者提供價值的商業邏輯。允許服務管理基礎機制可協助您更快速地開發應用程式，同時減少要維護的自訂程式碼。

在 函數中實作無狀態

建置 Lambda 函數時，您應假設環境僅存在於單一調用中。函數應在第一次啟動時初始化任何必要的狀態。例如，您的函數可能需要從 DynamoDB 資料表擷取資料。在結束之前，它應該將任何永久資料變更遞交至持久性存放區，例如 Amazon S3、DynamoDB 或 Amazon SQS。它不應依賴任何現有的資料結構或暫存檔案，或任何將由多個調用管理的內部狀態。

若要初始化資料庫連線和程式庫，或載入狀態，您可以利用靜態初始化。由於執行環境會盡可能重複使用以改善效能，因此您可以在多次調用中分攤初始化這些資源所花費的時間。但是，您不應在此全域範圍內儲存函數中使用的任何變數或資料。

將耦合降至最低

大多數架構應偏好許多、較短的函數，而不是較少、較大的函數。每個函數的用途應該是處理傳遞到函數的事件，而無需了解或預期整個工作流程或交易量。這使得此函數與事件來源無關，且與其他服務的耦合最少。

任何不常變更的全域範圍常數都應作為環境變數實作，以允許在不部署的情況下進行更新。任何機密或敏感資訊都應儲存在 AWS Systems Manager Parameter Store 或 AWS Secrets Manager 中，並由函數載入。由於這些資源是帳戶特定的，因此您可以跨多個帳戶建立建置管道。管道根據環境載入適當的機密，而無需向開發人員公開這些機密，也無需變更任何程式碼。

為隨需資料而非批次建置

許多傳統系統旨在定期執行並處理隨著時間累積的交易批次。例如，銀行應用程式可能每小時執行一次，以處理中央分類帳中的 ATM 交易。在 Lambda 型應用程式中，每個事件都應觸發自訂處理，從而允許服務視需要向上擴展並行，以提供近乎即時的交易處理。

雖然您可以透過使用 Amazon EventBridge 中規則的排程表達式，在無伺服器應用程式中執行 cron 任務，但應謹慎使用或作為最後的手段。在任何處理批次的排程任務中，交易量可能會超出 15 分鐘 Lambda 持續時間限制內可處理的範圍。如果外部系統的限制迫使您使用排程器，您通常應排程最短的合理重複時段。

例如，不最佳實務是使用觸發 Lambda 函數擷取新 Amazon S3 物件清單的批次程序。這是因為服務在批次之間接收到的新物件可能多於 15 分鐘 Lambda 函數內可以處理的物件。

相反地，Amazon S3 應該在每次將新物件放入儲存貯體時叫用 Lambda 函數。這種方法更具可擴展性，並且近乎即時地運作。

AWS Step Functions 考慮協調

涉及分支邏輯、不同類型的故障模型和重試邏輯的工作流程通常會使用協調器來追蹤整體執行的狀態。避免將 Lambda 函數用於此目的，因為它會導致緊密耦合和複雜的程式碼處理路由。

透過 AWS Step Functions，您可以使用狀態機器來管理協同運作。這會從您的程式碼擷取錯誤處理、路由和分支邏輯，並將其取代為使用 JSON 宣告的狀態機器。除了讓工作流程更強大且可觀察之外，您也可以將版本控制新增至工作流程，並讓狀態機器成為您可以新增至程式碼儲存庫的編纂資源。

Lambda 函數中較簡單的工作流程通常會隨著時間變得更加複雜。操作生產無伺服器應用程式時，務必識別何時發生這種情況，以便將此邏輯遷移至狀態機器。

實作冪等性

AWS 無伺服器服務，包括 Lambda，具有容錯能力，旨在處理故障。例如，如果服務叫用 Lambda 函數且發生服務中斷，Lambda 會在不同的可用區域中叫用您的函數。如果您的函數擲回錯誤，Lambda 會重試調用。

由於同一事件可能會被多次接收，因此函數應設計為等冪。這意味著多次接收同一事件不會在第一次收到事件之後變更結果。

您可以使用 DynamoDB 資料表來追蹤最近處理的識別符，以判斷先前是否已處理交易，藉此在 Lambda 函數中實作冪等性。DynamoDB 資料表通常實作存留時間 (TTL) 值來使項目過期，以限制所使用的儲存空間。

使用多個 AWS 帳戶來管理配額

中的許多服務配額 AWS 是在帳戶層級設定。這表示當您新增更多工作負載時，可以快速耗盡限制。

解決此問題的有效方法是使用多個 AWS 帳戶，將每個工作負載分配到自己的 帳戶。這樣可防止與其他工作負載或非生產資源共用配額。

此外，透過使用 AWS Organizations，您可以集中管理這些帳戶的帳單、合規和安全性。您可以將政策連接到帳戶群組，避免自訂指令碼和手動程序。

一種常見的方法是為每個開發人員提供 AWS 帳戶，然後針對 Beta 部署階段和生產環境使用不同的帳戶：

在此模型中，每個開發人員都有自己的一組帳戶限制，因此其用量不會影響您的生產環境。此方法也允許開發人員在其開發機器上針對其個別帳戶中的即時雲端資源，在本機測試 Lambda 函數。