極致彈性架構：Lambda、EventBridge 與無伺服器微服務實戰

我第一次把一套同步的訂單流程改寫成事件驅動的時候，最不習慣的不是新服務要怎麼設定，而是「我看不到整條流程了」這件事。原本一路讀下來的程式碼，散成了好幾個各自獨立的片段。

這篇要把這件事講清楚：事件驅動到底改變了什麼、Lambda 在 2026 年已經長成什麼樣子、EventBridge 的三種形狀怎麼選，以及一條可以照著走的落地順序。

無伺服器真正改變的不是機器誰來開，而是你怎麼切邊界、怎麼描述因果，以及出事的時候你要去哪裡看。

先換一種因果觀：從呼叫別人，變成宣告事實

傳統微服務的預設動作是呼叫。訂單服務做完事，主動去呼叫庫存服務、通知服務、對帳服務。代價很清楚：訂單服務必須知道所有下游是誰。

事件驅動把方向反過來。訂單服務只負責宣告一件事實：訂單成立了。誰要理它、要做什麼，是接收端自己的事。

AWS 官方文件對這種風格的描述是「鬆耦合的軟體系統，靠發出事件與回應事件一起運作」。這句話聽起來抽象，但它的實際影響非常具體。

• 耦合方向改變：上游只依賴事件的格式，不依賴下游存不存在。
• 失敗被隔離：某個消費端出錯，不會沿著呼叫堆疊往回炸到使用者面前。
• 擴充成本降低：多接一個下游，通常只是多寫一條規則。
• 代價也很真實：整條流程沒有一份可以逐行讀完的程式碼，可觀測性要另外投資。

Lambda 的運算模型與它的邊界

Lambda 的模型可以用一句話講完：你交出一段函式，有事件的時候 AWS 幫你把它跑起來，沒事件的時候什麼都不留。它擅長的工作有很固定的形狀。

• 被事件觸發，而不是自己輪詢等待。
• 每次執行都能獨立完成，不需要記得上一次做了什麼。
• 可以水平展開，一次來一千筆就跑一千份。
• 執行時間有界，不是一開就要活好幾天。

反過來，需要長時間常駐、需要在記憶體裡累積狀態、或是對啟動延遲極度敏感的互動路徑，就要先想清楚再決定。逾時上限、記憶體上限這類數字會隨版本調整，規劃時請直接查官方文件的當期值。

2026 年的 Lambda 已經不只一種跑法

如果你對 Lambda 的印象還停在「一段短函式配一個 handler」，這裡要更新一下。官方產品頁目前的講法是一個服務、多種執行方式。

這件事對架構師的意義是：「Lambda 不夠用就得換別的服務」這個舊假設，值得重新檢查一次。

EventBridge：匯流排、管線與排程三種形狀

官方使用者指南把 EventBridge 的事件處理與投遞分成兩種方式：事件匯流排與管線，另外再加上一個排程器。三者解的問題不一樣。

• 事件匯流排：多來源對多目標的路由器。你在上面寫規則，依事件內容過濾，投遞到零個到多個目標，投遞前還可以做轉換。
• 管線：點對點整合。一條管線一個來源、一個目標，中間支援進階的轉換與資料強化。
• 排程器：用 cron 或 rate 表達式管理週期任務，也能設定一次性觸發，並可設定彈性投遞時間窗、重試上限與保留時間。

官方文件提到一個很實用的組合：把管線的目標設成事件匯流排。管線負責把某條資料流標準化成乾淨的事件，匯流排負責依規則散發給所有訂閱者。

Step Functions：把流程從程式碼裡拿出來

事件一多，你會遇到一個尷尬的問題：這條流程到底長什麼樣子？如果答案散在五個函式的例外處理裡，就沒有人講得完整。

Step Functions 的價值是把順序、重試、補償與分支變成一份可以被讀、被畫、被版本控制的定義。官方的定位是用視覺化工作流建構與編排分散式應用。

{
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Next": "ChargePayment"
    },
    "ChargePayment": {
      "Type": "Task",
      "Retry": [ { "ErrorEquals": [ "..." ] } ],
      "Catch": [ { "Next": "CompensateOrder" } ],
      "Next": "Fulfill"
    },
    "CompensateOrder": { "Type": "Task", "End": true },
    "Fulfill":         { "Type": "Task", "End": true }
  }
}

上面只是結構示意，用來說明「重試與補償被寫在流程定義裡，而不是塞在函式裡」這件事。實際的欄位名稱與可用屬性，請以官方的 Amazon States Language 文件為準。

2026 年官方頁面另外把代理式工作流列為主要使用情境之一，強調跨公有與私有端點的整合，以及把人放進迴圈的觀測與控制。

API Gateway：同步入口怎麼切

事件驅動不代表沒有同步入口。瀏覽器、合作夥伴的 webhook、手機應用程式，都需要一個會立刻回話的 HTTP 端點。

• REST API：需要完整的 API 管理能力時選它，官方定位是把代理功能與管理功能放在同一個方案裡。
• HTTP API：官方說法是「只需要代理功能時的最佳選擇」，適合單純把請求轉給後端的場景。
• WebSocket API：需要雙向即時通訊時選它，官方舉的例子是聊天應用與即時儀表板。

2025 年 11 月官方另外推出了 API Gateway 的入口功能（Portals），把 REST API 的探索、文件與治理集中起來。內部 API 一多，這件事的價值會超過預期。

設計原則其實只有一條：入口只做入口該做的事。驗證身分、擋掉明顯不合法的請求、把事情交出去，然後盡快回應。真正的工作留給後面的事件流。

一條務實的落地順序

1. 先畫事件，不要先畫服務。 把業務上真的發生過的事實列出來，例如訂單成立、付款失敗、庫存不足，那才是你的邊界。
2. 把事件當契約來管。 事件格式要有版本策略，因為改事件欄位比改 API 更容易無聲地弄壞下游。
3. 同步與非同步分線。 使用者要立刻看到的走 API Gateway 加 Lambda，可以晚一點的丟上匯流排。
4. 多步流程交給編排服務。 不要在函式裡手寫狀態機，那份狀態遲早會跟現實對不上。
5. 第一天就補齊三件事。 死信佇列、重試策略、分散式追蹤，事件驅動的除錯成本全部押在這一步。