🏗️ 從巨石到微服務雛形：基於事件驅動架構 (EDA) 的高可用 WMS/OMS 原型實戰

🏗️ 從巨石到微服務雛形：基於事件驅動架構 (EDA) 的高可用 WMS/OMS 原型實戰

前言：破解台灣電商物流的規模化瓶頸

在台灣電子商務市場不斷刷新紀錄的背景下，傳統倉儲管理系統 (WMS) 與訂單管理系統 (OMS) 已成為限制企業規模擴張的關鍵瓶頸。常見的痛點不僅限於硬體層面，更在於系統架構的韌性與效率：

• 人力資源優化瓶頸： 傳統逐單揀貨模式導致揀貨員走動距離過長，效率低下，難以應對日益高漲的人力成本。

• 高併發處理能力匱乏： 面對「雙 11」、「週年慶」等流量尖峰，同步處理的系統極易崩潰或響應遲緩。

• 狀態與流程黑箱： 訂單狀態缺乏即時、透明的追蹤機制，增加了客服與供應鏈追蹤的複雜度。

• 作業錯誤率高企： 分揀與包裝環節的人為錯誤，直接導致退貨成本與客戶滿意度下降。

為此，本專案團隊設計並實作了一個採用 事件驅動架構 (Event-Driven Architecture, EDA) 的 WMS/OMS 系統原型 (V5)，展示如何運用現代軟體工程方法，提供一個高效率、高可擴展性的解決方案。

您可以透過以下 GitHub 連結檢閱本專案的原始碼：https://github.com/BpsEason/wms-oms-demo.git

系統架構與技術棧選型

本專案採用成熟且高效率的技術組合，搭建前後端分離 (Separation of Concerns) 的架構，並透過 Docker Compose 實現快速部署與環境一致性。

核心技術棧

分層	技術/框架	版本	核心考量
後端	Laravel	10 (PHP 8.2)	框架成熟穩定，內建 Event/Listener、Queue 等高階組件，加速原型開發。
前端	Vue 3	Composition API/TS	透過 Composition API 強化邏輯複用與類型安全。
持久層	PostgreSQL	15	提供穩定的 ACID 特性，適合複雜的交易型資料。
消息/緩存	Redis	7	作為 Laravel Queue Driver 及 Cache Store，提供極低延遲的非同步處理能力。
容器化	Docker Compose	N/A	標準化開發、測試與部署環境。
佇列監控	Laravel Horizon	N/A	提供 Redis 佇列的可視化監控，便於追蹤任務效能與故障排除。

整體部署架構

Frontend (Vue3)  <-->  API Gateway (Nginx)  <-->  Backend (Laravel, PHP-FPM)
                                         |--> PostgreSQL (Data Persistence)
                                         |--> Redis (Queue & High-Speed Cache)

---

🚀 系統亮點：事件驅動與演算法優化

本原型的核心價值在於其對高併發處理的支援，以及對傳統作業流程的智慧化優化。

1. 核心驅動：強健的事件驅動架構 (EDA)

EDA 是實現模組解耦與流程透明化的關鍵。所有核心業務流程的轉換，皆由事件 (Event) 觸發監聽器 (Listener) 實現，確保狀態流轉的單向性與可追溯性。

• OrderCreated 事件： 自動觸發 InventoryChecker（庫存檢查）與 PickingTaskGenerator（揀貨任務生成）。

• PickingCompleted 事件： 觸發 SortingTaskGenerator（分揀任務生成）。

• PackingCompleted 事件： 觸發 ShipmentProcessor（出貨流程，模擬呼叫物流 API）。

價值： 提升系統的韌性 (Resilience) 與可擴展性 (Scalability)。未來可輕鬆掛載新的業務邏輯，例如異常處理、退貨流程或數據分析 Hook，而不必修改核心訂單流程。

2. 高併發處理基石：非同步佇列 (Queue)

