在無伺服器架構中，有效整合服務並減少 Lambda 函式的使用是提升效率的關鍵。本文介紹了幾種整合模式，例如利用 DynamoDB 實作斷路器，使用 EventBridge 的歸檔和重播功能管理事件，以及 Outbox 模式確保資料一致性。此外，也探討了無函式整合模式，示範如何利用 API Gateway、Step Functions 和 EventBridge 等服務，直接串接 AWS 服務，減少自定義程式碼與管理成本。最後，文章也介紹了 API Destinations 的應用，說明如何簡化與外部 HTTP API 的整合，進一步提升無伺服器架構的效率和彈性。
伺服器無法模式：斷路器模式
斷路器模式是一種常見的伺服器無法模式，用於處理伺服器之間的依賴關係。當伺服器A依賴伺服器B時，如果伺服器B出現故障，伺服器A可能會不斷嘗試連線伺服器B，導致伺服器A的效能下降甚至當機。斷路器模式可以解決這個問題，當伺服器B出現故障時，斷路器會開啟，伺服器A不再嘗試連線伺服器B，直到伺服器B還原正常。
使用DynamoDB實作斷路器模式
使用DynamoDB實作斷路器模式的思路是建立一個表格來儲存請求的不同階段。每個階段都有一個唯一的ID，例如SOURCE、TRANSFORMED、SUBMITTED等。這樣可以清晰地分離資料專案，並幫助追蹤資料流程。
然而，這種方法有一個主要缺點：當斷路器關閉時，需要觸發一個Lambda函式或Step Functions工作流程來查詢表格中的專案以重新播放。對於高流量的請求流，使用案例，由於DynamoDB的查詢結果大小限制為1 MB，可能需要反覆呼叫這個函式，且清除選項可能需要很長時間。
使用EventBridge的歸檔和重播功能
EventBridge的歸檔和重播功能提供了一種新的實作斷路器模式的方法。當斷路器開啟時，建立一個具有重試身份的事件並將其傳送到自定義事件匯流排。一個規則過濾重試事件並將其路由到EventBridge歸檔中。
當斷路器關閉時，啟動歸檔中事件的重播，指定時間範圍（對應於停機時間）。EventBridge將歸檔中的事件放置在匯流排上。設定一個規則來過濾這些重播的事件並將其處理為重新提交。
使用EventBridge歸檔和重播有其優點。沒有限制可以儲存在歸檔中的事件數量，使其能夠處理長時間的停機和高流量的請求流。另外，EventBridge在請求時間範圍內重播事件，消除了實作額外邏輯以在頻繁間隔內取得事件的需要。
然而，也有一些限制需要注意。EventBridge不保證事件的順序，而且不能控制重播期間事件的速度。此外，目前沒有選項可以從歸檔中刪除已重播的事件，因此需要維護每次重播時間範圍的日誌，以避免多次重播事件。
Outbox模式
Outbox模式是一種應用程式持久化資料到“outbox”表格中，以便另一個應用程式可以讀取和處理資料或將其轉發到佇列中。這種模式常見於伺服器無法開發中，特別是在事務性outbox模式中。
在事務性outbox模式中，一個Lambda函式處理來自資料並執行兩個動作：寫入DynamoDB表格和傳送事件到事件匯流排或新增訊息到佇列中。兩個動作都必須成功才能完成功能。為了減少這種風險，可以簡化過程，先將資料寫入outbox表格中，然後再傳送事件或新增訊息到佇列中。
無函式整合模式
無函式整合模式是一種減少使用Lambda函式的伺服器無法架構方法。雖然作為工程師，你經常聽到“程式碼是一種負債”的說法，但你知道不能沒有程式碼就建造應用程式。在伺服器無法中，你使用管理雲端服務來組成應用程式。在這種情況下，無函式整合意味著你不再手工編碼Lambda函式來連線或整合兩個或多個服務；相反，你使用現成功能和基礎設施即程式碼（IaC）來將這些服務串聯起來。
無函式整合模式有幾個優點：
- 減少程式碼：你編寫、測試、佈署和營運的程式碼越少越好。
- 減少故障點和除錯麻煩。
- 組態更少的IAM策略和許可權，意味著更少的安全問題。
- 減少超出Lambda並發執行配額的風險。
- 降低每月Lambda函式的成本。
雖然如果你只有少量Lambda函式，你可能不會覺得這種模式很吸引人，但當你考慮它對整個組織的潛在益處時，你就會明白它可以產生很大的積極影響。
伺服器無服務架構中的無函式整合應用案例
在伺服器無服務架構中，有多個部分可以減少Lambda函式的使用。然而，實作細節取決於您的業務領域和您使用的AWS服務。讓我們探討一些如何減少自定義程式碼的例子，從而實作無函式整合。
常見的AWS服務整合
以下是一些流行的AWS服務，它們可以幫助減少伺服器無服務應用中Lambda函式的數量：
Amazon API Gateway
API Gateway支援將超過100個AWS服務作為API端點的後端。實作細節中取代Lambda函式的部分是一個簡短的整合指令碼，使用Velocity Template Language（VTL）編寫，提供API Gateway和目標服務之間的連線。
以下是一個示例VTL指令碼，該指令碼從傳入API請求負載中提取資料，將其新增為EventBridge事件負載主體下的詳細部分，並將事件釋出到您的自定義事件匯流排：
{
"Entries": [
{
"DetailType": "customer-registered",
"Source": "service-customers",
"EventBusName": "your-custom-bus",
"Detail": "$util.escapeJavaScript($input.json('$'))"
}
]
}
AWS Step Functions
AWS Step Functions直接與Amazon DynamoDB、SQS、SNS、EventBridge等服務整合。此外，使用AWS SDK，您可以在不編寫Lambda函式的情況下從工作流程中與數百個AWS服務整合。
以下是一個示例VTL指令碼，該指令碼從請求負載主體中提取資料並將其作為輸入提供給Step Functions工作流程：
#set( $body = $util.escapeJavaScript($input.json('$')) )
{
"input": "{\"body\": $body}",
"name": "$context.requestId",
"stateMachineArn": "<arn-of-your-step-function>"
}
AWS Step Functions支援兩種型別的工作流程：標準和Express。雖然標準工作流程是非同步的，可以執行長達一年，但Express工作流程支援同步和非同步呼叫，可以執行長達五分鐘。由於其支援同步呼叫，Express工作流程已成為與API Gateway端點整合的熱門選擇，該端點提供請求/回應式呼叫模式，這是無函式整合的關鍵領域。
Amazon EventBridge
作為事件匯流排或微服務的編舞者，EventBridge提供了多種方法來減少編寫函式程式碼的需求。幾個AWS服務可以直接向EventBridge傳送事件，而幾個服務可以直接從EventBridge接收事件。雖然您可能有一些場景需要Lambda函式在將事件釋出到EventBridge之前執行一些邏輯，但無函式方法的動機是評估在沒有函式的情況下整合的可能性——無函式優先原則！
以下是示例Amazon States Language（ASL）指令碼，用於釋出Step Functions到EventBridge自定義事件匯流排的事件：
{
"Put SNS topic subscription event to event bus": {
"Next": "Create EventBridge Rule",
"Type": "Task",
"ResultPath": null,
"Resource": "arn:aws:states:::events:putEvents",
"Parameters": {
//...
}
}
}
ASL是一種根據JSON的結構化語言，用於定義狀態機（一組狀態、任務、狀態轉換等）。
圖表翻譯：
flowchart TD
A[API Gateway] --> B[Step Functions]
B --> C[EventBridge]
C --> D[目標服務]
D --> E[處理結果]
此圖表展示了API Gateway、Step Functions和EventBridge之間的工作流程，最終到達目標服務並處理結果。
內容解密：
上述示例展示瞭如何使用VTL指令碼和ASL指令碼實作無函式整合。透過使用API Gateway、Step Functions和EventBridge，您可以減少對Lambda函式的需求，並建立更高效、更可擴充套件的伺服器無服務架構。這些服務提供了一種簡單、靈活的方式來整合AWS服務，而無需編寫自定義程式碼。
無伺服器架構中的功能整合模式
在無伺服器架構中，減少對函式程式碼的需求是非常重要的。除了Amazon DynamoDB和S3提供的自動化資料清除功能外，還有其他服務和功能可以幫助您實作這一目標。例如，AWS AppSync可以簡化GraphQL的開發，而Amazon SNS則允許您向數百萬使用者傳送通知，而無需撰寫Lambda函式。
使用DynamoDB進行序列號生成
傳統的關聯式資料函式庫系統通常提供序列號生成功能，用於為每日使用案例（如訂單號碼、候選人號碼、網站存取次數等）提供唯一的遞增號碼。然而，在NoSQL資料儲存中，如DynamoDB，您需要使用原子計數器來實作此功能。
原子計數器是一個可以透過UpdateItem操作原子性更新的數值屬性。您可以將其與API Gateway整合，提供序列號生成服務。以下是使用DynamoDB和API Gateway實作功能整合模式的範例。
實作序列號生成服務
首先，您需要建立一個DynamoDB表格來儲存序列號值。然後，您可以組態API Gateway來接收序列號型別（如訂單、候選人或存取者）作為查詢引數，並傳回相應的遞增值。
以下是您可以用於組態API請求對映範本的VTL指令碼範例：
{
"TableName": "sequence-numbers",
"Key": {
"sequence_type": "order"
},
"UpdateExpression": "set #seq = #seq + :incr",
"ExpressionAttributeNames": {
"#seq": "sequence_value"
},
"ExpressionAttributeValues": {
":incr": {
"N": "1"
}
},
"ReturnValues": "UPDATED_NEW"
}
此指令碼更新DynamoDB表格中的序列號值，並傳回新的值。
圖表翻譯：
此圖表示了使用DynamoDB和API Gateway實作序列號生成服務的架構。
flowchart TD
A[API Gateway] --> B[DynamoDB]
B --> C[Sequence Number Generation]
C --> D[Return Incremented Value]
D --> A
此圖顯示了API Gateway如何接收請求，然後更新DynamoDB表格中的序列號值，並傳回新的值。
內容解密：
在此範例中，我們使用DynamoDB的原子計數器功能來實作序列號生成服務。原子計數器是一個可以透過UpdateItem操作原子性更新的數值屬性。透過將其與API Gateway整合，我們可以提供序列號生成服務，而無需撰寫Lambda函式。
此實作方式具有以下優點：
- 減少對函式程式碼的需求
- 提高系統的可擴充套件性和可靠性
- 簡化了序列號生成服務的實作
然而，需要注意的是，此實作方式需要仔細設計和組態，以確保正確性和效率。
伺服器無法使用的整合模式
在設計伺服器無法使用的架構時，開發人員常常會遇到需要與外部HTTP API進行互動的需求。例如，當客戶註冊成功後，需要將其同意接收新聞郵件、促銷郵件、產品更新等的偏好設定儲存到外部應用程式中。這種情況下，開發人員可以使用API目的地（API Destinations）來簡化架構。
什麼是API目的地？
API目的地是Amazon EventBridge的一個功能，允許開發人員將HTTP端點組態為事件路由規則的目標。這樣就可以使用RESTful API呼叫來與應用程式進行原生整合，從而消除了對Lambda函式的需求。
使用API目的地的優點
使用API目的地可以簡化架構，減少Lambda函式的複雜性。以下是使用API目的地的一些優點：
- 簡化架構：API目的地可以消除對Lambda函式的需求，從而簡化架構。
- 提高安全性：API目的地提供了高度安全的功能，例如OAuth驗證和授權。
- 提高開發速度：API目的地可以幫助開發人員快速整合外部應用程式，從而提高開發速度。
使用API目的地的範例
假設我們有一個客戶註冊服務，需要將客戶的偏好設定儲存到外部應用程式中。以下是使用API目的地的範例：
- 建立事件橋：建立一個事件橋（EventBridge），並組態事件路由規則。
- 組態API目的地：組態API目的地為事件路由規則的目標。
- 傳送事件：當客戶註冊成功後，傳送一個事件到事件橋。
- 觸發API呼叫：事件橋接收到事件後，觸發API呼叫到外部應用程式。
圖表翻譯：
此圖表示客戶註冊服務與外部應用程式之間的互動過程。當客戶註冊成功後，客戶註冊服務傳送一個事件到事件橋。事件橋接收到事件後，觸發API呼叫到外部應用程式。外部應用程式儲存客戶的偏好設定到資料函式庫中。
從技術架構視角來看，本文深入探討了多種無伺服器整合模式，特別聚焦於減少Lambda函式使用，從而降低營運成本和複雜度。對比分析DynamoDB實作斷路器模式、EventBridge歸檔重播以及Outbox模式，可以發現，EventBridge方案在處理高流量請求和長時間停機方面更具優勢，但需要額外處理事件順序和重播控制等問題。此外，無函式整合模式的應用，例如利用API Gateway、Step Functions和EventBridge直接整合AWS服務，有效簡化了架構並提升了開發效率。然而，並非所有場景都適用無函式整合，仍需根據實際需求權衡。展望未來，隨著AWS服務的持續演進和更多原生整合方案的推出，預計無函式整合模式將成為伺服器無服務架構的主流趨勢，進一步降低開發門檻並提升應用程式效能。對於追求高效、精簡架構的團隊，優先探索並應用無函式整合模式將是提升競爭力的關鍵策略。
