訂單，業(yè)務(wù)的核心模塊；

一、背景簡介

訂單業(yè)務(wù)一直都是系統(tǒng)研發(fā)中的核心模塊，訂單的產(chǎn)生過程，與系統(tǒng)中的很多模塊都會(huì)高度關(guān)聯(lián)，比如賬戶體系、支付中心、運(yùn)營管理等，即便單看訂單本身，也足夠的復(fù)雜；

業(yè)務(wù)在發(fā)展的過程中，必然會(huì)導(dǎo)致訂單量的持續(xù)增加，訂單自身、數(shù)據(jù)體量、實(shí)現(xiàn)流程，都需要不斷的迭代更新，如果在訂單流程的研發(fā)初期，沒有相對(duì)全面的考量，那么很有可能導(dǎo)致中后期的重構(gòu)；

從實(shí)踐經(jīng)驗(yàn)上說，圍繞訂單業(yè)務(wù)：建議過度設(shè)計(jì)，輕量級(jí)分步實(shí)現(xiàn)；

在產(chǎn)品初期先做好全面的設(shè)計(jì)，場景和流程上做好可擴(kuò)展性的保留，在數(shù)據(jù)層面規(guī)劃好不同體量的應(yīng)對(duì)方案，走在訂單業(yè)務(wù)的前面避免被動(dòng)，盡量不要被業(yè)務(wù)的發(fā)展和演變甩在身后；

二、訂單業(yè)務(wù)

1、訂單體系

訂單體系從角色上看，主要涉及：用戶、商戶、平臺(tái)三個(gè)核心參與方，其訂單流程的搭建就是圍繞三方的交易場景展開；

這里需要說明一些細(xì)節(jié)：商戶可以是第三方商家，也可以是平臺(tái)方自己，不影響概念上的劃分；商品也存在多種形式，所以用交付來描述，可以覆蓋物流的定義；

用戶：通過應(yīng)用端，進(jìn)行商品的選擇和下單；平臺(tái)：實(shí)現(xiàn)訂單交易鏈路和支付能力，以及對(duì)整個(gè)流程的調(diào)度；商戶：提供商品和交付能力；

在圖中，只是圍繞訂單體系做一個(gè)框架性的寬泛描述，在成熟的訂單業(yè)務(wù)中，其復(fù)雜程度遠(yuǎn)超上圖，下面圍繞核心節(jié)點(diǎn)來細(xì)致分析；

2、流程管理

2.1 流程拆分

訂單的業(yè)務(wù)屬性是極高的，流程本身也比較復(fù)雜，從不同的參與方來看，其流程分段策略完全不一樣，這里僅站位研發(fā)視角，把訂單邏輯分為：創(chuàng)建、支付、交付三個(gè)階段；

• 訂單創(chuàng)建：圍繞用戶的下單路徑做管理，從商品的訪問點(diǎn)擊并選中，到購車下單或者直接下單，從而完成訂單的創(chuàng)建；

• 訂單支付：各種支付渠道的對(duì)接是交易場景的基礎(chǔ)功能，訂單的核心狀態(tài)即支付成功；

• 訂單交付：在訂單支付完成之后，開始進(jìn)行商品的交付流程，可能是商家的發(fā)貨或者服務(wù)提供，交付成功即訂單完成；

如果將整個(gè)訂單場景統(tǒng)籌起來看的話，還存在很多隱性的流程，與訂單銜接的上下游業(yè)務(wù)還有很多，這里只是專注于訂單功能自身的邊界做劃分；

2.2 正向流程

在理想的狀態(tài)下，訂單從購物車結(jié)算下單開始，到交易支付完成，最終到商家完成交付，是非常復(fù)雜的流程鏈路；

在實(shí)現(xiàn)上，訂單的正向流程鏈路都是分段管理的，比如購物車、訂單創(chuàng)建之后、支付完成、交付等諸多關(guān)鍵節(jié)點(diǎn)，并不是一個(gè)即時(shí)的流程；

2.3 逆向流程

對(duì)于訂單這種極度復(fù)雜的流程，導(dǎo)致訂單流程逆向的情況，要細(xì)致的考慮并且提供相應(yīng)的解決方案，盡量確保程序可以兜底流程逆向，人工干預(yù)的成本和風(fēng)險(xiǎn)都極高；

• 取消動(dòng)作：用戶主動(dòng)取消訂單，發(fā)起退款流程等；商戶因?yàn)榻桓妒。鲃?dòng)發(fā)起流程退回等動(dòng)作；

