如何設計一套完整的訂單系統，或者完整的業務流程？

1樓：請幫忙關燈

利益相關，5年電商產品狗一條。新一年立了個flag——每週至少分鐘在知乎回覆一條題。那就從今天開始哦——

1.訂單系統的核心在於狀態機，可根據業務訂製狀態，靈活適配的狀態流程，從支付成功開始到履約結束，始態和終態是確定性的，可根據業務來配置好適用的狀態；

2.訂單資料一致性，訂單系統次重要的點在於資料一致性，任何狀態變更引發對其單據的變化，其訂單的金額，訂單中的商品，訂單包含的優惠資訊，訂單包含的會員資訊等等產生的變化都要可追溯，通知到位，通過技術非同步或訊息發出通知到所有關心這個訂單資料的系統。作為乙個承上啟下的系統，能保證資訊一致性，就相當難。

3.技術方法

重試補償，冪等處理，非同步訊息，可追溯一切歷史資料。

2樓：梁川

說一下一些關鍵設計點供參考。

以下設計點，可以歸為 "冪等設計"、"CQRS/Event Sourcing"、補償機制等一些設計原則的體現。

1、請求/響應方都要維護自己平台的請求號/響應號，並保證請求號/響應號的唯一性。

設計上不能假定對方能夠保證唯一性，應當保證請求方的序號+響應方的序號是唯一的。

2、原始請求/響應報文的所有內容都要本地持久化儲存，便於請求/響應的過程回溯，有助於審計、排查、定位問題。

3、對訂單狀態定義要遵循MECE(Mutually Exclusive Collectively Exhaustive)原則，同時對狀態機的遷移要做完整記錄

4、訊息同步返回+非同步通知+主動查詢結合的補償機制

由於網際網路通訊的不可靠性，例如雙方網路、伺服器、應用等因素的影響，不管是同步返回、非同步通知、主動查詢報文都可能出現超時無響應、報文丟失等情況，所以像支付業務，對結果的通知一般採用幾種方案結合的補償機制，不能完全依賴某一種機制。

例如乙個支付結果的通知，一方面會在支付頁面跳轉時候返回支付結果（一般只用作前端展示使用，非最終狀態），同時會採用後台非同步通知機制（有前台、後台通知的，以後臺非同步通知結果為準），但由於前台跳轉、後台結果通知都可能失效，因此還以定時補單+請求方主動查詢介面作為輔助手段。

常見的補單操作，任務排程策略一般設定30秒、60秒、3分鐘、6分鐘、10分鐘排程多次（以自己業務需要），如果排程接收到響應確認報文，補單成功，則中止對應訂單的排程任務；如果超過補單上限次數，則停止補單，避免無謂的資源浪費。請求端隨時可以發起請求報文查詢對應訂單的狀態。

5、對重複報文的判重機制，這對諸如支付、代付等場景至關重要，避免出現重複支付、重複付款。

6、採用不同的事務處理機制（按照支付寶的說法叫柔性事務）來滿足不同的業務場景需求。例如對支付賬戶餘額更新，採用標準的ACID事務（兩階段、三階段）；對虛擬賬戶賬戶的會計分錄採用補償型事務（非同步確保型）；對支付結果通知，採用補償型事務機制（最大努力通知）；