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

一、OMS所處位置

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

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

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

二、OMS作用

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

可見OMS系統(tǒng)要具備數(shù)據(jù)快速聚集、加工、分發(fā)、跟蹤匯總的能力。

三、OMS設計

了解了OMS所處位置和作用，接下來談談如何設計一個穩(wěn)健的、可持續(xù)性的OMS系統(tǒng)。

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

1. 訂單相關(guān)表字段

2. 前后端數(shù)據(jù)讀寫分離

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

BDMS 業(yè)務+數(shù)據(jù)（中臺）庫與OMS 訂單庫特點對比：

3. 分表歸檔

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

4. 業(yè)務解耦

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

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

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

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

其中，會員中心的退款/售后為逆向狀態(tài)，可與其他tab正向狀態(tài)區(qū)分開。

5. 縮短業(yè)務鏈

OMS系統(tǒng)主線是從建立訂單開始為倉庫提供發(fā)貨依據(jù)到配送完成，最終實現(xiàn)可預知的業(yè)務閉環(huán)。

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

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

→正向狀態(tài)流（每種狀態(tài)分別由定時任務異步處理當前狀態(tài)下的后續(xù)業(yè)務）：

→逆向狀態(tài)（由定時任務異步處理取消訂單后續(xù)業(yè)務）：

6. 自動審單

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

7. 拆單

拆單主要原因涉及店鋪、品類、跨境商品、商品超重以及倉庫的不同。系統(tǒng)根據(jù)拆單配置規(guī)則實現(xiàn)對訂單拆分。

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

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

8. 合單

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

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

實現(xiàn)方式如定時輪詢?nèi)蝿眨訒r消息。當數(shù)量少時使用定時任務即可滿足設計。當數(shù)量過大時可采用延時消息，訂單生成后發(fā)延時消息，到設置臨界點時判斷是否支付，未支付則取消訂單。

10. 虛擬出庫

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

11. 異常訂單攔截

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

12. 訂單開票

開票分為紙質(zhì)和電子兩種，紙質(zhì)一般由倉庫隨發(fā)貨一起開具，電子發(fā)票則由訂單發(fā)貨后，出庫狀態(tài)上報到OMS后，由OMS系統(tǒng)調(diào)用稅務平臺開具藍色發(fā)票。退貨逆向流程則開具紅沖發(fā)票。

13. 補償機制

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

14. 換貨

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

15. 其他

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

四、總結(jié)

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