• 超時(shí)情況：訂單創(chuàng)建后，指定時(shí)間內(nèi)沒有支付；訂單支付后，指定時(shí)間內(nèi)商家沒有交付等多個(gè)超時(shí)場景；

• 節(jié)點(diǎn)異常：系統(tǒng)平臺(tái)的在訂單調(diào)度時(shí)的業(yè)務(wù)異常，或者程序異常，又或者支付等第三方渠道異常等；

這些常見的異常問題，在一般的場景下可能不會(huì)引發(fā)效應(yīng)問題，對(duì)于訂單這種異步解耦的復(fù)雜場景中，需要一個(gè)穩(wěn)定的機(jī)制快速執(zhí)行逆向流程；比如下單后未支付導(dǎo)致持續(xù)鎖定庫存，或者交付超時(shí)影響用戶體驗(yàn)等；

2.4 調(diào)度與監(jiān)控

訂單屬于核心流程又兼具復(fù)雜的特性，自然依賴系統(tǒng)平臺(tái)的調(diào)度與監(jiān)控手段，無論是正向還是逆向流程，都依賴調(diào)度手段提高訂單的完成率，或者促使逆向流程有序執(zhí)行，在這個(gè)過程中需要對(duì)訂單路徑有完整的監(jiān)控能力；

調(diào)度機(jī)制：更側(cè)重訂單被動(dòng)狀態(tài)的處理，多見于各種超時(shí)的場景，用來提前對(duì)用戶和商戶進(jìn)行消息提醒觸達(dá)，或者進(jìn)行訂單流程的處理；

監(jiān)控策略：更側(cè)重對(duì)訂單的主動(dòng)干預(yù)處理，在發(fā)現(xiàn)訂單中斷或者異常時(shí)，可以通過產(chǎn)品層面的入口進(jìn)行主動(dòng)修復(fù)，或者系統(tǒng)層面的主動(dòng)重試，當(dāng)然也不排除最后的手動(dòng)干預(yù)；

3、結(jié)構(gòu)設(shè)計(jì)

圍繞訂單場景，涉及的數(shù)據(jù)結(jié)構(gòu)非常復(fù)雜，不論是商品還是支付，亦或是訂單自身的結(jié)構(gòu)，在具體的業(yè)務(wù)中都會(huì)拓展出很多關(guān)聯(lián)表；

訂單結(jié)構(gòu)的設(shè)計(jì)和管理，基于場景復(fù)雜度考慮，可能要融合商家、倉儲(chǔ)貨架、用戶、渠道和類型等；在訂單量增長之后，還需要結(jié)合業(yè)務(wù)場景，進(jìn)行數(shù)據(jù)體量層面的拆分處理；

三、技術(shù)方案

1、訂單ID

訂單主體的唯一ID標(biāo)識(shí)，在數(shù)據(jù)體量不大的情況下，使用表的自增ID主鍵即可，從長期看的話并不友好，如果訂單量比較大，可能涉及分庫分表的流程，則需要制定ID生成策略；

• UUID：生成唯一字符串識(shí)別碼，訂單ID直接使用即可；

• 雪花算法：分布式ID生成算法策略，生成的ID遵循時(shí)間的順序；

• 自定義ID：除了唯一的屬性外，在訂單ID中添加其他的關(guān)鍵業(yè)務(wù)標(biāo)識(shí)；

2、并行與異步

并行操作，在訂單詳情的加載過程中，涉及到的查詢信息非常多，比如：商品、商戶、訂單、用戶等，可以通過并行的方式，提高響應(yīng)的時(shí)間，如果采用串行的方式，則接口性能會(huì)差很多；

異步操作，訂單是個(gè)復(fù)雜的流程，顯然不可能在一次流程中完成所有邏輯，流程分段異步常規(guī)手段，就是借助MQ消息的方式，同樣可以極大的提升服務(wù)性能；不論是訂單的正逆向流程，都可以基于狀態(tài)、事件、動(dòng)作進(jìn)行異步解耦處理；

3、超時(shí)問題

訂單超時(shí)問題的本質(zhì)在于，指定時(shí)間段之后需要執(zhí)行一個(gè)動(dòng)作；比如最經(jīng)典的場景，下單之后超過15||30分鐘未支付，訂單自動(dòng)取消并且被關(guān)閉，釋放商品的庫存，并通知用戶；

