本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 什麼是 AWS Lambda？ **提示** 參加 Serverless 專家的免費實作研討會，了解如何使用最佳實務建置 Serverless 應用程式。[按一下此處](https://aws-experience.com/amer/smb/events/series/Get-Hands-On-With-Serverless?trk=188abe3e-9f94-4e84-aefb-398d944ad567%26sc_channel%3Del)註冊。 AWS Lambda 是一種運算服務，無需管理伺服器即可執行程式碼。您的程式碼會自動執行，並依據負載向上擴展或縮減規模，且採用按使用量付費的計價方式。若要開始使用，請參閱[建立第一個函數](getting-started.md)。 您可以將 Lambda 用於： + **檔案處理**：在檔案上傳至 Amazon Simple Storage Service 時自動處理檔案。如需詳細資訊，請參閱[檔案處理範例](example-apps.md#examples-apps-file)。 + **長時間執行的工作流程：**使用[耐用的 Lambda 函數](durable-functions.md)來建置狀態良好的多步驟工作流程，最多可執行一年。非常適合訂單處理、核准工作流程、human-in-the-loop，以及需要記住進度的複雜資料管道。 + **資料庫操作與整合範例**：回應資料庫變更並自動執行資料工作流程。如需詳細資訊，請參閱[資料庫範例](example-apps.md#examples-apps-database)。 + **排程與定期任務**：使用 EventBridge 定期執行自動化操作。如需詳細資訊，請參閱[排程任務範例](example-apps.md#examples-apps-scheduled)。 + **串流處理**：處理即時資料串流，用於分析與監控用途。如需詳細資訊，請參閱 [Kinesis Data Streams](with-kinesis.md)。 + **Web 應用程式**：建置可擴展的 Web 應用程式，能依據需求自動調整規模。 + **行動後端**：建立安全的 API 後端，供行動裝置與 Web 應用程式使用。 + **IoT 後端**：處理 Web、行裝置動、IoT 與第三方 API 請求。如需詳細資訊，請參閱 [IoT](services-iot.md)。 如需定價資訊，請參閱 [AWS Lambda 定價](https://aws.amazon.com/lambda/pricing/)。 ## Lambda 的運作方式 使用 Lambda 時，您只需負責程式碼的相關操作。Lambda 在高可用性運算基礎結構上執行您的程式碼，並管理所有運算資源，包括伺服器與作業系統維護、容量佈建、自動擴展以及日誌記錄。 由於 Lambda 是事件驅動型無伺服器運算服務，其採用的程式設計典範有別於傳統 Web 應用程式。下列模型說明了 Lambda 的運作方式： 1. 您可以在用於建立 Lambda 應用程式的基本建置區塊 – [Lambda 函式](concepts-basics.md#gettingstarted-concepts-function)中編寫並組織程式碼。 1. 您可以透過 [Lambda 許可](lambda-permissions.md)控制安全性和存取權，使用[執行角色](lambda-intro-execution-role.md)來管理函數可以與哪些 AWS 服務互動，以及哪些資源政策可以與程式碼互動。 1. 事件來源 AWS 和服務[會觸發](concepts-event-driven-architectures.md)您的 Lambda 函數，以 JSON 格式傳遞事件資料，您的函數會處理這些資料 （包括事件來源映射）。 1. Lambda 會透過語言專屬執行時期 (如 Node.js 與 Python) 在執行環境中[執行程式碼](concepts-how-lambda-runs-code.md)，這些執行環境已封裝您的執行時期、層級與延伸模組。 **提示** 若要了解如何建置**無伺服器解決方案**，請參閱[無伺服器開發人員指南](https://docs.aws.amazon.com/serverless/latest/devguide/)。 ## 主要功能 **設定、控制與部署安全應用程式：** + [環境變數](configuration-envvars.md)無需部署新的程式碼即可修改應用程式行為。 + [版本](configuration-versions.md)可以安全地測試新功能，同時維持穩定的生產環境。 + [Lambda 層](chapter-layers.md)透過跨多個函式共用通用元件，最佳化程式碼的重複使用性與可維護性。 + [程式碼簽署](configuration-codesigning.md)透過確保僅有經核准的程式碼能進入生產環境，強制執行安全合規要求。 **可靠擴展與執行：** + [並行與擴展控制](lambda-concurrency.md)可在流量激增期間精準管理應用程式的回應速度與資源使用率。 + [Lambda SnapStart](snapstart.md) 可大幅縮短冷啟動時間。Lambda SnapStart 可提供低至一秒的啟動效能，通常不會變更函數程式碼。 + [回應串流](configuration-response-streaming.md)透過逐步傳送大型承載資料來實現即時處理，從而最佳化函式效能。 + [容器映像](images-create.md)運用容器工作流程，將具有複雜相依性的函式進行封裝。 **無縫連線與整合：** + [VPC 網路](configuration-vpc.md)可防護敏感資源與內部服務的安全。 + [檔案系統](configuration-filesystem.md)整合能跨函式調用共用持續性資料，並管理具狀態作業。 + [函數 URL](urls-configuration.md) 無需額外服務即可建立公開面向的 API 與端點。 + [Lambda 延伸](lambda-extensions.md)可透過監控、安全與營運工具增強函式效能。 ## 相關資訊 + 如需 Lambda 運作方式的詳細資訊，請參閱 [Lambda 的運作方式](concepts-basics.md)。 + 若要開始使用 Lambda，請參閱[建立第一個 Lambda 函數](getting-started.md)。 + 如需範例應用程式清單，請參閱[透過範例應用程式與模式快速入門](example-apps.md)。 # Lambda 的運作方式 Lambda 函式是用來建置 Lambda 應用程式的基本建置區塊。若要編寫函式，必須了解組成 Lambda 程式設計模型的核心概念和元件。本節將引導您了解開始使用 Lambda 建置無伺服器應用程式所需的基本元素。 + **[Lambda 函式與函式處理常式](#gettingstarted-concepts-function)** - Lambda 函數是一小段程式碼，用於回應事件。函數可以是標準 （最多 15 分鐘） 或[耐用](durable-functions.md) （最多一年）。函數是您用來建置應用程式的基本建置區塊。處理常式是 Lambda 函式程式碼處理事件物件的進入點。 + **[Lambda 執行環境與執行時期](#gettingstarted-concepts-runtime)** – Lambda 執行環境會管理執行函式所需的資源。對於[耐用的函數](durable-functions.md)，執行環境包含自動狀態管理和檢查點功能。執行時間是您函數執行的特定語言環境。 + **[事件與觸發程序](#gettingstarted-concepts-event)** - 其他 AWS 服務 可以調用函數以回應特定事件。對於耐用的函數，事件也可以觸發暫停工作流程的恢復。 + **[Lambda 許可與角色](#gettingstarted-concepts-permissions)** - 控制誰可以存取您的函式，以及 AWS 服務 您的函式可以與哪些其他互動。耐用的函數需要額外的許可，才能進行狀態管理和延伸執行。 **提示** 若要更全面地了解無伺服器開發，請參閱 *AWS Serverless Developer Guide* 中的 [Understanding the difference between traditional and serverless development](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html)。 ## Lambda 函式與函式處理常式 在 Lambda 中，**函式**是您用來建立應用程式的基本建置區塊。Lambda 函式是為回應事件而執行的一段程式碼，例如使用者按一下網站上的按鈕，或檔案上傳至 Amazon Simple Storage Service (Amazon S3) 儲存貯體。透過耐用的 函數，您的程式碼可以在步驟之間暫停執行，自動維護狀態，使其非常適合長時間執行的工作流程，例如訂單處理或內容管制。您可以將函式視為一種具有下列特性的獨立程式。 Lambda **函式處理常式**是函式程式碼中處理事件的方法。當函式因回應事件而執行時，Lambda 會執行函式處理常式。導致函式執行的事件相關資料，會直接傳遞至處理常式。雖然 Lambda 函式中的程式碼可以包含多個方法或函式，但 Lambda 函式只能有一個處理常式。 若要建立 Lambda 函式，需將函式程式碼及其相依項共同封裝為部署套件。Lambda 支援兩種類型的部署套件：[.zip 壓縮檔](configuration-function-zip.md)與[容器映像](images-create.md)。 + 一個函式有一個特定的任務或用途 + 僅在需要回應特定事件時執行 + 會在任務完成後自動停止執行 ## Lambda 執行環境與執行時期 Lambda 函式會在 Lambda 為您管理的安全隔離*[執行環境](lambda-runtime-environment.md)*中執行。對於[耐用的函數](durable-functions.md)，執行環境包含用於狀態管理和工作流程協調的其他元件。執行環境會管理執行函數所需的程序和資源。當函式首次被調用時，Lambda 會為該函式建立一個新的執行環境以在其中執行。函式執行完成後，Lambda 不會立即停止該執行環境；如果函式被再次調用，Lambda 可以重複使用現有的執行環境。 Lambda 執行環境中還包含*執行時期*，這是一種與特定程式語言相關的環境，負責在 Lambda 與您的函式之間傳遞事件資訊與回應。Lambda 提供許多適用於最熱門程式設計語言的[受管執行時期](lambda-runtimes.md#runtimes-supported)，但您也可以自行建立執行時期。 對於受管執行時期，Lambda 會自動對使用該執行時期的函式套用安全性更新與修補程式。 ## 事件與觸發程序 您也可以透過 Lambda 主控台、[AWS CLI](https://aws.amazon.com/cli/) 或任一 [AWS 軟體開發套件 (SDK)](https://aws.amazon.com/developer/tools/) 直接調用 Lambda 函式。在生產應用程式中，另一個 會調用您的函數 AWS 服務 以回應特定事件，這是較常見的做法。例如，您可能希望每當 Amazon DynamoDB 資料表新增項目時，就執行某個函式。 若要讓函式回應事件，您可以設定**觸發程序**。觸發程序會將函式連線至事件來源，且函式可以有多個觸發程序。當事件發生時，Lambda 會以 JSON 文件的形式接收事件資料，並將其轉換為程式碼能夠處理的物件。您可以為事件定義下列 JSON 格式，Lambda 執行時期會將此 JSON 文件轉換為物件，然後再將其傳遞至函式的處理常式。 **Example 自訂 Lambda 事件** ``` { "Location": "SEA", "WeatherData":{ "TemperaturesF":{ "MinTempF": 22, "MaxTempF": 78 }, "PressuresHPa":{ "MinPressureHPa": 1015, "MaxPressureHPa": 1027 } } } ``` Amazon Kinesis 或 Amazon SQS 等串流和佇列服務會使用[事件來源映射](invocation-eventsourcemapping.md)，而非標準觸發。事件來源映射會輪詢來源以取得新資料、批次記錄，然後使用批次事件調用函式。如需詳細資訊，請參閱[事件來源映射與直接觸發條件有何不同](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference)。 若要了解觸發程序的運作方式，建議先完成[使用 Amazon S3 觸發程序](with-s3-example.md)教學課程。若需觸發程序使用總覽，或透過 Lambda 主控台建立觸發程序的操作步驟，請參閱[整合其他服務](lambda-services.md)。 ## Lambda 許可與角色 對於 Lambda，您需要設定兩種主要的[許可](permissions-granting-access.md)類型： + 您的函數存取其他 所需的許可 AWS 服務 + 其他使用者和 存取函數 AWS 服務 所需的許可 下列各節介紹了這兩種許可類型，並討論了套用最低權限許可的最佳實務。 ### 函數存取其他 AWS 資源的許可 Lambda 函數通常需要存取其他 AWS 資源並對其執行動作。例如，函式可能會讀取 DynamoDB 資料表中項目、將物件儲存在 S3 儲存貯體中，或向 Amazon SQS 佇列寫入資料。若要為函式提供執行這些動作所需的許可，您可以使用*[執行角色](lambda-intro-execution-role.md)*。 Lambda 執行角色是一種特殊的 AWS Identity and Access Management (IAM) [角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，您在帳戶中建立的身分，具有*政策*中定義與其相關聯的特定許可。 每個 Lambda 函式都必須擁有執行角色，而且單一角色可供多個函式共同使用。當函式被調用時，Lambda 會擔任函式的執行角色，取得執行該角色政策中定義之動作的許可。 若您透過 Lambda 主控台建立函式，Lambda 會自動為您的函式建立執行角色。該角色的政策會授予函式基本許可，可將日誌輸出寫入 Amazon CloudWatch Logs。若要授予函數在其他 AWS 資源上執行動作的許可，您需要編輯角色以新增額外的許可。新增許可的最簡單方法是使用 AWS [受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。受管政策是由 建立和管理 AWS ，並提供許多常見使用案例的許可。例如，若函式對 DynamoDB 資料表執行 CRUD 操作，您可以將 [AmazonDynamoDBFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) 政策新增至角色。 ### 其他使用者與資源存取函式所需的許可 若要授予其他 AWS 服務 許可來存取您的 Lambda 函數，您可以使用以*[資源為基礎的政策](access-control-resource-based.md)*。在 IAM 中，資源型政策會連接至資源 (本案例中即您的 Lambda 函式)，並定義可存取該資源的對象，以及允許對象執行哪些動作。 若要讓另一個 AWS 服務 透過觸發叫用函數，函數的資源型政策必須授予該服務使用該`lambda:InvokeFunction`動作的許可。若您透過主控台建立觸發程序，Lambda 會自動為您新增此許可。 若要授予其他 AWS 使用者存取函數的許可，您可以在函數的資源型政策中定義此項目，方式與另一個 AWS 服務 或 資源完全相同。您也可以使用與使用者相關聯的*[身分型政策](access-control-identity-based.md)*。 ### Lambda 許可的最佳實務 使用 IAM 政策設定許可時，[安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)是僅授予執行任務所需的許可。這稱為*最低權限*原則。若要開始授予函數的許可，您可以選擇使用 AWS 受管政策。受管政策是授予執行任務所需許可最快速且最簡單的方式，但其中可能包含您不需要的其他許可。從早期開發到進入測試及生產階段的過程中，建議透過間建立自訂[客戶管理政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)，將許可精簡至僅保留實際所需的項目。 在使用資源型政策授予存取函式的許可時，此原則同樣適用。例如，如果您想要授予 Amazon S3 叫用函數的許可，最佳實務是限制對個別儲存貯體或儲存貯體的存取 AWS 帳戶，而不是授予 S3 服務的空白許可。 # 透過 Lambda 執行程式碼 當您編寫 Lambda 函式時，其實是在建立將在獨特的無伺服器環境中執行的程式碼。了解 Lambda 實際執行程式碼的運作原理，需掌握兩個核心面向：定義程式碼與 Lambda 互動方式的程式設計模型，以及決定 Lambda 如何管理程式碼執行時期環境的執行環境生命週期。 ## Lambda 程式設計模型 無論您是以 Python、Java 或任何其他支援的語言撰寫，程式設計模型都會做為 Lambda 如何使用程式碼的常見規則集。程式設計模型包含您的執行時期與處理常式。 **對於標準函數：** 1. Lambda 收到事件。 1. Lambda 會使用執行時間，以您的程式碼可以使用的格式準備事件。 1. 執行時期將格式化的事件傳送至您的處理常式。 1. 您的處理常式會使用您撰寫的程式碼來處理事件。 **對於耐用函數：** 1. Lambda 收到事件 1. 執行時間會準備事件和 DurableContext 1. 您的處理常式可以： + 使用自動檢查點處理步驟 + 暫停執行而不耗用資源 + 從最後一個成功的檢查點繼續 + 在步驟之間維持狀態 此模型的關鍵是*處理常式*，這是 Lambda 將事件傳送給您的程式碼進行處理的入口。您可以將其視為程式碼的進入點。當 Lambda 收到事件時，會將此事件與部分內容資訊傳遞給您的處理常式。然後，處理常式會執行您的程式碼來處理這些事件。例如，其可能會在有檔案上傳至 Amazon S3 時讀取該檔案、分析映像或更新資料庫。當程式碼完成事件處理後，處理常式即準備就緒，可繼續處理下一個事件。 ## Lambda 執行模型 雖然程式設計模型會定義 Lambda 與您的程式碼互動的方式，但執行環境是 Lambda 實際執行函數的位置，這是專為您的函數建立的安全隔離運算空間。 **每個環境遵循的生命週期會因標準和耐用函數而異：** **標準函數 （最多 15 分鐘）：** 1. **初始化：**環境設定和程式碼載入 1. **調用：**函數程式碼的單一執行 1. **關閉：**環境清除 **耐用函數 （最長 1 年）：** 1. **初始化：**環境和持久狀態設定 1. **調用：**具有自動檢查點的多個步驟 1. **等待狀態：**暫停執行而不耗用資源 1. **繼續：**從最後一個檢查點重新啟動 1. **關閉：**清除持久狀態 此環境會處理執行函式所涉及的重要層面。其會為函式提供記憶體與 `/tmp` 目錄用於暫時儲存。**對於持久性函數，它也會管理：** + 步驟之間的自動狀態持久性 + 檢查點儲存和復原 + 等待狀態協調 + 長時間執行執行的進度追蹤 # 了解 Lambda 程式設計模型 Lambda 提供兩種程式設計模型：執行最多 15 分鐘的標準函數，以及執行最多一年的耐久函數。雖然兩者都共用核心概念，但耐用函數為長時間執行且具狀態的工作流程新增了功能。 Lambda 提供的程式設計模型對於所有執行時間通用。程式設計模型會定義程式碼與 Lambda 系統之間的介面。透過在函數組態中定義一個*處理常式*，將函數的進入點告知 Lambda。執行時間會將包含呼叫*事件*和*內容*的物件傳入至處理常式，例如函數名稱和請求 ID。 **對於耐用函數，處理常式也會收到 DurableContext 物件，提供：** + 透過 step() 的檢查點功能 + 透過 wait() 和 waitForCallback() 等待狀態管理 + 叫用之間的自動狀態持續性 當處理常式完成處理第一個事件時，執行時間就會傳送至另一個。對於耐用函數，處理常式可以暫停步驟之間的執行，而且 Lambda 將在函數恢復時自動儲存和還原狀態。函數的類別會保留在記憶體中，因此可以重複使用在*初始化程式碼*的處理常式方法外宣告的用戶端和變數。為了節省後續事件的處理時間，請建立可重複使用的資源，例如初始化期間的 AWS SDK 用戶端。初始化後，函式的每個執行個體都可以處理數千個請求。 您的函數也可以存取 `/tmp` 目錄中的本機儲存體，此暫時性快取可用於多個調用。如需詳細資訊，請參閱[執行環境](lambda-runtime-environment.md)。 啟用[AWS X-Ray 追蹤](services-xray.md)時，執行時間會記錄初始化和執行的個別子區段。 執行時間會從您的函數擷取記錄輸出，並將其傳送至 Amazon CloudWatch Logs。除了記錄函式的輸出之外，執行階段也會記錄函式叫用開始和結束的項目。這包含有要求 ID、帳單期、初始化持續時間和其他詳細資料的記錄。如果函數拋出錯誤，執行時間會將該錯誤傳回給叫用者。 **注意** 記錄受 [CloudWatch Logs 配額](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)限制。日誌資料可能會因節流而遺失，或在某些情況下，因函數的執行個體停止而遺失。 **持久性函數的主要差異：** + 狀態會在步驟之間自動保留 + 函數可以暫停執行而不耗用資源 + 步驟會在失敗時自動重試 + 透過檢查點追蹤進度 Lambda 會隨著需求增加執行額外的執行個體，以及隨需求降低停止執行個體，藉以擴展您的函數。此模型會導致應用程式結構的變化，例如： + 除非另有說明，否則可能會不按順序或同時處理傳入的請求。 + 不依賴函數長期存留的執行個體，而是將應用程式的狀態存放在其他服務中。 + 使用本機儲存和類別層級物件來提高效能，但將部署套裝服務的大小和傳輸至執行環境的資料量降至最低。 如需使用慣用程式設計語言的程式設計模型實作簡介，請參閱以下章節。 + [使用 Node.js 建置 Lambda 函數](lambda-nodejs.md) + [使用 Python 建置 Lambda 函數](lambda-python.md) + [使用 Ruby 建置 Lambda 函數](lambda-ruby.md) + [使用 Java 建置 Lambda 函數](lambda-java.md) + [使用 Go 建置 Lambda 函數](lambda-golang.md) + [使用 C\$1 建置 Lambda 函數](lambda-csharp.md) + [使用 PowerShell 建置 Lambda 函數](lambda-powershell.md) # 了解 Lambda 執行環境生命週期 Lambda 執行環境支援標準函數 （最多 15 分鐘） 和耐用函數 （最多一年）。雖然兩者共用相同的基本生命週期，但耐用函數會為長時間執行的工作流程新增狀態管理功能。 Lambda 會在執行環境中叫用您的函數，該環境可提供安全且隔離的執行時間環境。執行環境會管理執行函式所需的資源。執行環境也會提供函式執行階段的生命週期支援，以及與函式相關聯的任何[外部延伸項目](lambda-extensions.md)。 **對於耐用函數，執行環境包含以下項目的其他元件：** + 步驟之間的狀態持久性 + 檢查點管理 + 等待狀態協調 + 進度追蹤 **Lambda 受管執行個體執行環境** 如果您使用的是 [Lambda 受管執行個體](lambda-managed-instances-execution-environment.md)，執行環境與 Lambda （預設） 函數有重要的差異。受管執行個體支援並行調用、使用不同的生命週期模型，以及在客戶擁有的基礎設施上執行。如需受管執行個體執行環境的詳細資訊，請參閱 [了解 Lambda 受管執行個體執行環境](lambda-managed-instances-execution-environment.md)。 函數的執行時間會使用 [Runtime API](runtimes-api.md) 與 Lambda 進行通訊。延伸項目會使用 [Extensions API](runtimes-extensions-api.md) 與 Lambda 進行通訊。延伸項目還可以透過使用[遙測 API](telemetry-api.md) 來接收函數的日誌訊息和其他遙測項目。 ![\[執行環境的架構圖表。\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/telemetry-api-concept-diagram.png) 當您建立 Lambda 函數時，您將指定組態資訊，例如您的函數允許的記憶體數量與執行時間上限。Lambda 會使用此資訊來設定執行環境。 函式的執行階段和每個外部延伸項目都是在執行環境中執行的程序。許可、資源、認證和環境變數會在函式和延伸項目之間共用。 **Topics** + [ ## Lambda 執行環境生命週期 ](#runtimes-lifecycle) + [ ## 冷啟動和延遲 ](#cold-start-latency) + [ ## 使用佈建並行減少冷啟動 ](#cold-starts-pc) + [ ## 最佳化靜態初始化 ](#static-initialization) ## Lambda 執行環境生命週期 ![\[Lambda 生命週期階段：初始化、調用、關閉\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/Overview-Successful-Invokes.png) 每個階段都以 Lambda 傳送到執行階段和所有已註冊延伸項目的事件開始。執行時間和每個已註冊延伸項目都會透過傳送 `Next` API 請求來表示已完成。當執行時間和每個延伸項目已完成且沒有擱置的事件時，Lambda 凍結執行環境。 **耐用函數的生命週期階段包括：** + **初始化：**標準初始化加上持久狀態設定 + **調用：**可以包含具有自動檢查點的多個步驟執行 + **等待：**函數可以暫停執行，而不會耗用資源 + **繼續：**從最後一個檢查點重新啟動函數 + **關閉：**清除耐用狀態和資源 **Topics** + [ ### 初始化階段 ](#runtimes-lifecycle-ib) + [ ### 初始化階段期間出現的失敗 ](#runtimes-lifecycle-init-errors) + [ ### 還原階段 (僅限 Lambda SnapStart) ](#runtimes-lifecycle-restore) + [ ### 調用階段 ](#runtimes-lifecycle-invoke) + [ ### 調用階段期間出現的故障 ](#runtimes-lifecycle-invoke-with-errors) + [ ### 關閉階段 ](#runtimes-lifecycle-shutdown) ### 初始化階段 在 `Init` 階段中，Lambda 會執行三項任務： + 啟動所有延伸項目 (`Extension init`) + Bootstrap 執行時間 (`Runtime init`) + 執行該函式的靜態代碼 (`Function init`) + 執行任何檢查點前的[執行時期勾點](snapstart-runtime-hooks.md) (僅限 Lambda SnapStart) 當執行階段和所有延伸項目透過傳送 `Next` API 請求發出訊號表示它們已準備就緒時，`Init` 階段便會結束。`Init` 階段限制為 10 秒。如果所有三項任務都未在 10 秒內完成，Lambda 會在第一次函數調用時以設定的函數逾時重試 `Init` 階段。 在 [Lambda SnapStart](snapstart.md) 啟動的情況下，發佈函數版本時會發生 `Init` 階段。Lambda 會儲存初始化執行環境的記憶體和磁碟狀態快照、保留加密的快照，並快取以進行低延遲存取。如果您擁有檢查點前的[執行時期勾點](snapstart-runtime-hooks.md)，則程式碼會在 `Init` 階段結束時執行。 **注意** 10 秒逾時不適用於使用佈建並行、SnapStart 或 Lambda 受管執行個體的函數。對於佈建並行、SnapStart 和受管執行個體函數，初始化程式碼最多可執行 15 分鐘。時間限制為 130 秒或設定的函數逾時 (最長 900 秒)，以較長者為準。 使用[佈建並行](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)時，當您設定函數的電腦設定，Lambda 會初始化執行環境。Lambda 也可確保初始化的執行環境在調用之前隨時可用。您會發現函數調用和初始化階段之間出現差距。根據函數的執行期和記憶體組態，您也會在初始化的執行環境上第一次調用時看到變數延遲。 對於使用隨需並行的函數，Lambda 偶爾會在調用請求之前初始化執行環境。發生這種情況時，您也會注意到函數初始化和調用階段之間出現時間差。建議您不要依賴此行為。 ### 初始化階段期間出現的失敗 如果在 `Init` 階段期間函數當機或出現逾時，Lambda 會在 `INIT_REPORT` 日誌檔中發出錯誤資訊。 **Example — 逾時的 INIT\$1REPORT 日誌** ``` INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout ``` **Example — 延伸失敗的 INIT\$1REPORT 日誌** ``` INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash ``` 如果 `Init` 階段成功，除非已啟用 [SnapStart](snapstart.md) 或[佈建並行](provisioned-concurrency.md)，否則 Lambda 不會發出 `INIT_REPORT` 日誌。SnapStart 和佈建並行函數一律會發出 `INIT_REPORT`。如需詳細資訊，請參閱[監控 Lambda SnapStart](snapstart-monitoring.md)。 ### 還原階段 (僅限 Lambda SnapStart) 第一次調用 [SnapStart](snapstart.md) 函數且函數擴展時，Lambda 會從保留的快照繼續新的執行環境，而不是從頭開始初始化函數。如果您設定了還原後[執行時期勾點](snapstart-runtime-hooks.md)，其程式碼會在 `Restore` 階段結束時執行。您需支付還原後執行時期勾點期間的費用。執行時期必須完成載入，且還原後執行時期勾點必須在逾時限制 (10 秒) 內完成。否則，您將收到 SnapStartTimeoutException 訊息。`Restore` 階段完成時，Lambda 會調用函數處理常式 ([調用階段](#runtimes-lifecycle-invoke))。 #### 還原階段期間出現的失敗 如果 `Restore` 階段失敗，Lambda 會在 `RESTORE_REPORT` 日誌檔中發出錯誤資訊。 **Example — 逾時的 RESTORE\$1REPORT 日誌** ``` RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout ``` **Example — 執行期勾點失敗的 RESTORE\$1REPORT 日誌** ``` RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError ``` 如需`RESTORE_REPORT` 日誌的詳細資訊，請參閱 [監控 Lambda SnapStart](snapstart-monitoring.md)。 ### 調用階段 調用 Lambda 函數以回應 `Next` API 請求時，Lambda 會將 `Invoke` 事件傳送至執行時間和每個延伸項目。 該函式的逾時設定會限制整個 `Invoke` 階段的持續時間。例如，如果您將函式逾時設定為 360 秒，則函式和所有延伸項目都需要在 360 秒內完成。請注意，沒有獨立的調用後階段。持續時間是所有調用時間 (執行階段 \$1 延伸項目) 的總和，直到函式和所有延伸項目完成執行後才會計算。 調用階段會在執行階段後結束，所有延伸項目訊號都透過傳送 `Next` API 請求完成。 ### 調用階段期間出現的故障 如果 Lambda 函數當機或在 `Invoke` 階段逾時，Lambda 會重設執行環境。下圖會說明發生調用故障時 Lambda 執行環境的行為： ![\[執行環境範例：初始化、調用、調用出現錯誤、調用、關閉\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/Overview-Invoke-with-Error.png) 在前一張示意圖中： + 第一階段是 **INIT** 階段，執行期間未發生錯誤。 + 第二階段是 **INVOKE** 階段，執行期間未發生錯誤。 + 假設在某個時間點，函式遇到調用失敗 (常見原因包括函式逾時、執行時期錯誤、記憶體耗盡、VPC 連線問題、許可錯誤、並行限制以及各種組態問題)。如需可能調用失敗的完整清單，請參閱[針對 Lambda 中的調用問題進行疑難排解](troubleshooting-invocation.md)。第三階段 (標記為「**INVOKE WITH ERROR**」) 會說明此狀況。發生此狀況時，Lambda 服務會進行重設。重設的行為會與 `Shutdown` 事件一樣。首先，Lambda 會關閉執行階段，然後將 `Shutdown` 事件傳送給每個已註冊的外部延伸項目。事件會包括關閉的原因。如果將此環境用於新的調用，Lambda 便會在下一次調用時重新初始化延伸項目和執行階段。 請注意，在下一個初始化階段之前，Lambda 重設不會清除 `/tmp` 目錄內容。這種行為與一般關機階段一致。 **注意** AWS 目前正在對 Lambda 服務實作變更。由於這些變更，您可能會看到系統日誌訊息的結構和內容，與 AWS 帳戶中不同 Lambda 函數發出的追蹤區段之間存在細微差異。 如果函數的系統日誌組態設為純文字，則此變更會影響函數發生調用失敗時在 CloudWatch Logs 中擷取的日誌訊息。下列範例展示了舊格式和新格式的日誌輸出。 這些變化將在未來幾週內實作，除中國和 GovCloud 區域以外，所有 AWS 區域 中的所有函數都會轉換至使用新格式的日誌訊息和追蹤區段。 **Example CloudWatch Logs 日誌輸出 (執行時期或延伸項目損毀) - 舊式** ``` START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason Runtime.ExitError END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB ``` **Example CloudWatch Logs 日誌輸出 (函數逾時) - 舊式** ``` START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST 2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms ``` CloudWatch Logs 的新格式包括 `REPORT` 行中的額外 `status` 欄位。在執行時期或延伸項目損毀的情況下，該 `REPORT` 行也包含欄位 `ErrorType`。 **Example CloudWatch Logs 日誌輸出 (執行時期或延伸項目損毀) - 新式** ``` START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError ``` **Example CloudWatch Logs 日誌輸出 (函數逾時) - 新式** ``` START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout ``` + 第四階段指的是出現調用故障後立即進入的 **INVOKE** 階段。在此階段中，Lambda 會透過重新執行 **INIT** 階段來再次初始化環境。(我們將其稱為*隱藏的初始化*。) 發生隱藏的初始化時，Lambda 不會在 CloudWatch Logs 中明確回報其他 **INIT** 階段。相反地，您可能會注意到 REPORT 行中的持續時間包含其他的 **INIT** 持續時間以及 **INVOKE** 持續時間。舉例來說，假設您在 CloudWatch 中看到以下日誌： ``` 2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST 2022-12-20T01:00:02.500-08:00 END RequestId: XXX 2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB ``` 在這個例子中，REPORT 和 START 時間戳記之間的差距是 2.5 秒。這與回報的 3022.91 毫秒持續時間不相符，因為它不會將 Lambda 執行的額外 **INIT**（隱藏的初始化） 納入考量。在這個例子中，您可以推斷實際的 **INVOKE** 階段花費了 2.5 秒的時間。 若要深入了解此行為，您可以使用 [使用遙測 API 即時存取延伸功能的遙測資料](telemetry-api.md). 調用階段發生隱藏的初始化時，遙測 API 便會透過 `phase=invoke` 發送 `INIT_START`、`INIT_RUNTIME_DONE` 及 `INIT_REPORT` 事件。 + 第五階段指的是 **SHUTDOWN** 階段，執行期間未發生錯誤。 ### 關閉階段 當 Lambda 即將關閉執行時間，它會將 `Shutdown` 事件傳送至每個已註冊外部延伸。延伸項目可以使用此時間進行最終清理工作。`Shutdown` 事件是對 `Next` API 請求的回應。 **持續時間限制**：`Shutdown` 階段的最長持續時間視已註冊延伸項目的組態而定： + 0 毫秒 - 沒有註冊延伸的函數 + 500 毫秒 - 具有已註冊內部延伸項目的函數 + 2,000 毫秒 - 具有一個或多個已註冊外部延伸項目的函數 如果執行時間或延伸項目未在限制內回應 `Shutdown` 事件，Lambda 會使用 `SIGKILL` 訊號結束程序。 在函數和所有延伸項目完成之後，Lambda 會維護執行環境一段時間，並預期另一個函數調用。不過，Lambda 每隔幾小時終止一次執行環境，以允許執行時期更新和維護，即使對於持續調用的函數也是如此。您不應該假設執行環境將無限期持續運作。如需詳細資訊，請參閱[在函式中實作無狀態](concepts-application-design.md#statelessness-functions)。 再次叫用函數時，Lambda 會解凍環境以重複使用。重複使用執行環境具有下列含義： + 在函數處理常式方法外宣告的物件會保持初始化，於再次呼叫函數時提供額外的最佳化。例如，假設您的 Lambda 函數建立資料庫連線，而不是重建連線，那麼在後續呼叫時便會使用原始連線。建議您在程式碼中新增邏輯，在建立連線前先確認是否存在既有連線。 + 每個執行環境都會在 `/tmp` 目錄中提供 512 MB 到 10,240 MB 的磁碟空間，增量為 1 MB。執行內容凍結時，目錄環境會凍結，所提供的暫時性可用於多重調用。您可以新增額外的程式碼，確認快取是否具有您已儲存的資料。如需部署大小限制的詳細資訊，請參閱[Lambda 配額Lambda 配額](gettingstarted-limits.md)。 + 如果 Lambda 重複使用執行環境，則會恢復由 Lambda 函數啟動且在函數結束時沒有完成的背景程序或回呼。請確定程式碼中的任何背景程序或回呼在程式碼存在前已完成。 ## 冷啟動和延遲 當 Lambda 收到透過 Lambda API 執行函式的請求時，此服務會先準備執行環境。在此初始化階段，服務會下載程式碼、啟動環境，並執行主要處理常式外部的任何初始化程式碼。最後，Lambda 才會執行處理常式程式碼。 ![\[效能最佳化圖 1\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/perf-optimize-figure-1.png) 在此圖表中，下載程式碼和設定環境的前兩個步驟通常稱為「冷啟動」。[這段時間會產生費用](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/)，且會增加調用的整體延遲時間。 調用完成之後，執行環境會凍結。為了改善資源管理和效能，Lambda 會將執行環境保留一段時間。在此期間，如果收到另一個針對相同函式的請求，Lambda 可以重複使用該環境。第二個請求通常會更快完成，因為執行環境已完全設定。這就是所謂的「暖啟動」。 冷啟動通常發生在不到 1% 的調用中。冷啟動的持續時間從低於 100 毫秒至超過 1 秒不等。一般而言，冷啟動在開發和測試函式中通常比在生產工作負載更為常見。這是因為開發和測試函數的調用頻率通常較低。 ## 使用佈建並行減少冷啟動 如果工作負載需要可預測的函式啟動時間，建議使用[佈建並行](provisioned-concurrency.md)解決方案，確保盡可能降低延遲。此功能會預先初始化執行環境，從而減少冷啟動時間。 例如，若函式的佈建並行為 6，表示具有 6 個預先暖啟動的執行環境。 ![\[效能最佳化圖 4\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/perf-optimize-figure-4.png) ## 最佳化靜態初始化 靜態初始化在處理常式程式碼開始在函數中執行之前進行。這是您在主要處理常式外部提供的初始化程式碼。此程式碼通常用於匯入程式庫和相依項、設定組態，以及初始化與其他服務的連線。 下列 Python 範例示範了如何在調用期間執行 `lambda_handler` 函式之前，在初始化階段匯入和設定模組以及建立 Amazon S3 用戶端。 ``` import os import json import cv2 import logging import boto3 s3 = boto3.client('s3') logger = logging.getLogger() logger.setLevel(logging.INFO) def lambda_handler(event, context): # Handler logic... ``` 函式執行前的延遲，主要來自初始化程式碼的執行時間。首次建立新的執行環境，即會執行此程式碼。如果調用使用暖執行環境，則不會再次執行初始化程式碼。影響初始化程式碼延遲的因素包括： + 函數套件的大小，包括匯入的程式庫和相依項以及 Lambda 層。 + 程式碼和初始化工作的數量。 + 程式庫和其他服務在設定連線及其他資源方面的表現。 開發人員可以採取多個步驟來最佳化靜態初始化延遲。如果一個函數具有許多物件和連線，您可以將單一函數重新架構為多個專用函數。這些函式各自較小，並且每個函式的初始化程式碼也更少。 重要的是，函數僅匯入所需的程式庫和相依項。例如，如果您只在 AWS SDK 中使用 Amazon DynamoDB，您可以要求個別服務，而不是整個 SDK。比較下列三個範例： ``` // Instead of const AWS = require('aws-sdk'), use: const DynamoDB = require('aws-sdk/clients/dynamodb') // Instead of const AWSXRay = require('aws-xray-sdk'), use: const AWSXRay = require('aws-xray-sdk-core') // Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use: const dynamodb = new DynamoDB.DocumentClient() AWSXRay.captureAWSClient(dynamodb.service) ``` 靜態初始化通常也是開啟資料庫連線的最佳位置，可允許函式在對同一執行環境的多次調用中重複使用連線。但是，您可能具有大量僅在函數的某些執行路徑中使用的物件。在這種情況下，您可以在全域範圍內延遲載入變數，以縮短靜態初始化持續時間。 避免使用全域變數來取得特定內容的資訊。如果您的函數具有僅在單次調用的生命週期內使用並在下次調用時重設的全域變數，請使用處理常式本機的變數範圍。這不僅可以防止調用間的全域變數洩漏，還可以改善靜態初始化效能。 # 透過 Lambda 建立事件驅動型架構 事件是指能夠觸發 Lambda 函式執行的任何事物。事件可以透過兩種方式觸發 Lambda 函數：透過直接調用 （推送） 和事件來源映射 （提取）。 許多 AWS 服務可以直接叫用您的 Lambda 函數。這些服務會將事件*推送*至您的 Lambda 函式。觸發函數的事件幾乎可以是任何事件，從透過 API Gateway 的 HTTP 請求、由 EventBridge 規則管理的排程、 AWS IoT 事件或 Amazon S3 事件。透過事件來源映射，Lambda 會主動從佇列或串流擷取 (或*拉取*) 事件。您僅需設定 Lambda 檢查來自支援服務的事件，Lambda 便會自動處理輪詢與函式調用作業。 事件在傳遞至函式時，會以 JSON 格式結構化呈現。JSON 結構會因事件來源服務與類型而異。雖然標準 Lambda 函數調用最多可持續 15 分鐘 （或使用[耐久函數](durable-functions.md)最長一年），但 Lambda 最適合持續 1 秒或更短的短調用。此特性在事件驅動型架構中尤為明顯：在這種架構中，每個 Lambda 函式都被視為一個微服務，負責執行一組精簡的特定指令。 **注意** 事件驅動型架構使用網路跨不同系統進行通訊，這會引入可變延遲。對於需要極低延遲的工作負載，例如即時交易系統，此設計可能不是最佳選擇。但是，對於高度可擴展和可用的工作負載，或是具有不可預測流量模式的工作負載，事件驅動型架構可以提供有效的方式來符合這些需求。 **Topics** + [ ## 事件驅動型架構的優勢 ](#event-driven-benefits) + [ ## 事件驅動型架構的權衡 ](#event-driven-tradeoffs) + [ ## 基於 Lambda 的事件驅動型應用程式反模式 ](#event-driven-anti-patterns) ## 事件驅動型架構的優勢 在事件驅動型架構中，Lambda 支援兩種調用方法： 1. 直接調用 （推送方法）： AWS 服務會直接觸發 Lambda 函數。例如： + Amazon S3 於檔案上傳時觸發函式 + API Gateway 於接收 HTTP 請求時觸發函式 1. 事件來源映射 (拉取方法)：Lambda 會擷取事件並調用函式。例如： + Lambda 從 Amazon SQS 佇列擷取訊息後調用函式 + Lambda 從 DynamoDB 串流讀取記錄後調用函式 如下文所述，這兩種方法共同實現了事件驅動型架構的優勢。 ### 將輪詢和 Webhook 取代為事件 許多傳統架構會透過輪詢與 Webhook 機制，在不同元件之間傳達狀態資訊。輪詢在擷取更新時的效率可能非常低，因為新資料變得可用和與下游服務同步之間存在延遲。您想要整合的其他微服務並非總是支援 Webhook。它們也可能需要自訂授權和身分驗證組態。在這兩種情況下，如果沒有開發團隊的額外工作，這些整合方法難以隨需擴展。 ![\[事件驅動型架構圖 7\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-7.png) 這兩種機制都可以取代為事件，這些事件可以篩選、路由並推送至下游使用微服務。此方法可能會導致頻寬耗用減少、CPU 使用率降低，並可能降低成本。這些架構還可以降低複雜性，因為每個功能單元都較小，而且程式碼通常較少。 ![\[事件驅動型架構圖 8\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-8.png) 事件驅動型架構也可以更輕鬆地設計近乎即時的系統，協助組織遠離批次型處理。事件會在應用程式中的狀態變更時產生，因此微服務的自訂程式碼應設計為處理單一事件。由於擴展由 Lambda 服務處理，因此該架構無需變更自訂程式碼，即可應對流量的顯著增加。隨著事件向上擴展，處理事件的運算層也隨之擴展。 ### 降低複雜性 微服務可讓開發人員和架構師簡化複雜的工作流程。例如，電子商務整體可以分為訂單接受和付款程序，使用單獨的庫存、履行和會計服務。在整體中管理和協調可能很複雜，會成為一系列與事件非同步通訊的解耦服務。 ![\[事件驅動型架構圖 9\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-9.png) 此方法也可讓您組合以不同速率處理資料的服務。在此情況下，訂單接受微服務可以透過緩衝 Amazon SQS 佇列中的訊息來存放大量傳入訂單。 由於處理付款的複雜性，付款處理服務通常較慢，因此可以從 Amazon SQS 佇列取得穩定的訊息串流。它可以使用 協調複雜的重試和錯誤處理邏輯 AWS Step Functions，並為數十萬個訂單協調作用中的付款工作流程。 **替代方法：**對於使用標準程式設計語言的協同運作，您可以使用 [Lambda 耐久函數](durable-functions.md)。耐用的函數可讓您使用自動檢查點和重試，以程式碼撰寫訂單接受、付款處理和通知邏輯。當工作流程主要涉及 Lambda 函數，而且您偏好在程式碼中保留協同運作邏輯時，此方法運作良好。 ### 改善可擴展性和可擴充性 微服務產生的事件通常會發布至 Amazon SNS 和 Amazon SQS 等傳訊服務。這些行為就像微服務之間的彈性緩衝，有助於在流量增加時處理擴展。然後，Amazon EventBridge 之類的服務可以根據事件的內容篩選和路由訊息，如規則中所定義。因此，事件型應用程式可能比單體式應用程式更具可擴展性，並提供更大的備援。 此系統也具有高度可擴展性，允許其他團隊擴展特性並新增功能，而不會影響訂單處理和付款處理微服務。透過使用 EventBridge 發布事件，此應用程式可與庫存微服務等現有系統整合，但也可讓任何未來應用程式以事件取用者身分整合。事件的生產者不了解事件取用者，這有助於簡化微服務邏輯。 ## 事件驅動型架構的權衡 ### 可變延遲 與單一裝置上可能處理相同記憶體空間內所有內容的單體應用程式不同，事件驅動型應用程式會跨網路進行通訊。此設計引入了可變延遲。雖然可以設計應用程式以將延遲降至最低，但單體式應用程式幾乎總是可以最佳化來降低延遲，而犧牲可擴展性和可用性。 需要穩定低延遲效能的工作負載 (例如銀行中的高頻交易應用程式，或倉儲中低於一毫秒的機器人自動化)，並非事件驅動型架構的理想候選項目。 ### 最終一致性 事件代表狀態變更，許多事件在任何指定時間點流經架構中的不同服務，此類工作負載通常[最終會一致](https://en.wikipedia.org/wiki/Eventual_consistency)。這使得處理交易、處理重複項目或確定系統的確切整體狀態更複雜。 某些工作負載包含最終一致 (例如，目前小時內的總訂單數) 或高度一致 (例如，目前庫存) 的要求組合。對於那些需要高度資料一致性的工作負載，有架構模式可支援此作業。例如： + DynamoDB 可以提供[高度一致性讀取](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html)，有時延遲較高，會耗用比預設模式更高的輸送量。DynamoDB 也能[支援交易](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html)，可協助維持資料一致性。 + 您可以使用 Amazon RDS 來實現需要 [ACID 屬性](https://en.wikipedia.org/wiki/ACID)的功能，但關聯式資料庫的可擴展性一般低於 DynamoDB 等 NoSQL 資料庫。[Amazon RDS Proxy](https://aws.amazon.com/rds/proxy/) 可協助管理 Lambda 函數等暫時性取用者的連線集區和擴展。 事件型架構通常以個別事件為基礎設計，而非大批次資料。通常，工作流程旨在管理個別事件或執行流程的步驟，而不是同時在多個事件上操作。在無伺服器架構中，即時事件處理優先於批次處理：應以多次小規模增量更新取代批次作樂。雖然這可以提高工作負載的可用性和可擴展性，但也讓事件更難以感知其他事件。 ### 將值傳回給呼叫者 在許多情況下，事件型應用程式是非同步的。這意味著呼叫者服務不會等待來自其他服務的請求，然後再繼續其他工作。這是事件驅動型架構的基本特性，可實現可擴展性和彈性。這意味著傳遞傳回值或工作流程的結果會比同步執行流程更複雜。 生產系統中的大多數 Lambda 調用都是[非同步的](invocation-async.md)，可回應來自 Amazon S3 或 Amazon SQS 等服務的事件。在這些情況下，處理事件的成功或失敗通常比傳回值更重要。在 Lambda 中提供[無效字母佇列](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQ) 等功能，以確保您可以識別和重試失敗的事件，而無需通知呼叫者。 ### 跨服務和函數進行偵錯 與單體式應用程式相比，偵錯事件驅動型系統的方式也有所不同。由於傳遞事件的系統和服務不同，因此無法在發生錯誤時記錄和重現多個服務的確切狀態。由於每個服務和函數調用都具有單獨的日誌檔案，因此確定導致錯誤的特定事件發生的情況可能更複雜。 在事件驅動型系統中成功建置偵錯方法有三個重要要求。首先，強大的記錄系統至關重要，這由 Amazon CloudWatch 跨 AWS 服務提供，並內嵌在 Lambda 函數中。其次，在這些系統中，請務必確保每個事件都具有一個交易識別碼，該識別碼在整個交易的每個步驟中都會記錄下來，以在搜尋日誌時提供協助。 最後，強烈建議使用偵錯和監控服務 (例如 AWS X-Ray) 來自動化日誌的剖析和分析。這可以跨多個 Lambda 調用和服務取用日誌，讓您更輕鬆地找出問題的根本原因。如需有關使用 X-Ray 進行疑難排解的深度資訊，請參閱[疑難排解演練](lambda-troubleshooting.md)。 ## 基於 Lambda 的事件驅動型應用程式反模式 使用 Lambda 建置事件驅動型架構時，請避免下列常見的反模式。這些模式有效，但可能會增加成本和複雜性。 ### Lambda 單體 在許多從傳統伺服器 (例如 Amazon EC2 執行個體或 Elastic Beanstalk 應用程式) 遷移而來的應用程式中，開發人員通常會採用「直接移轉」的方式沿用現有程式碼。通常，這會產生單一 Lambda 函數，其中包含針對所有事件觸發的所有應用程式邏輯。對於基本 Web 應用程式，單體式 Lambda 函數會處理所有 API Gateway 路由，並與所有必要的下游資源整合。 ![\[事件驅動型架構圖 13\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-13.png) 此方法有數個缺點： + **套件大小** – Lambda 函數可能較大，因為它包含所有路徑的所有可能程式碼，這使得 Lambda 服務執行速度變慢。 + **難以強制執行最低權限**：函式的[執行角色](lambda-intro-execution-role.md)必須允許所有路徑所需的所有資源的許可，導致許可範圍非常廣泛。這是一個安全隱患題。功能單體中的許多路徑不需要所有已授予的許可。 + **更難升級**：在生產系統中，對單一函式的任何升級風險都較大，可能導致整個應用程式中斷運作。升級 Lambda 函數中的單一路徑就是對整個函數的升級。 + **更難維護**：由於程式碼儲存庫為單體架構，多位開發人員協同處理服務時會面臨更多困難。它也會增加開發人員的認知負擔，並使為程式碼建立適當的測試涵蓋範圍變得更加困難。 + **更難重複使用程式碼**：更加難以將可重複使用的程式庫與單體分隔，導致程式碼重複使用變得更加困難。當您開發和支援更多專案時，這可能會讓支援程式碼和擴展團隊速度變得更加困難。 + **更難測試**：隨著程式碼行數的增加，對程式碼庫中所有可能的輸入和進入點組合進行單元測試會更加困難。對於程式碼較少的小型服務，實作單元測試通常更容易。 首選的替代方案是將單體 Lambda 函數分解為個別微服務，將單一 Lambda 函數映射至單一定義良好的任務。在這個具有幾個 API 端點的簡易 Web 應用程式中，產生的微服務型架構可以基於 API Gateway 路由。 ![\[事件驅動型架構圖 14\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-14.png) ### 導致 Lambda 函數失控的遞迴模式 AWS 服務會產生叫用 Lambda 函數的事件，而 Lambda 函數可以將訊息傳送到 AWS 服務。通常，調用 Lambda 函數的服務或資源應與函數輸出至的服務或資源不同。如果不進行管理，可能會導致無限迴圈。 例如，Lambda 函式會將物件寫入 Amazon S3 物件，進而透過 put 事件調用同一個 Lambda 函式。調用會導致第二個物件寫入儲存貯體，這會調用相同的 Lambda 函數： ![\[事件驅動型架構圖 15\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-15.png) 雖然大多數程式設計語言都存在無限迴圈的可能性，但此反模式有可能在無伺服器應用程式中取用更多資源。Lambda 和 Amazon S3 都會根據流量自動擴展，因此迴圈可能會導致 Lambda 擴展以使用所有可用的並行，Amazon S3 將繼續寫入物件並為 Lambda 產生更多事件。 此範例以 S3 為例，但 Amazon SNS、Amazon SQS、DynamoDB 及其他服務中也存在遞迴迴圈的風險。您可以使用[遞迴迴圈偵測](invocation-recursion.md)功能，找出並避免此反模式。 ### 呼叫 Lambda 函數的 Lambda 函數 函數支援封裝和程式碼重複使用。大多數程式設計語言都支援程式碼同步呼叫程式碼庫中的函數的概念。在此情況下，呼叫者會等到函數傳回回應。 **注意** 雖然 Lambda 函數因為成本和複雜性問題而直接呼叫其他 Lambda 函數通常是反模式，但這不適用於[耐用函數](durable-functions.md)，其專門設計來調用其他函數來協調多步驟工作流程。 當傳統伺服器或虛擬執行個體發生這種情況時，作業系統排程器會切換至其他可用的工作。CPU 以 0% 還是 100% 執行並不影響應用程式的整體成本，因為您要支付擁有和營運伺服器的固定成本。 此模型通常無法很好地適應無伺服器開發。例如，請考慮一個由三個處理訂單的 Lambda 函數組成的簡易電子商務應用程式： ![\[事件驅動型架構圖 16\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-16.png) 在此案例中，*Create order* 函數會呼叫 *Process payment* 函數，進而呼叫 *Create invoice* 函數。雖然此同步流程可能在伺服器上的單一應用程式內運作，但在分散式無伺服器架構中引入了幾個可避免的問題： + **成本**：使用 Lambda 時，您需要支付調用期間的費用。在此範例中，當 *Create invoice* 函式執行時，其他兩個函式也會在等待狀態下執行，在圖表上以紅色顯示。 + **錯誤處理**：在巢狀調用中，錯誤處理可能會變得更複雜。例如，*建立發票*中的錯誤可能需要*程序付款*函數來撤銷費用，或者可能改為重試*建立發票*程序。 + **緊耦合**：處理付款通常比建立發票需要更長時間。在此模型中，整個工作流程的可用性受最慢函數限制。 + **擴展**：所有三個函式的[並行](lambda-concurrency.md)必須相等。在忙碌的系統中，這會使用比其他方式需要更多的並行。 在無伺服器應用程式中，有兩種​​常見方法可以避免此模式。首先，在 Lambda 函式之間使用 Amazon SQS 佇列。如果下游程序比上游程序更慢，佇列會長期保留訊息，並解耦這兩個函數。在此範例中，*建立訂單*函數會將訊息發佈至 Amazon SQS 佇列，而*程序付款*函數會使用來自佇列的訊息。 第二個方法是使用 AWS Step Functions。對於具有多種類型的故障和重試邏輯的複雜程序，Step Functions 有助於減少協調工作流程所需的自訂程式碼數量。因此，Step Functions 會協調工作並穩健地處理錯誤和重試，而 Lambda 函數僅包含商業邏輯。 ### 在單一 Lambda 函數內的同步等待 請確定未在單一 Lambda 函數中同步排程任何可能並行的活動。例如，Lambda 函數可能會寫入 S3 儲存貯體，然後寫入 DynamoDB 資料表： ![\[事件驅動型架構圖 17\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-17.png) 在此設計中，由於各項互動採取循序執行方式，等待時間會逐漸累積放大。若第二個任務需依賴第一個任務完成，您可透過兩個獨立的 Lambda 函式來減少總等待時間與執行成本： ![\[事件驅動型架構圖 19\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-19.png) 在此設計中，第一個 Lambda 函式會在將物件放入 Amazon S3 儲存貯體之後立即回應。S3 服務會調用第二個 Lambda 函數，然後將資料寫入至 DynamoDB 資料表。此方法可將 Lambda 函數執行的總等待時間降至最低。 # 設計 Lambda 應用程式 架構良好的事件驅動應用程式使用 AWS 服務和自訂程式碼的組合來處理和管理請求和資料。本章著重介紹應用程式設計中與 Lambda 相關的主題。在為忙碌的生產系統設計應用程式時，無伺服器架構師有許多重要的考量。 許多適用於軟體開發和分散式系統的最佳實務，也適用於無伺服器應用程式開發。整體目標是開發符合下列條件的工作負載： + **可靠** – 為您的最終使用者提供高水準的可用性。 AWS 無伺服器服務是可靠的，因為其亦專為解決故障而設計。 + **耐久** – 提供符合工作負載耐久性需求的儲存選項。 + **安全** – 遵循最佳實務，並使用提供的工具來保護對工作負載的存取，並在發生任何問題時限制影響範圍。 + **高效能** – 有效率地使用運算資源，並滿足最終使用者的效能需求。 + **具成本效益** – 設計可避免不必要的成本的架構，這些架構可以在不超支的情況下進行擴展及除役，而不會產生大量開銷。 下列設計原則可協助您建置符合這些目標的工作負載。並非每一項原則都適用於所有架構，但這些原則應能為您的總體架構決策提供指引。 **Topics** + [ ## 使用服務而非自訂程式碼 ](#services-custom-code) + [ ## 了解 Lambda 抽象層級 ](#level-abstraction) + [ ## 在函式中實作無狀態 ](#statelessness-functions) + [ ## 最小化耦合度 ](#minimize-coupling) + [ ## 針對隨選資料而非批次處理進行建置 ](#on-demand-batches) + [ ## 選擇複雜工作流程的協同運作選項 ](#orchestration) + [ ## 實作冪等性 ](#retries-failures) + [ ## 使用多個 AWS 帳戶來管理配額 ](#multiple-accounts) ## 使用服務而非自訂程式碼 無伺服器應用程式通常包含數個 AWS 服務，與 Lambda 函數中執行的自訂程式碼整合。雖然 Lambda 可以與大多數 AWS 服務整合，但無伺服器應用程式中最常使用的服務如下： | Category | AWS 服務 | | --- | --- | | 運算 | AWS Lambda | | 資料儲存 | Amazon S3 Amazon DynamoDB Amazon RDS | | API | Amazon API Gateway | | 應用程式整合 | Amazon EventBridge Amazon SNS Amazon SQS | | 協調 | Lambda 耐用函數 AWS Step Functions | | 串流資料和分析 | Amazon Data Firehose | **注意** 許多無伺服器服務皆提供資料複寫功能與多區域支援，包括 DynamoDB 與 Amazon S3。Lambda 函數可以作為部署管道的一部分部署在多個區域中，並且可以將 API Gateway 設定為支援此組態。請參閱此[範例架構](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card)，其示範如何實現這一點。 分散式架構中有許多建立良好的常見模式，您可以使用 AWS 服務自行建置或實作。對於大多數客戶，投資時間從頭開始開發這些模式幾乎沒有商業價值。當您的應用程式需要其中一個模式時，請使用對應的 AWS 服務： | 模式 | AWS 服務 | | --- | --- | | 佇列 | Amazon SQS | | 事件匯流排 | Amazon EventBridge | | 發布/訂閱 (扇出) | Amazon SNS | | 協調 | Lambda 耐用函數 AWS Step Functions | | API | Amazon API Gateway | | 事件串流 | Amazon Kinesis | 這些服務旨在與 Lambda 整合，您可以使用基礎設施即程式碼 (IaC) 來建立和捨棄服務中的資源。您可以透過 [AWS SDK](https://aws.amazon.com/tools/) 使用其中任何服務，而無需安裝應用程式或設定伺服器。熟悉透過 Lambda 函數中的程式碼使用這些服務，是生產設計良好的無伺服器應用程式的重要步驟。 ## 了解 Lambda 抽象層級 Lambda 服務會限制您對執行 Lambda 函數和基礎作業系統、Hypervisor 和硬體的存取。此服務會持續改善和變更基礎設施，以新增功能、降低成本，並提高服務效能。您的程式碼應假設不了解 Lambda 的架構方式，且假設沒有硬體親和性。 同樣地，Lambda 與其他 服務的整合是由 管理 AWS，只有少量的組態選項會公開給您。例如，API Gateway 與 Lambda 互動時無需考慮負載平衡，因為這項功能已完全由服務本身管理。您也無法直接控制服務在任何時間點調用函式時所使用的[可用區域](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)，亦無法控制 Lambda 如何決定執行環境數量的向上擴展或縮減時機。 此抽象概念可協助您專注於應用程式的整合層面、資料流程，以及工作負載為最終使用者提供價值的商業邏輯。允許服務管理基礎機制可協助您更快速地開發應用程式，同時減少要維護的自訂程式碼。 ## 在函式中實作無狀態 對於標準 Lambda 函數，您應該假設環境僅存在於單一調用中。函式應在首次啟動時初始化任何必要的狀態。例如，函式可能需要從 DynamoDB 資料表擷取資料。在結束前，函式應將所有永久性資料變更提交至 Amazon S3、DynamoDB 或 Amazon SQS 等耐久存放區。其不應依賴任何現有的資料結構或暫存檔案，或任何需要多次調用才能管理的內部狀態。 使用耐用函數時，狀態會在叫用之間自動保留，無需手動將狀態保留到外部儲存體。不過，對於未透過 DurableContext 明確管理的任何資料，您仍應遵循無狀態原則。 若要初始化資料庫連線與程式庫，或是載入狀態資訊，您可以使用[靜態初始化](lambda-runtime-environment.md#static-initialization)功能。由於執行環境會盡可能重複使用以改善效能，因此您可以在多次調用中分攤初始化這些資源所花費的時間。但是，您不應在此全域範圍內儲存函數中使用的任何變數或資料。 ## 最小化耦合度 大多數架構應偏好許多、較短的函數，而不是較少、較大的函數。每個函數的用途應該是處理傳遞到函數的事件，而無需了解或預期整個工作流程或交易量。這使得此函數與事件來源無關，且與其他服務的耦合最少。 任何不常變更的全域範圍常數都應作為環境變數實作，以允許在不部署的情況下進行更新。任何機密或敏感資訊都應儲存在 [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) 或 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) 中，並由函數載入。由於這些資源具有帳戶專屬特性，您可建立跨多個帳戶的建置管道。管道根據環境載入適當的機密，而無需向開發人員公開這些機密，也無需變更任何程式碼。 ## 針對隨選資料而非批次處理進行建置 許多傳統系統旨在定期執行並處理隨著時間累積的交易批次。例如，銀行應用程式可能每小時執行一次，以處理中央分類帳中的 ATM 交易。在 Lambda 型應用程式中，每個事件都應觸發自訂處理，從而允許服務視需要向上擴展並行，以提供近乎即時的交易處理。 雖然標準 Lambda 函數的執行時間限制為 15 分鐘，但耐用函數最多可執行一年，因此適合長時間執行的處理需求。不過，您仍然應該盡可能偏好事件驅動型處理，而不是批次處理。 雖然您可以透過使用 Amazon EventBridge 中規則的[排程表達式](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html)，在無伺服器應用程式中執行 [cron](https://en.wikipedia.org/wiki/Cron) 任務，但應謹慎使用或作為最後的手段。在任何採用批次處理模式的排程任務中，交易量都有可能增長到超出 Lambda 15 分鐘時間限制內可以處理的數量。如果外部系統的限制迫使您使用排程器，您通常應排程最短的合理重複時段。 例如，使用批次程序觸發 Lambda 函式來擷取新的 Amazon S3 物件清單並非最佳實務。這是因為服務在批次之間接收到的新物件可能多於 15 分鐘 Lambda 函數內可以處理的物件。 ![\[事件驅動型架構圖 10\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-10.png) 相反，Amazon S3 儲存貯體應在每次有新物件放入其中時都調用 Lambda 函式。此方法的可擴展性顯著提高，並且可以近乎即時地進行處理。 ![\[事件驅動型架構圖 11\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/event-driven-architectures-figure-11.png) ## 選擇複雜工作流程的協同運作選項 涉及分支邏輯、不同類型故障模型與重試邏輯的工作流程，通常會使用協調器來追蹤整體執行的狀態。請勿在標準 Lambda 函數中建置臨機操作協同運作。這會導致緊密耦合、複雜的路由代碼，而且沒有自動狀態復原。 請改用下列其中一個專用協同運作選項： + **[Lambda 耐久函數](durable-functions.md)：**以應用程式為中心的協同運作，使用標準程式設計語言搭配自動檢查點、內建重試和執行復原。非常適合偏好將工作流程邏輯與 Lambda 內的商業邏輯一起保存在程式碼中的開發人員。 + **[AWS Step Functions](with-step-functions.md)：**視覺化工作流程協同運作與 220 多種 AWS 服務的原生整合。非常適合用於多服務協調、零維護基礎設施和視覺化工作流程設計。 如需在這些選項之間進行選擇的指引，請參閱[耐用函數或 Step Functions](durable-step-functions.md)。 透過 [ Step Functions](https://aws.amazon.com/step-functions/)，您可以使用狀態機器來管理協同運作。這會從您的程式碼擷取錯誤處理、路由和分支邏輯，並將其取代為使用 JSON 宣告的狀態機器。除了提升工作流程的穩健性與可觀測性之外，您還可以為工作流程新增版本控制功能，並將狀態機器轉化成可新增至程式碼儲存庫的編碼資源。 Lambda 函式中的簡易工作流程，往往會隨著時間推移逐漸變得更加複雜。操作生產無伺服器應用程式時，請務必識別何時發生這種情況，以便將此邏輯遷移至狀態機器或耐用函數。 ## 實作冪等性 AWS 無伺服器服務，包括 Lambda，具有容錯能力，旨在處理故障。例如，若某項服務調用 Lambda 函式時發生服務中斷，Lambda 會自動在另一個可用區域中調用您的函式。如果您的函式擲回錯誤，Lambda 會重試此調用請求。 由於同一事件可能會被多次接收，因此函數應設計為[等冪](https://en.wikipedia.org/wiki/Idempotence)。這意味著多次接收同一事件不會在第一次收到事件之後變更結果。 您可在 Lambda 函式中實作冪等性：透過 DynamoDB 資料表追蹤近期處理過的識別碼，藉此判斷該交易先前是否已處理完畢。DynamoDB 資料表通常實作[存留時間 (TTL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) 值來使項目過期，以限制所使用的儲存空間。 ## 使用多個 AWS 帳戶來管理配額 中的許多[服務配額](gettingstarted-limits.md) AWS 是在帳戶層級設定。這表示隨著您新增更多工作負載，可能會快速用盡配額上限。 解決此問題的有效方法是使用多個 AWS 帳戶，將每個工作負載分配到自己的 帳戶。這樣可防止與其他工作負載或非生產資源共用配額。 此外，您可以透過 [AWS Organizations](https://aws.amazon.com/organizations/) 集中管理這些帳戶的帳單、合規性與安全性。您可以將政策連接到帳戶群組，避免自訂指令碼和手動程序。 一種常見的方法是為每個開發人員提供 AWS 帳戶，然後針對 Beta 部署階段和生產環境使用不同的帳戶： ![\[應用程式設計圖 3\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/application-design-figure-3.png) 在此模型中，每位開發人員的帳戶都具備獨立的配額限制，因此其資源使用行為不會影響您的生產環境。此做法還能讓開發人員在本機開發環境中測試 Lambda 函式，並直接對接其個人帳戶中的真實雲端資源。