透過 Redis Queue 結合 Laravel Horizon，將所有耗時操作 (如複雜計算、IO 延遲、外部服務呼叫) 異步化。

• 處理任務： 揀貨任務模擬延遲、物流 API 呼叫、包裝單 PDF 生成 (DomPDF)。

• 優勢： 主應用服務 (Web Process) 僅負責接收請求並將任務推送至佇列，快速釋放資源，有效抵抗雙 11 等高併發流量衝擊。Horizon 提供即時的任務吞吐量、延遲及失敗率監控，便於 SRE (Site Reliability Engineering) 維護。

3. WMS 效率殺手鐧：分批揀貨演算法 (Batch Picking Algorithm)

針對「揀貨員走動距離過長」這一經典倉儲痛點，系統實作了分批揀貨 (Batch Picking) 策略。

• 邏輯： 將多張待處理訂單中相同的 SKU 進行合併，並根據商品儲位 (Location) 進行路徑排序。

• 限制與拆分： 考量單次作業負荷，設定每批次最大商品數量限制（e.g., 50 件），超限則自動拆分為多個批次任務，分配給不同的揀貨員，實現並行化作業。

• 潛力： 目前採用易於實作的貪婪演算法 (Greedy Algorithm)，未來可升級為更優的旅行推銷員問題 (TSP) 演算法或 A* 搜尋，預計可進一步減少 50% 至 90% 的總行走距離。

4. 錯誤防範：分揀策略與驗證

模擬現代倉庫的 Pick-to-Light 站台邏輯，確保商品準確地被分配到對應的訂單箱號 (Sorting Bin)。

• 關鍵機制： 導入 JSON 格式的驗證機制，於分揀 (Sorting) 流程中即時檢查商品數量與目標訂單的一致性。

• 分揀波次 (Wave Sorting)： 支援優先處理具時效性的急單 (Rush Order)，並可規劃波次，確保資源利用率最大化。

5. 外部服務整合：出貨流程自動化

模擬與第三方物流服務商 (e.g., Shippo/FedEx) 的 API 介接，實現出貨流程的自動化。

• 功能： 呼叫外部 API，生成唯一追蹤號碼，並將狀態回寫至 OMS。

• 穩定性： 具備基本的錯誤處理與重試機制 (Retry Mechanism)，保證服務的最終一致性 (Eventually Consistency)。

---

🎯 痛點解決方案對照表

台灣倉儲痛點	系統核心功能	技術/演算法解決方案	效益評估
揀貨員人力效率低落	分批揀貨演算法	貪婪搜尋 + 儲位優化排序	減少 50% 以上倉庫行走距離。
高峰期訂單暴增	非同步佇列處理	Redis Queue + Laravel Horizon	支援高併發，保證核心服務穩定性。
流程/狀態不透明	事件驅動架構	Events/Listeners + 狀態機設計	訂單狀態自動流轉，流程清晰可追溯。
分揀錯誤率高	分揀策略優化	JSON 驗證 + 模擬 Pick-to-Light	降低人為錯誤，提升準確率。
出貨整合不足	物流 API 整合	GuzzleHttp 模擬 API 呼叫/追蹤號生成	簡化出貨作業，提升客戶體驗。

結語：從 POC 到生產級的演進潛力與 AI 賦能

本專案原型展示了如何結合 EDA 思想、演算法優化與高可用非同步佇列，來解決倉儲物流的效率問題。

此原型具備極高的擴展性，可作為中小型電商快速搭建 WMS/OMS 的基礎。值得一提的是，在架構設計、程式碼審查與複雜演算法的初步實作過程中，AI 輔助工具（如程式碼生成與重構建議）也提供了有效的支持，極大地縮短了原型驗證 (POC) 的週期。

未來的進階需求（如：退貨流程、冷鏈管理、多物流商路由選擇、AI 驅動的人力排班與需求預測）皆已在架構上預留了清晰的擴展接口。