實(shí)現(xiàn)一個(gè)動(dòng)作延遲執(zhí)行的方式有很多，比如延期隊(duì)列，過期監(jiān)聽，消息延時(shí)消費(fèi)等，不過這些方式在復(fù)雜的訂單系統(tǒng)中并不常見，主流的話還是采用定時(shí)任務(wù)調(diào)度的方式；

任務(wù)調(diào)度時(shí)，對(duì)訂單的處理，同樣要確保業(yè)務(wù)流程操作的冪等性，數(shù)據(jù)層面的一致性等問題，如果出現(xiàn)異常單則進(jìn)行重試，分析異常原因不斷優(yōu)化流程也同樣重要；

如果訂單體量大，任務(wù)調(diào)度能完成嗎？

訂單體量和訂單實(shí)時(shí)量不是一個(gè)概念，系統(tǒng)沉淀的訂單量和任務(wù)要處理的量不是一個(gè)等級(jí)，常規(guī)的數(shù)據(jù)體量做好分庫分表的設(shè)計(jì)和查詢優(yōu)化即可，不會(huì)成為調(diào)度任務(wù)的瓶頸問題；

如果訂單數(shù)據(jù)實(shí)時(shí)體量大，比如每天超千萬的水平？

這就更不是應(yīng)用的問題了，訂單體量能達(dá)到每日千萬的規(guī)模，公司會(huì)提前很長時(shí)間就把數(shù)據(jù)團(tuán)隊(duì)拉到應(yīng)用團(tuán)隊(duì)中，解決這種核心的棘手問題，此前在數(shù)據(jù)公司搬磚時(shí)，每日單量剛過百萬，就安排數(shù)據(jù)團(tuán)隊(duì)做解決方案了；

4、分布式事務(wù)

訂單涉及支付對(duì)接、庫存管理、結(jié)算對(duì)賬等各種復(fù)雜的流程，自然對(duì)數(shù)據(jù)一致性有極高的要求，如果數(shù)據(jù)層面出現(xiàn)問題導(dǎo)致異常單出現(xiàn)，難免需要人工介入處理，所以對(duì)流程的各階段做好細(xì)致的事務(wù)和邏輯管理極其重要；

訂單流程是異步解耦的方式推進(jìn)的，在分布式事務(wù)的策略上追求的是最終結(jié)果一致性即可，不過這并不妨礙在分段的流程中，進(jìn)行局部的事務(wù)管理，事務(wù)成功，流程正向推進(jìn)，事務(wù)失敗，流程重試或逆向回滾；

四、數(shù)據(jù)方案

1、轉(zhuǎn)化分析

經(jīng)典的訂單指標(biāo)體系，用戶下單過程的路徑統(tǒng)計(jì)，從而深度的分析轉(zhuǎn)化率問題，不斷的對(duì)流程和場景優(yōu)化，從而提高成交量；

交易的轉(zhuǎn)化路徑分析，是產(chǎn)品和運(yùn)營重點(diǎn)關(guān)注的指標(biāo)體系，在數(shù)據(jù)層面，埋點(diǎn)采集的數(shù)據(jù)通常是上傳第三方平臺(tái)，方便進(jìn)行用戶和業(yè)務(wù)分析，并且有助于同類客群的營銷推廣；

2、分庫分表

數(shù)據(jù)在到達(dá)一定體量之后，需要進(jìn)行分庫分表的操作，從而解決各種性能方面的問題；將訂單數(shù)據(jù)按照特定的維度進(jìn)行計(jì)算，從而將數(shù)據(jù)分流到不同的庫表中，解決讀和寫的瓶頸；

基于訂單ID計(jì)算拆分的邏輯是最常見的，在特殊情況下，也會(huì)基于用戶ID或商戶ID進(jìn)行計(jì)算，從而將相關(guān)的數(shù)據(jù)堆放在一起，如果有必要，也可以考慮多維度拆分的多寫模式；

3、數(shù)據(jù)同步

訂單數(shù)據(jù)分庫分表雖然解決存儲(chǔ)問題，但是也帶來了很多查詢方面的阻礙，通過搜索引擎來解決查詢問題也是常用的技術(shù)選型；

訂單數(shù)據(jù)在庫和搜索引擎之間同步的方法有很多：同步雙寫，對(duì)數(shù)據(jù)的實(shí)時(shí)性要求極高；異步解耦，流程存在輕微的延遲；定時(shí)任務(wù)，存在明顯的時(shí)效問題；組件同步，采用第三方數(shù)據(jù)同步組件；訂單場景的話推薦同步雙寫的方式。