• 一、背景簡介
• 二、訂單業務
  • 1、訂單體系
  • 2、流程管理
    • 2.1 流程拆分
    • 2.2 正向流程
    • 2.3 逆向流程
    • 2.4 調度與監控
  • 3、結構設計
• 三、技術方案
  • 1、訂單ID
  • 2、并行與異步
  • 3、超時問題
  • 4、分布式事務
• 四、資料方案
  • 1、轉化分析
  • 2、分庫分表
  • 3、資料同步
• 五、參考原始碼

訂單，業務的核心模塊；

一、背景簡介

訂單業務一直都是系統研發中的核心模塊，訂單的產生程序，與系統中的很多模塊都會高度關聯，比如賬戶體系、支付中心、運營管理等，即便單看訂單本身，也足夠的復雜；

業務在發展的程序中，必然會導致訂單量的持續增加，訂單自身、資料體量、實作流程，都需要不斷的迭代更新，如果在訂單流程的研發初期，沒有相對全面的考量，那么很有可能導致中后期的重構；

從實踐經驗上說，圍繞訂單業務：建議過度設計，輕量級分步實作；

在產品初期先做好全面的設計，場景和流程上做好可擴展性的保留，在資料層面規劃好不同體量的應對方案，走在訂單業務的前面避免被動，盡量不要被業務的發展和演變甩在身后；

二、訂單業務

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

標籤：Java

上一篇：Java 缺失的特性：運算子多載

下一篇：Java 列舉實作單例模式，執行緒安全又優雅！