這個被忽視四年的AWS功能，讓我省下一半成本

2020年，AWS發布了一個功能，當時沒多少人當回事。四年過去，用它的人開始偷偷省錢。

synchronous Express Workflows——同步快速工作流。名字拗口，但用起來像給Lambda裝了個大腦。作者去年大規模試了一年，結論是：這才是構建微服務的正確姿勢。

Lambda的甜蜜與苦澀

Lambda是AWS無服務器的門面。輸入輸出，簡單直接，"把這個消息入隊"或"按key取數據庫記錄"——這種活它干得很漂亮。

但現實復雜得多。一個同步請求里要做多件事，要有分支邏輯，要處理錯誤。一旦偏離"就是個函數"的模型，成本、性能、可觀測性全開始出問題。

電商訂單處理是典型場景：驗證商品、檢查庫存、預留庫存、處理支付、保存訂單。每個環節都可能失敗，失敗要回滾，還要快速響應。

用純Lambda寫這段邏輯？可以，但代碼里會塞滿重試邏輯、補償邏輯、狀態管理。維護起來像拆炸彈。

Step Functions的隱藏版本

Step Functions本身不新，但大多數人用的是標準版——異步、按狀態轉換計費、適合長時間運行。

Express版是另一個東西。2020年發布，同步響應，按執行次數計費，最長5分鐘。作者去年才真正大規模用上。

關鍵區別：標準版像寄掛號信，Express版像打電話。一個等回音，一個立刻回。

在Step Functions控制臺里，這套流程可以畫出來：并行執行驗證和庫存檢查，錯誤狀態用菱形框標出，補償邏輯用虛線連接。Workflow Studio支持拖拽，做完能導出到基礎設施即代碼。

作者的項目用AWS CDK管理。目錄結構很清晰：bin放入口，lib放棧定義和狀態機，functions放七個Lambda——驗證訂單、預留庫存、釋放庫存（補償用）、處理支付、保存訂單、查訂單、列商品。

預留庫存和釋放庫存是一對。Map狀態循環處理每個商品項，失敗時觸發補償，把已預留的全部釋放。這是Saga模式的樸素實現。

錢是怎么省下來的

成本結構完全不同。標準Step Functions按狀態轉換收費，復雜工作流轉一次可能幾十個狀態，費用線性增長。

Express版按執行次數收費，與狀態數量無關。并行步驟不額外計費，錯誤處理不額外計費，重試邏輯也不額外計費。

性能也有優勢。同步模式省掉輪詢開銷，端到端延遲更低。作者沒給具體數字，但強調"performant and economical"——又快又便宜。

可觀測性是意外收獲。狀態機可視化就是天然的操作手冊，哪個環節失敗、走到哪一步補償、整體執行路徑，控制臺里一目了然。不用在CloudWatch里翻Lambda日志拼故事。

什么時候該用它

不是萬能藥。超過5分鐘的長流程、需要人工審批的環節、跨天暫停的場景，還是得用標準版。

但微服務里的請求-響應式流程，特別是有明確成功/失敗定義、需要強一致性的交易類操作，Express版是更優解。

作者的樣本項目已經開源。從CDK初始化到完整可部署的訂單系統，代碼結構可以直接抄。

2020年發布時，這個功能被低估了。四年過去，云成本壓力變大，人們重新發現它。技術選型里常有這種時差——好工具需要壞環境來證明自己。