百度訂單系統(tǒng)架構(gòu)淺析
導(dǎo)讀：百度交易中臺作為集團(tuán)移動生態(tài)戰(zhàn)略的基礎(chǔ)設(shè)施，面向收銀交易與清分結(jié)算場景，為賦能業(yè)務(wù)提供高效交易生態(tài)搭建。目前支持百度體系內(nèi)多個(gè)產(chǎn)品線，主要包含：小程序，地圖打車，百家號，招財(cái)貓，好看視頻等。本文主要從業(yè)務(wù)模型與架構(gòu)設(shè)計(jì)兩個(gè)方面介紹訂單系統(tǒng)的構(gòu)建過程。
本期公布第四期「周一見」活動中獎名單，詳情見文末~
一、訂單系統(tǒng)應(yīng)具備怎樣的能力？
訂單打通用戶、商家、商品、庫存、售后等關(guān)鍵業(yè)務(wù)，是驅(qū)動交易全流程運(yùn)轉(zhuǎn)的核心。而訂單系統(tǒng)承上啟下，作為入口，涵蓋了訂單流程管理、庫存與營銷管理、算價(jià)引擎、履約子流程、售后以及退款信息管理等。
訂單系統(tǒng)具備的能力可以按照下面三個(gè)角度進(jìn)行切入拆解：
用戶視角：支付算價(jià)、用戶下單、物流跟蹤、退款、訂單檢索等；
商家視角：訂單狀態(tài)管理、商家拆單、售后客訴管理等；
平臺視角：拆單、CPS分傭、風(fēng)控、反作弊等。
二、交易中臺如何提供服務(wù)？
交易中臺基于現(xiàn)有的業(yè)務(wù)進(jìn)行了抽象和歸類，從接入主要分成如下三個(gè)類型：
通用型：業(yè)務(wù)自己維護(hù)商品，庫存信息等信息，只需調(diào)用訂單系統(tǒng)進(jìn)行聚合支付。訂單系統(tǒng)會根據(jù)業(yè)務(wù)訴求提供營銷、退款、免密、推廣、分賬、一清、對賬、風(fēng)控等功能支持，主要業(yè)務(wù)有：百度地圖、百度醫(yī)療、小度商城、度小店等。
自營型：訂單系統(tǒng)提供完整的電商能力支持，包含商品、庫存、營銷、退款、售后、檢索、物流跟蹤等功能支持，主要業(yè)務(wù)有：招財(cái)貓、夸夸豆等。
直連型：業(yè)務(wù)自己調(diào)用渠道進(jìn)行支付，支付完成之后將訂單信息到同步到訂單系統(tǒng),訂單系統(tǒng)通過計(jì)算推廣信息進(jìn)行流量主（包含：主播、推廣作者、平臺等）分傭，主要業(yè)務(wù)有：當(dāng)當(dāng)、亞馬遜。
上圖中介紹了通用業(yè)務(wù)和自營業(yè)務(wù)關(guān)鍵環(huán)節(jié)中的對比。可以看到：
通用業(yè)務(wù)主要側(cè)重于支付的環(huán)節(jié)，包含的步驟是支付、支付通知、交易狀態(tài)、退款等；
自營業(yè)務(wù)則在支付的基礎(chǔ)上，擴(kuò)展增加了商品管理，包括收發(fā)貨、訂單的超時(shí)取消等；
直連業(yè)務(wù)是針對某些業(yè)務(wù)定制的，主要的區(qū)別在于資金流的處理環(huán)節(jié)，在此不進(jìn)行贅述。
三、訂單的生命周期以及流程
在常見的電商環(huán)節(jié)中，訂單從產(chǎn)生之后，主要包括訂單確認(rèn)、支付、發(fā)貨、成功、取消、退款等，這些狀態(tài)構(gòu)成了一個(gè)有限狀態(tài)機(jī)。
這些狀態(tài)主要通過兩個(gè)動作進(jìn)行串聯(lián)，即：訂單的正向流程及逆向流程，正向流程是指用戶購買產(chǎn)品或者服務(wù)的支付行為管理。逆向流程則是指用戶發(fā)起售后造成的退款、退貨行為管理。
3.1 正向支付流程
正向支付流程，由用戶發(fā)起，代表用戶向商家發(fā)起一筆交易，交易的流程入下圖所示：
入口：從上圖可以看的比較明確，訂單可以從多個(gè)入口產(chǎn)生，包括常見的移動設(shè)備、網(wǎng)站、掃碼等；
訂單生成：隨著用戶確定訂單，訂單系統(tǒng)需要協(xié)調(diào)商品、營銷、庫存、風(fēng)控等多個(gè)下游系統(tǒng)進(jìn)行確認(rèn)；
支付通道選擇：生成訂單之后，用戶會跳轉(zhuǎn)到支付界面，此時(shí)，訂單系統(tǒng)會提供常見的支付通道供用戶選擇進(jìn)行處理，常見的支付通道微信、支付寶、度小滿支付等都由訂單系統(tǒng)進(jìn)行集成；
支付成功：用戶支付成功之后，訂單系統(tǒng)會通知上下游系統(tǒng)狀態(tài)變更，同時(shí)對庫存、營銷進(jìn)行扣減
商家發(fā)貨、確認(rèn)收貨：訂單支付完成之后，就會進(jìn)入商家處理流程，對于實(shí)體商品的購買場景，中臺訂單會進(jìn)入物流環(huán)節(jié)。對于沒有實(shí)體的商品，中臺會提供沒有發(fā)貨流程的交易模板。
交易成功：交易成功是訂單的其中一個(gè)終態(tài)，代表用戶和商家最終完成交易。
3.2 逆向退款流程
在實(shí)際的業(yè)務(wù)場景中，逆向退款主要是指商家進(jìn)行退款的流程。通常可以在電商場景中的7天無理由退款、退貨、用戶售后流程中見到。
中臺經(jīng)過抽象業(yè)務(wù)流程之后，梳理了一套退款退貨流程，如上圖所示，退款退貨發(fā)起之后，會進(jìn)入商家審核的環(huán)節(jié)，商家確認(rèn)通過之后，會進(jìn)行用戶處理。如果有物流環(huán)節(jié)的話，這時(shí)候會處理商家退貨發(fā)貨等。
業(yè)務(wù)流程就介紹到這里，接下來主要做系統(tǒng)架構(gòu)方面的介紹。
四、架構(gòu)淺談
技術(shù)本身的目標(biāo)是為業(yè)務(wù)服務(wù)，貼合業(yè)務(wù)的技術(shù)架構(gòu)本身是最經(jīng)濟(jì)的選擇。訂單系統(tǒng)也是一樣，架構(gòu)隨著業(yè)務(wù)的發(fā)展進(jìn)新了逐步的優(yōu)化和擴(kuò)展。
在業(yè)務(wù)初期，架構(gòu)如下圖所示：
業(yè)務(wù)初期規(guī)模較小，功能也比較單一，只需要具備簡單的支付、退款能力。所有功能都集中在一個(gè)系統(tǒng)，這樣做的好處是簡單快捷，容易部署，測試、開發(fā)效率高，是適合業(yè)務(wù)初期發(fā)展的架構(gòu)。訂單系統(tǒng)初期也為百度內(nèi)部的火車票、小度商城、小程序的業(yè)務(wù)提供訂單管理的能力。
隨著業(yè)務(wù)不斷擴(kuò)張，虛擬商品的購買，退款已經(jīng)不能滿足業(yè)務(wù)，需要擴(kuò)展支持帶有物流商品訂單，并且在支付方式部分，需要擴(kuò)展支持各類購買入口和場景，比如聚合掃碼支付、小額免密支付、周期代扣。隨著業(yè)務(wù)擴(kuò)展，后續(xù)又引入了諸如直播帶貨、拍賣、閃電購、訂單評價(jià)、紅包搶購，資產(chǎn)充值等更加豐富的場景。并且在功能擴(kuò)展之外，整體交易中臺還必須引入符合央行的監(jiān)管規(guī)范改造，為了訂單安全對接反作弊入口等諸多非功能方面的擴(kuò)展。
為了支持業(yè)務(wù)的多方向擴(kuò)展，原來的單體架構(gòu)在功能需求方面會遇到了擴(kuò)展難的問題，同時(shí)在性能方面，也逐漸無法滿足吞吐量，響應(yīng)時(shí)間以及擴(kuò)展性等要求。
對于性能方面的擴(kuò)展，需要將系統(tǒng)從單體改造為分布式的架構(gòu)，這一部分的改造方案較為成熟，采用集團(tuán)內(nèi)的分布式數(shù)據(jù)庫、緩存、以及商業(yè)平臺近年來提供的云原生部署架構(gòu)可以較為快速的進(jìn)行提升。唯一的難點(diǎn)就在于訂單分布式數(shù)據(jù)庫的改造，由于業(yè)務(wù)初期已經(jīng)充分考慮了訂單的擴(kuò)展進(jìn)行持久層結(jié)構(gòu)設(shè)計(jì)，這部分?jǐn)U展也不難。
對于業(yè)務(wù)方面的擴(kuò)展則是重頭戲，訂單系統(tǒng)構(gòu)建了一套指令編排架構(gòu)，通過不同指令調(diào)用不同的系統(tǒng)，然后抽象出模板，然后通過不同模板指令支撐不同業(yè)務(wù)場景。并且通過緩存，異步，降級等方式來提升性能。
分布式技術(shù)改造方案非常成熟，不在此進(jìn)行贅述。接下來主要介紹一下基于指令進(jìn)行設(shè)計(jì)方案，以及基于該方案專門設(shè)計(jì)的性能升級改造。
4.1 指令編排架構(gòu)
不同的產(chǎn)品形態(tài)、交易類型產(chǎn)生的流程各式各樣，為了滿足這種不同場景中的業(yè)務(wù)需求，訂單系統(tǒng)通過抽象了指令編排的設(shè)計(jì)，來實(shí)現(xiàn)業(yè)務(wù)流程的管理，從而使系統(tǒng)更具擴(kuò)展性。
指令可以簡單理解為相對獨(dú)立的操作單元，比如常見的功能點(diǎn)都可以拆分為指令集，比如支付指令、用戶指令等。優(yōu)點(diǎn)在于代碼的改動較小，遵循開閉原則。編排的方式類似于模板方法，不同的指令類似搭積木一樣的進(jìn)行疊加，即可實(shí)現(xiàn)不同業(yè)務(wù)的流程。
實(shí)際的實(shí)現(xiàn)中，訂單系統(tǒng)將業(yè)務(wù)訴求拆解成不同的指令集，并且提供不同指令操作。
通過指令的組合形成規(guī)則，通過組合不同規(guī)則抽象出具體的模板，進(jìn)行實(shí)例化從而產(chǎn)生具體的接入模型以供不同業(yè)務(wù)接入。
通過不同模板指令，可以快速支撐不同業(yè)務(wù)場景。通過對復(fù)雜指令集的優(yōu)化，還可以使訂單系統(tǒng)的吞吐量，拓展性，穩(wěn)定性都得到很大提升。
下面列舉一個(gè)訂單拆分業(yè)務(wù)的案例進(jìn)行說明。
拆單指令
用戶支付完訂單后，需要獲取訂單的支付信息，包括支付流水號、支付時(shí)間等。支付完訂單接著就是等商家發(fā)貨，但在發(fā)貨過程中，根據(jù)平臺業(yè)務(wù)模式的不同，可能會涉及到訂單的拆分（如果是充值、消費(fèi)類業(yè)務(wù)不存在發(fā)貨情況）。
訂單拆分原因一般分兩種：
（1）電商場景的合并支付：用戶商品來自不同商家，需要進(jìn)行拆單進(jìn)行分賬；
（2）問答、咨詢類場景：用戶支付時(shí)并不知道哪個(gè)平臺或者答者會接單、回答。只有用戶提問最終完成服務(wù)之后才能確定具體的商家，該場景也需要后續(xù)拆單。
這種業(yè)務(wù)可以抽象為拆單指令進(jìn)行實(shí)現(xiàn)。
通過指令編排實(shí)現(xiàn)拆單
創(chuàng)建拆單指令可以進(jìn)行拆解，拆解為兩種指令：拆單類型+拆單策略。根據(jù)業(yè)務(wù)需求通過指令的組合，抽象出規(guī)則并生成二種類型的模板（購物車拆單模板、咨詢問答類拆單模板）并且實(shí)例化出接入模型對外輸出。
當(dāng)有購物車需求的業(yè)務(wù)可以跟進(jìn)接入類型選擇購物車拆單模板如：度小店。
當(dāng)有咨詢問答或者支付后拆單需求的業(yè)務(wù)可以使用咨詢問答拆單模板如：醫(yī)療，百度地圖，盎司手機(jī)充值等。
4.2 架構(gòu)性能優(yōu)化
上一章講解了指令編排在生產(chǎn)環(huán)境中承擔(dān)業(yè)務(wù)場景，接下來會講解指令編排架構(gòu)遇到的問題，以及進(jìn)行優(yōu)化。
上圖是通過指令編排架構(gòu)生成的一個(gè)通用下單模板，功能沒有問題，但是在較高流量的場景下，會遇到性能方面的挑戰(zhàn)。
可以看出的問題有：
順序串行執(zhí)行，調(diào)用鏈路過長，一旦中途一個(gè)指令執(zhí)行出現(xiàn)問題，當(dāng)次請求將返回失敗，穩(wěn)定性無法得到保障；
每個(gè)指令是獨(dú)立的執(zhí)行單元，所以每個(gè)指令都需要單獨(dú)查詢數(shù)據(jù)獲取所需的數(shù)據(jù)，造成對數(shù)據(jù)庫的請求成倍擴(kuò)張。
針對問題，我們逐個(gè)進(jìn)行擊破。
4.2.1 長鏈路串行問題
首先是調(diào)用鏈過長問題做了以下優(yōu)化。
針對數(shù)據(jù)變更不頻繁的數(shù)據(jù)進(jìn)行緩存化，動態(tài)更新機(jī)制，使用緩存淘汰算法（LRU）。核心思想是“如果數(shù)據(jù)最近被訪問過，那么將來被訪問的幾率也更高”。如獲取用戶信息，商品信息接口。
針對非關(guān)鍵路徑的指令配置異步執(zhí)行或者降級執(zhí)行。通過異步線程池來實(shí)現(xiàn)指令異步化，通過指令執(zhí)行時(shí)間來判斷是否降級處理。
通過以上二點(diǎn)完成調(diào)用鏈過長，穩(wěn)定性無法保障的問題。
4.2.2 數(shù)據(jù)庫重復(fù)獲取壓力
針對每個(gè)指令是獨(dú)立執(zhí)行單元要重復(fù)獲取數(shù)據(jù)的問題使用以下解決方案。
同一線程重復(fù)查詢數(shù)據(jù)做到線程級別傳遞，使用ThreadLocal方式進(jìn)行線程之間的數(shù)據(jù)傳遞。
ThreadLocal提供了線程本地變量，它可以保證訪問到的變量屬于當(dāng)前線程，每個(gè)線程都保存有一個(gè)變量副本，每個(gè)線程的變量都不同。ThreadLocal相當(dāng)于提供了一種線程隔離，將變量與線程相綁定。
因通過線程池把非關(guān)鍵路徑的指令異步化后，發(fā)現(xiàn)異步化的指令無法使用ThreadLocal進(jìn)行數(shù)據(jù)傳遞，從而引入全鏈路追蹤組件TransmittableThreadLocal進(jìn)行異步線程數(shù)據(jù)的傳遞。
TransmittableThreadLocal繼承InheritableThreadLocal，使用方式也類似。相比InheritableThreadLocal，添加了：
（1）copy方法用于定制 任務(wù)提交給線程池時(shí) 的ThreadLocal值傳遞到 任務(wù)執(zhí)行時(shí) 的拷貝行為，缺省傳遞的是引用。注意：如果跨線程傳遞了對象引用因?yàn)椴辉儆芯€程封閉，與InheritableThreadLocal.childValue一樣，使用者/業(yè)務(wù)邏輯要注意傳遞對象的線程安全。
（2）protected的beforeExecute/afterExecute方法執(zhí)行任務(wù)(Runnable/Callable)的前/后的生命周期回調(diào)。
4.2.3 數(shù)據(jù)庫性能提升
數(shù)據(jù)庫受限于物理服務(wù)器的CPU、內(nèi)存、存儲、連接數(shù)等資源，在處理上會遇到性能瓶頸，以及在主從同步存在延遲情況，為了下單的達(dá)到2萬QPS并且主從無延遲就需要進(jìn)行性能提升的優(yōu)化。
首先針對不同業(yè)務(wù)需要進(jìn)行數(shù)據(jù)的隔離以及拆分。需要跟進(jìn)業(yè)務(wù)把不同的業(yè)務(wù)數(shù)據(jù)進(jìn)行數(shù)據(jù)隔離，垂直拆分到不同的庫和機(jī)器，從而分別提升不同業(yè)務(wù)的數(shù)據(jù)庫性能和容量。（如：訂單，退款，售后，客訴，商品，庫存等）
某些業(yè)務(wù)雖然庫垂直拆分了，但是單表數(shù)據(jù)增長太快，當(dāng)單表數(shù)據(jù)量太大，會極大的影響sql的執(zhí)行性能，這時(shí)sql會跑的很慢。這時(shí)就需要針對單表進(jìn)行水平切分來減少單表的數(shù)據(jù)量。（如：訂單相關(guān)表，退款相關(guān)表，CPS記錄表）
訂單表進(jìn)行水平切分，首先需要確定分表字段。
消費(fèi)者用戶查詢訂單最頻繁的場景，是通過用戶id以及訂單號這兩種類型進(jìn)行查詢，所以訂單主表的設(shè)計(jì)需要兼容這兩種查詢。
在數(shù)據(jù)模型的設(shè)計(jì)上，由于數(shù)據(jù)庫分表字段只能有一個(gè)，所以這里采用計(jì)算規(guī)則將訂單號和用戶id進(jìn)行關(guān)聯(lián)，即，讓一個(gè)用戶所有的訂單都存儲在一張單表之中，具體手段就是通過用戶id的一種規(guī)則作為分表字段（shardingKey），訂單id生成規(guī)則和分表字段做關(guān)聯(lián)，具體就不進(jìn)行展開說明。
這樣不論通過用戶id還是訂單號查詢都能取到分表字段，從而定位到具體的庫和表。
因?qū)⒄麄€(gè)訂單庫所有表按照統(tǒng)一規(guī)則進(jìn)行切分，分表規(guī)則一致，保證按照同一用戶或者訂單都能在一個(gè)庫，從而可以使用數(shù)據(jù)庫事務(wù)。
針對數(shù)據(jù)庫查詢禁止不帶分表規(guī)則信息的維度的查詢，避免造成輪詢數(shù)據(jù)庫表造成慢查詢情況。
對于查詢用戶id以及訂單號之外的查詢場景，分為兩種實(shí)現(xiàn)：對于高實(shí)時(shí)性的查詢，會建立額外的數(shù)據(jù)庫索引表進(jìn)行存儲，比如手機(jī)號查詢、外部訂單號查詢等。對于低實(shí)時(shí)性要求的查詢，比如商家端查詢訂單數(shù)據(jù)，此時(shí)借助全文檢索的外部數(shù)據(jù)存儲（比如ElasticSearch等數(shù)據(jù)存儲）實(shí)現(xiàn)查詢，我們會通過數(shù)據(jù)庫binlog同步工具，將訂單信息同步到存儲之中來提供查詢。
另外，一定要保證數(shù)據(jù)查詢要存在索引，保證數(shù)據(jù)庫可控，能從長遠(yuǎn)保證庫的擴(kuò)展性和容量的提升。
五、總結(jié)
本文重點(diǎn)在介紹如何通過架構(gòu)、技術(shù)實(shí)現(xiàn)等手段來搭建一個(gè)可靠、完善的訂單系統(tǒng)。實(shí)際生產(chǎn)中，應(yīng)該抓住業(yè)務(wù)上的關(guān)鍵問題，在滿足業(yè)務(wù)的前提下，對流程、需求做合理的減法，以降低整體架構(gòu)的復(fù)雜度。另外，應(yīng)該合理利用開源項(xiàng)目和第三方平臺服務(wù)滿足系統(tǒng)需求，在技術(shù)方案和開發(fā)成本之間做到較好的折衷。
招聘信息
百度移動生態(tài)事業(yè)部MEG，交易支付類核心研發(fā)崗位（Java/PHP/Go）。承接公司全域流量，極速擴(kuò)張中，空間潛力大。歡迎對交易核心鏈路場景感興趣的同學(xué)朋友們加盟！
簡歷投遞郵箱：[email protected]