編輯導語：OMS即訂單管理中心，可以看作是電商系統的核心，其所需要具備的功能包括匯集數據、分發、跟蹤匯總等等。那么，如何依據實際業務場景、搭建一個可支撐的、穩固強大的OMS系統？本文作者針對分布式場景下的OMS系統設計做了總結，一起來看一下。

一、OMS所處位置

通常我們所談論的網上購物為狹義電商，屬于廣義電商的一種，即以電子化手段進行商品交易的一種行為。

狹義電商簡單可以描述為貨、款、以及貨與款的關系。同樣，轉化為電商系統主要核心模塊可以分為WMS倉儲系統、FMS財務系統、OMS訂單系統。

在電商的三大核心模塊中OMS訂單系統又可以看作核心中的核心，所有系統以圍繞著訂單模塊進行構建，如果整個電商系統比作人體器官，那么OMS當之無愧可以比作人的心臟，所以OMS系統設計的好壞，直接影響著其他系統的構建。

二、OMS作用

OMS系統承上啟下處在電商系統業務鏈的中游。通過各個平臺聚集到OMS的訂單，系統通過會員信息、收貨信息、優惠信息、商品、積分、支付等條件對訂單提供后續處理，如合單、拆單、第三方推送、分發倉庫、通知扣減積分，庫存、創建退款，退貨申請單等操作。同時具備從其他系統上報收集追蹤訂單變化。如出庫、物流信息，并對其他系統運營分析提供數據支撐。

可見OMS系統要具備數據快速聚集、加工、分發、跟蹤匯總的能力。

三、OMS設計

了解了OMS所處位置和作用，接下來談談如何設計一個穩健的、可持續性的OMS系統。

我們知道建設大樓，會考慮地基、主體結構、周圍環境、承載以及抗震能力等各種因素。系統搭建也一樣，對達到什么樣的預期目標也需提前做出制定，制定的要求越高，設計考慮的因素就越多。

1. 訂單相關表字段

2. 前后端數據讀寫分離

根據用戶群體的特點，前后端數據庫主從讀寫分離、應用服務分開靈活部署。主數據庫處理相關業務事務，大量的查詢轉移到從數據庫。一是減輕主數據庫的壓力，二是前后端物理隔離一方宕機可降低對另一方作業的影響。

BDMS 業務+數據（中臺）庫與OMS 訂單庫特點對比：

3. 分表歸檔

根據C端用戶特性查詢訂單以會員維度區分，所以緩解前端訪問數據壓力，分表設計是個不錯的選擇。按照訂單號1024取模方式，會員編號尾號數字1位，2位取模方式等等。

4. 業務解耦

架構從單體、三層、再到分布式微服務的變化，業務邊界也從領域驅動建模開始制定到最終分而治之，各得其所。各個分拆模塊更具獨立性和可擴展性。所以設計時其他業務模塊數據不應混到單獨某一業務模塊中，數據交換傳遞統一通過服務接口形式獲取。這也體現了分布式系統一切皆服務的思想。

業務拆分后的三大模塊主要變化時間軸：

從客戶角度分析，C端用戶界面可操作性較低，要求簡潔、直觀、易懂。如會員中心訂單tab分類：查看全部、待付款、待發貨、待收貨、待評價、退款/售后。

上圖分類由兩種或三種業務狀態的組合而成，如下圖為后端訂單和支付狀態值組合到前端狀態值以及顯示的算法。

其中，會員中心的退款/售后為逆向狀態，可與其他tab正向狀態區分開。

5. 縮短業務鏈

OMS系統主線是從建立訂單開始為倉庫提供發貨依據到配送完成，最終實現可預知的業務閉環。

其他事務如推送第三方商戶、扣減庫存、創建應收、釋放積分，庫存、退回優惠券，創建退款申請單等事務，可歸納到分支，實現可控的由訂單狀態流轉異步創建單據和事件進行處理。一是縮短業務鏈長度可使系統更具穩定和強健性，二是可根據活動、秒殺情況控制分支事務處理頻次，使資源更好的集中到業務主線上。

例如，雙十一活動期間，阿里把會員等級，芝麻信用計算等附加業務暫停服務。甚至在雙十一凌晨秒殺階段，延遲退款退花唄等逆向行為。

→正向狀態流（每種狀態分別由定時任務異步處理當前狀態下的后續業務）：

→逆向狀態（由定時任務異步處理取消訂單后續業務）：

6. 自動審單

系統根據審單配置規則對訂單金額、地址、地區、收貨人，指定會員、手機號等信息進行合法性校驗，校驗通過的則正常流轉后續流程。不符合規則的訂單，以及包含備注的訂單轉人工，通過人工再次審核。

7. 拆單

拆單主要原因涉及店鋪、品類、跨境商品、商品超重以及倉庫的不同。系統根據拆單配置規則實現對訂單拆分。

拆單一般時間節點在支付前和支付后兩種情況。拆單需要把運費、優惠、積分分攤到正價單一商品上，方便退款退貨以及財務結算。

同時需要考慮部分退情況。如果存在滿減、累計消費金額，跨店鋪消費等優惠限制時，要注意是否滿足部分退。不滿足，則需要連帶其他拆分子訂單一起退，否則駁回。

8. 合單

當買家編號、收貨人手機號、地址、姓名一致時，系統自動合并生成新訂單。需要注意的是合并訂單為虛擬訂單，并不是多個訂單的合并生成父訂單，實質只是合并發貨，降低物流成本。

9. 自動取消超時未支付訂單

實現方式如定時輪詢任務，延時消息。當數量少時使用定時任務即可滿足設計。當數量過大時可采用延時消息，訂單生成后發延時消息，到設置臨界點時判斷是否支付，未支付則取消訂單。

10. 虛擬出庫

一般針對虛擬商品，無需推送到倉庫實物發貨的訂單。如手機充值、購買游戲幣等等系統可主動變更訂單為已出庫，減少人工干預。

11. 異常訂單攔截

異常訂單攔截一般有別于自動審單校驗，可看作是對自動審單規則的補充加強。如收貨地址臨時變更、商品破損、庫存不足、部分地區管控物流限行等等。攔截可以是系統和人工攔截兩種。

12. 訂單開票

開票分為紙質和電子兩種，紙質一般由倉庫隨發貨一起開具，電子發票則由訂單發貨后，出庫狀態上報到OMS后，由OMS系統調用稅務平臺開具藍色發票。退貨逆向流程則開具紅沖發票。

13. 補償機制

如第三方消息隊列事務消息機制，TCC補償方案等等，同時需要注意接口設計時一定要做到冪等性。

14. 換貨

換貨實質是訂單商品的變化，同時也可以理解為新訂單加退貨或部分退的方式，因此也會涉及到商品單價、優惠券、積分的重新分攤。這也是為什么換貨功能設計到OMS的原因。換貨主要包含同類商品、不同類商品之間，以及數量的變化，同時還會涉及到舊商品、新商品庫存和應收、實收財務結算上的變化。

15. 其他

最后，還要與日志監控、數據分析等系統配合做好預警服務防止惡意下單，最大程度保證商家利益。OMS作為整個電商核心系統，在設計時需要充分分析具體涵蓋的業務場景，以及與其他系統的融合，這樣才能設計出符合自己企業的OMS系統。

四、總結

分布式場景下系統設計是一個不斷摸索前進的過程。只有對架構設計和業務解耦的粒度大小等合理構思，才能使后續系統更具有迭代性和可擴展性。

本文由 @莫名 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議