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

02-01

完整的一套訂單系統流程如何確保支付結果的完整性和及時的通知用戶，非同步消息隊列+計劃任務，還是加鎖處理，如寫計劃任務，時間應該設置為多久

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

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

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

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

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

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

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

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

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

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

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

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

首先要梳理訂單系統的整體流程，多從用戶角度去思考、設計功能；多考慮可能會出現的異常問題、逆向規則處理方式，並提前準備好後門策略。

在系統設計過程中，注意劃清各個功能的職責，不要混淆、亂放，這樣便於以後的梳理、監控。設計時要從框架角度設計，盡量不修改而是擴展。

要保證系統的安全性，對於防重問題，可以先選擇redis進行判斷。由於是內存操作，所以會相當快，也防止了db的壓力。而後db中添加uuid欄位以及唯一索引，進行二道防重。

保證數據的完成性，每個操作要保留流水記錄，用於後期對賬使用。

由於前後分離以及微服務調用，只能保證數據最終一致性，可以引入回調進行驗證，或者使用失敗重試，這都需要方法冪等。

同步+非同步，實時數據要立即展示，相關後續操作使用非同步操作，一方面解耦，一方面緩解系統壓力。

本文作者：京東金融-技術研發部孫浩

現在有這麼多成熟的erp系統可以參考嘛

先完整的體驗別人的系統，看別人的訂單系統，是如何實現的，比如淘寶

在看人家的介面是如何確保準確及時送達的

都了解了自然就懂了

訂單的核心就是個狀態機，設計的前提是你要懂業務，沒人帶怎麼懂，看前兩條

有一個在線工具，只要你有業務邏輯就能變成訂單系統，叫百寶雲，你去找一下。