訂單，業務的核心模組；
一、背景簡介
訂單業務一直都是系統研發中的核心模組，訂單的產生過程，與系統中的很多模組都會高度關聯，比如賬戶體系、支付中心、運營管理等，即便單看訂單本身，也足夠的複雜；
業務在發展的過程中，必然會導致訂單量的持續增加，訂單自身、資料體量、實現流程，都需要不斷的迭代更新，如果在訂單流程的研發初期，沒有相對全面的考量，那麼很有可能導致中後期的重構；
從實踐經驗上說，圍繞訂單業務：建議過度設計，輕量級分步實現；
在產品初期先做好全面的設計，場景和流程上做好可擴充套件性的保留，在資料層面規劃好不同體量的應對方案，走在訂單業務的前面避免被動，儘量不要被業務的發展和演變甩在身後；
二、訂單業務
1、訂單體系
訂單體系從角色上看，主要涉及：使用者、商戶、平臺三個核心參與方，其訂單流程的搭建就是圍繞三方的交易場景展開；
這裡需要說明一些細節：商戶可以是第三方商家，也可以是平臺方自己，不影響概念上的劃分；商品也存在多種形式，所以用交付來描述，可以覆蓋物流的定義；
使用者：透過應用端，進行商品的選擇和下單；平臺：實現訂單交易鏈路和支付能力，以及對整個流程的排程；商戶：提供商品和交付能力；
在圖中，只是圍繞訂單體系做一個框架性的寬泛描述，在成熟的訂單業務中，其複雜程度遠超上圖，下面圍繞核心節點來細緻分析；
2、流程管理
2.1 流程拆分
訂單的業務屬性是極高的，流程本身也比較複雜，從不同的參與方來看，其流程分段策略完全不一樣，這裡僅站位研發視角，把訂單邏輯分為：建立、支付、交付三個階段；
- 訂單建立：圍繞使用者的下單路徑做管理，從商品的訪問點選並選中，到購車下單或者直接下單，從而完成訂單的建立；
- 訂單支付：各種支付渠道的對接是交易場景的基礎功能，訂單的核心狀態即支付成功；
- 訂單交付：在訂單支付完成之後，開始進行商品的交付流程，可能是商家的發貨或者服務提供，交付成功即訂單完成；
如果將整個訂單場景統籌起來看的話，還存在很多隱性的流程，與訂單銜接的上下游業務還有很多，這裡只是專注於訂單功能自身的邊界做劃分；
2.2 正向流程
在理想的狀態下，訂單從購物車結算下單開始，到交易支付完成，最終到商家完成交付，是非常複雜的流程鏈路；
在實現上，訂單的正向流程鏈路都是分段管理的，比如購物車、訂單建立之後、支付完成、交付等諸多關鍵節點，並不是一個即時的流程；
2.3 逆向流程
對於訂單這種極度複雜的流程，導致訂單流程逆向的情況，要細緻的考慮並且提供相應的解決方案，儘量確保程式可以兜底流程逆向，人工干預的成本和風險都極高；
- 取消動作：使用者主動取消訂單，發起退款流程等；商戶因為交付失敗，主動發起流程退回等動作；
- 超時情況：訂單建立後，指定時間內沒有支付；訂單支付後，指定時間內商家沒有交付等多個超時場景；
- 節點異常：系統平臺的在訂單排程時的業務異常，或者程式異常，又或者支付等第三方渠道異常等；
這些常見的異常問題，在一般的場景下可能不會引發效應問題，對於訂單這種非同步解耦的複雜場景中，需要一個穩定的機制快速執行逆向流程；比如下單後未支付導致持續鎖定庫存，或者交付超時影響使用者體驗等；
2.4 排程與監控
訂單屬於核心流程又兼具複雜的特性，自然依賴系統平臺的排程與監控手段，無論是正向還是逆向流程，都依賴排程手段提高訂單的完成率，或者促使逆向流程有序執行，在這個過程中需要對訂單路徑有完整的監控能力；
排程機制：更側重訂單被動狀態的處理，多見於各種超時的場景，用來提前對使用者和商戶進行訊息提醒觸達，或者進行訂單流程的處理；
監控策略：更側重對訂單的主動干預處理，在發現訂單中斷或者異常時，可以透過產品層面的入口進行主動修復，或者系統層面的主動重試，當然也不排除最後的手動干預；
3、結構設計
圍繞訂單場景，涉及的資料結構非常複雜，不論是商品還是支付，亦或是訂單自身的結構，在具體的業務中都會擴充出很多關聯表；
訂單結構的設計和管理，基於場景複雜度考慮，可能要融合商家、倉儲貨架、使用者、渠道和型別等；在訂單量增長之後，還需要結合業務場景，進行資料體量層面的拆分處理；
三、技術方案
1、訂單ID
訂單主體的唯一ID標識，在資料體量不大的情況下，使用表的自增ID主鍵即可，從長期看的話並不友好，如果訂單量比較大，可能涉及分庫分表的流程，則需要制定ID生成策略；
- UUID：生成唯一字串識別碼，訂單ID直接使用即可；
- 雪花演算法：分散式ID生成演算法策略，生成的ID遵循時間的順序；
- 自定義ID：除了唯一的屬性外，在訂單ID中新增其他的關鍵業務標識；
2、並行與非同步
並行操作，在訂單詳情的載入過程中，涉及到的查詢資訊非常多，比如：商品、商戶、訂單、使用者等，可以透過並行的方式，提高響應的時間，如果採用序列的方式，則介面效能會差很多；
非同步操作，訂單是個複雜的流程，顯然不可能在一次流程中完成所有邏輯，流程分段非同步常規手段，就是藉助MQ訊息的方式，同樣可以極大的提升服務效能；不論是訂單的正逆向流程，都可以基於狀態、事件、動作進行非同步解耦處理；
3、超時問題
訂單超時問題的本質在於，指定時間段之後需要執行一個動作；比如最經典的場景，下單之後超過15||30分鐘未支付，訂單自動取消並且被關閉，釋放商品的庫存，並通知使用者；
實現一個動作延遲執行的方式有很多，比如延期佇列，過期監聽，訊息延時消費等，不過這些方式在複雜的訂單系統中並不常見，主流的話還是採用定時任務排程的方式；
任務排程時，對訂單的處理，同樣要確保業務流程操作的冪等性，資料層面的一致性等問題，如果出現異常單則進行重試，分析異常原因不斷最佳化流程也同樣重要；
如果訂單體量大，任務排程能完成嗎？
訂單體量和訂單實時量不是一個概念，系統沉澱的訂單量和任務要處理的量不是一個等級，常規的資料體量做好分庫分表的設計和查詢最佳化即可，不會成為排程任務的瓶頸問題；
如果訂單資料實時體量大，比如每天超千萬的水平？
這就更不是應用的問題了，訂單體量能達到每日千萬的規模，公司會提前很長時間就把資料團隊拉到應用團隊中，解決這種核心的棘手問題，此前在資料公司搬磚時，每日單量剛過百萬，就安排資料團隊做解決方案了；
4、分散式事務
訂單涉及支付對接、庫存管理、結算對賬等各種複雜的流程，自然對資料一致性有極高的要求，如果資料層面出現問題導致異常單出現，難免需要人工介入處理，所以對流程的各階段做好細緻的事務和邏輯管理極其重要；
訂單流程是非同步解耦的方式推進的，在分散式事務的策略上追求的是最終結果一致性即可，不過這並不妨礙在分段的流程中，進行區域性的事務管理，事務成功，流程正向推進，事務失敗，流程重試或逆向回滾；
四、資料方案
1、轉化分析
經典的訂單指標體系，使用者下單過程的路徑統計，從而深度的分析轉化率問題，不斷的對流程和場景最佳化，從而提高成交量；
交易的轉化路徑分析，是產品和運營重點關注的指標體系，在資料層面，埋點採集的資料通常是上傳第三方平臺，方便進行使用者和業務分析，並且有助於同類客群的營銷推廣；
2、分庫分表
資料在到達一定體量之後，需要進行分庫分表的操作，從而解決各種效能方面的問題；將訂單資料按照特定的維度進行計算，從而將資料分流到不同的庫表中，解決讀和寫的瓶頸；
基於訂單ID計算拆分的邏輯是最常見的，在特殊情況下，也會基於使用者ID或商戶ID進行計算，從而將相關的資料堆放在一起，如果有必要，也可以考慮多維度拆分的多寫模式；
3、資料同步
訂單資料分庫分表雖然解決儲存問題，但是也帶來了很多查詢方面的阻礙，透過搜尋引擎來解決查詢問題也是常用的技術選型；
訂單資料在庫和搜尋引擎之間同步的方法有很多：同步雙寫，對資料的實時性要求極高；非同步解耦，流程存在輕微的延遲；定時任務，存在明顯的時效問題；元件同步，採用第三方資料同步元件；訂單場景的話推薦同步雙寫的方式。
五、參考原始碼
程式設計文件：
https://gitee.com/cicadasmile/butte-java-note
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent