交易系統(tǒng)一直是電商的核心模塊，幾乎所有業(yè)務(wù)都圍繞其展開，看似簡單的下單流程，實際涉及的模塊、內(nèi)容也很龐雜。這次就把訂單下單的整體鏈路抽象出來，與大家分享。

說到下單，對于用戶而言就是選擇商品-下單-支付-商品運輸-確認(rèn)收貨這樣簡單的主流程，保證了即使是網(wǎng)購新手也可以很快上手。

但對于電商交易系統(tǒng)來說，訂單的生命周期遠(yuǎn)不止上述流程那般簡單。見下圖，對于電商平臺來說一個訂單的生命周期涉及眾多系統(tǒng)，下圖也僅僅是列出了各大系統(tǒng)間的交互流轉(zhuǎn)，且僅涉及正向流程，逆向流程會更加復(fù)雜。

01 關(guān)于訂單

1. 什么是訂單

首先來聊一下什么是訂單？

訂單可以簡單理解為買家與賣家簽訂的一份具備法律效應(yīng)的合約。一般情況下，合同的訂立有要約和承諾兩個程序。賣家展示商品及其價值的行為，便屬于要約；購買者確認(rèn)購買商品并提交訂單的行為屬于承諾，訂單提交后，合同即成立并生效。所以大家可以簡單理解為訂單其實就是一份客戶與商家簽訂的合同，具有法律效益。

2. 訂單的生成與流轉(zhuǎn)

參考上文，如果從前端的體驗來看，訂單的生成就是加車后結(jié)算或立即購買，進(jìn)入結(jié)算界面確認(rèn)訂單各項信息無誤，提交后即生成訂單。

但我們從訂單在內(nèi)部系統(tǒng)生成的流程來看，在生成訂單前需要內(nèi)部各大系統(tǒng)進(jìn)行配合與支撐，包括風(fēng)控系統(tǒng)、商品系統(tǒng)、營銷系統(tǒng)、會員系統(tǒng)、庫存系統(tǒng)等。上述系統(tǒng)流程也僅是對交易主流程的梳理，涉及數(shù)據(jù)在各系統(tǒng)中如何交互并沒有列出，可見整個電商交易系統(tǒng)是何其復(fù)雜。

02 風(fēng)控系統(tǒng)——風(fēng)險訂單檢測、攔截

說到風(fēng)控系統(tǒng)，最容易聯(lián)想到的是銀行借貸、P2P等金融領(lǐng)域的風(fēng)險控制。無論是金融行業(yè)還是電商行業(yè)，風(fēng)控的本質(zhì)都是保證平臺利益不受損失。

電商訂單風(fēng)控主要側(cè)重于兩防——防刷單；防羊毛黨。

1. 防刷單

商家刷單影響平臺流量分配，間接影響商家管理體系的構(gòu)建；商家刷單體系大概歷經(jīng)了兩個時期：野蠻生長，集中刷單；平臺監(jiān)管，精細(xì)化刷單。

電子商務(wù)起步初期，唯銷量論英雄，”培養(yǎng)”了商家們的刷單習(xí)慣，加上平臺監(jiān)管缺失，一個人一臺電腦就能刷上一天，那時候管刷單不叫刷單，叫刷鉆/刷皇冠，主要刷的是店鋪等級。

但“好日子”很快到頭了，隨著平臺的流量分配由店鋪變?yōu)閱纹罚由瞎芾硪?guī)則、風(fēng)控體系不斷完善，商戶們的刷單成本也越來越高，刷單的工作也要交給”專業(yè)”人士來，所謂精細(xì)化刷單就是模擬用戶真實下單場景，騙過系統(tǒng)，讓它認(rèn)為就是普通用戶在下單。精細(xì)到怎么搜到商品，需要瀏覽多少個商品，每個頁面停留多長時間，是靜默下單還是咨詢下單都有嚴(yán)格的規(guī)范。

業(yè)內(nèi)早就形成了認(rèn)知：沒有一勞永逸的防刷單策略，最好的方法就是不斷提高刷單的成本。

2. 防羊毛黨

羊毛黨薅羊毛的做法直接影響平臺/商家收益，損害正常用戶購物體驗。說到羊毛黨離不開另外一個詞：黑產(chǎn)。單兵作戰(zhàn)的羊毛黨不可怕，可怕的是成體系作戰(zhàn)的黑產(chǎn)團(tuán)隊，他們往往分工明確，主攻電商平臺業(yè)務(wù)(規(guī)則)漏洞和系統(tǒng)BUG，薅上一天夠吃一年。

上述流程圖，在用戶提交下單申請后會經(jīng)過風(fēng)控系統(tǒng)的風(fēng)險檢測，但此時的風(fēng)險檢測較為初級，主要針對確定性事件如用戶黑名單、下單環(huán)境等事件進(jìn)行下單攔截。

因為下單時風(fēng)控系統(tǒng)能夠拿到的字段信息較少，缺乏大量數(shù)據(jù)支撐，難以準(zhǔn)確判斷用戶下單行為，且下單流程屬于高并發(fā)場景，系統(tǒng)反饋需要在毫秒級完成，進(jìn)行復(fù)雜的風(fēng)控檢測嚴(yán)重拖慢系統(tǒng)進(jìn)程，因此更復(fù)雜的風(fēng)控會在用戶下單成功后異步進(jìn)行。

進(jìn)行異步風(fēng)控檢測后，系統(tǒng)會對命中風(fēng)控策略的訂單進(jìn)行關(guān)閉(取消訂單)，當(dāng)然風(fēng)控并不只是攔截訂單，在復(fù)雜的場景下還需要有報警機(jī)制，人工介入。

拼多多在19年1月就因為優(yōu)惠券事件被黑產(chǎn)薅了數(shù)千萬羊毛，就是因為缺乏有效的風(fēng)控機(jī)制。

03 商品系統(tǒng)——商品信息的獲取

訂單生成時需要通過商品系統(tǒng)獲取商品基礎(chǔ)信息、數(shù)量、價格。同時部分電商平臺還會記錄交易快照，同樣是需要商品系統(tǒng)支持。

1. 關(guān)于交易快照

什么是訂單商品快照(交易快照)？看字面意思，很容易讓人理解為用戶下單時針對訂單商品詳情的一個快照(截圖)，其實嚴(yán)格來講，商品快照是一個靜態(tài)數(shù)據(jù)合集，記錄了用戶下單時的商品信息，包含：商品圖片、標(biāo)題、描述、服務(wù)等要素。

淘寶是國內(nèi)較早啟用交易快照的電商平臺，為了解決商家與用戶交易糾紛時難以追溯用戶下單時的商品情況，淘寶的產(chǎn)品經(jīng)理引入了交易快照的概念，即用戶的每一次下單，都會對下單時的商品信息做一個記錄，快照作為買賣雙方發(fā)生交易的憑證，任何交易糾紛或者投訴都將以快照為準(zhǔn)。

大多數(shù)電商平臺做交易快照的初衷是為了解決交易糾紛，此外，交易快照還運用于法律訴訟場景，法院進(jìn)行相關(guān)訴訟的裁定時，是認(rèn)可交易快照作為證據(jù)的，但需要證明快照就是用戶下單時的商品快照，無法被篡改。

2. 交易快照的記錄

交易快照的記錄：目前主要有兩種記錄方式，如圖：

• 第一種：用戶每下一單都對訂單商品信息進(jìn)行一次信息記錄，此操作主要由交易系統(tǒng)完成，弊端也很明顯在下單高峰期，會對系統(tǒng)性能產(chǎn)生影響，且數(shù)據(jù)存儲量大。該方案主要適用于低頻交易場景，如大宗商品交易等。
• 第二種方法：由商品系統(tǒng)(基礎(chǔ)數(shù)據(jù))對每一次商品信息變更做備份，之后根據(jù)用戶下單時間映射商品快照。此方案適用于高頻交易場景，且對高并發(fā)下交易系統(tǒng)性能不會產(chǎn)生太大影響。

04 庫存系統(tǒng)——商品庫存校驗

1. 庫存的定義

關(guān)于庫存的定義，百科上給出的解釋是：“倉庫中實際儲存的貨物”。但這里我特別提到了虛擬庫存，為了與實際倉庫庫存做區(qū)分。

目前商家在電商平臺維護(hù)的庫存都叫虛擬庫存，虛擬庫存可以簡單理解為不存在的庫存，它并不跟實際倉庫庫存關(guān)聯(lián)，可以認(rèn)為虛擬庫存就是商家指定的平臺的一個渠道可售庫存。如果商家有一批商品正在生產(chǎn)中、采購中、運輸中或正在入庫，亦或者商家覺得能承擔(dān)住超賣的風(fēng)險，有辦法從其他地方調(diào)貨，設(shè)置虛擬庫存時就可能大于實際倉庫庫存。

2. 庫存預(yù)占與庫存校驗

說到庫存預(yù)占，在電商發(fā)展過程中有個很經(jīng)典的問題：是下單減庫存還是支付減庫存？

現(xiàn)在想一想，應(yīng)該在什么時候減庫存？

線下實體商超是怎樣的？

這里不考慮實體商超倉庫庫存的情況，只考慮貨架庫存。什么時候減庫存呢？或者說什么時候這個庫存會被用戶占據(jù)呢，應(yīng)該是在用戶從貨架拿走商品，放入購物車的時候。

那么線上購物流程也按照加入購物車即減庫存呢？顯然是不行的，線上購物車的”加車”操作幾乎是0成本，決定它更像是作為一個商品收藏池或備忘錄，用戶把備選的商品放入購物車后再進(jìn)行二次選品，加車商品數(shù)遠(yuǎn)大于用戶實際購買數(shù)，故在購物車即扣減庫存效率是低下的。

如果是在下單的時候扣減庫存呢？

相當(dāng)于用戶下單，系統(tǒng)已經(jīng)把相應(yīng)庫存分配給此用戶，用戶支付成功后即可發(fā)貨，這是正常的流程。但會出現(xiàn)下單不支付惡意預(yù)占庫存的情況，導(dǎo)致商家商品未能及時售出，銷售受損。

如果更進(jìn)一步，支付成功時再扣減庫存呢？

此方法一定程度提高了惡意下單的門檻。但問題也產(chǎn)生了，當(dāng)商品供不應(yīng)求，出現(xiàn)大量用戶搶購的情況，此時大部分用戶都能下單成功，但在支付環(huán)節(jié)僅有少部分用戶可完成支付，對于未成功支付的用戶來說，體驗太差。

上述兩種有效方案，無論是下單減庫存還是支付成功減庫存，都不是完美的解決方案。那么應(yīng)該選擇哪一種呢？蘇杰在《淘寶十年產(chǎn)品事》中回憶當(dāng)時淘寶的產(chǎn)品經(jīng)理也是糾結(jié)于選擇哪種方案，最后折中，提供兩種方案，商家自行選擇。

在我看來，對于平臺型電商，下單減庫存優(yōu)于支付成功減庫存。

• 從體驗角度上看：用戶(購物)體驗是平臺型電商的核心競爭力。下單減庫存影響商家銷售，支付減庫存影響用戶體驗，所以從購物體驗角度做取舍，下單減庫存對用戶較為友好。
• 從系統(tǒng)層面上看，支付減庫存是要比下單減庫存復(fù)雜的。支付減庫存涉及 訂單系統(tǒng)-庫存系統(tǒng)-支付系統(tǒng)的交互，而下單減庫存僅由訂單系統(tǒng)-庫存系統(tǒng)完成即可。支付減庫存在高并發(fā)的場景下容易出現(xiàn)超賣現(xiàn)象。

  

• 下單減庫存存在的問題：惡意下單不支付?？梢酝ㄟ^系統(tǒng)規(guī)則來解決：如單用戶限購，超時未支付自動取消訂單(庫存返還)

05 訂單系統(tǒng)——訂單信息記錄

1. 訂單拆單

1）為什么要進(jìn)行訂單拆單？

核心有兩點：便于結(jié)算；便于發(fā)貨。

主要是圍繞上述兩點核心進(jìn)行，常見拆單規(guī)則有：

• 按商家拆單；不同商家間需要拆單
• 按倉庫拆單；不同倉庫間需要拆單
• 按商品重量、體積拆單；快遞公司對包裹最大體積/重量有要求
• 按商品價值拆單；貴重、易損商品單獨拆分等
• 按發(fā)貨方式拆單；如實物商品與虛擬商品混合下單，發(fā)貨方式不同
• 按配送時效拆單；如正常商品與預(yù)售商品混合下單，發(fā)貨時效不同

具體拆單規(guī)則根據(jù)不同平臺不同業(yè)務(wù)場景而異，按照便于結(jié)算、便于發(fā)貨兩大方向去做訂單拆分便能滿足大部分業(yè)務(wù)需求。

2）什么時候拆單

先來看下京東、淘寶分別在什么時候進(jìn)行拆單

• 京東：用戶訂單支付成功后進(jìn)行拆單
• 淘寶：用戶提交訂單，支付前即對訂單進(jìn)行拆單

那么什么時候拆單有何講究？因為業(yè)務(wù)形態(tài)不同，淘寶以商家為主，京東以自營為主。故淘寶拆單邏輯較為簡單，按商家拆單即可滿足絕大部分拆單訴求；而京東因涉及自營倉+商家，除了商家間的拆單，還涉及倉間/倉內(nèi)拆單，拆單邏輯更為復(fù)雜，將拆單邏輯后置到支付成功后，能夠減少無效拆單(未支付訂單不拆單)，提升高并發(fā)時系統(tǒng)性能。

所以在什么時候進(jìn)行訂單拆分，遵循兩大原則：

1. 占用資源最小原則（特別要考慮高并發(fā)場景）；
2. 訂單推送前需要完成拆單（推送至商家/倉庫前都需要完成拆單）

2. 訂單優(yōu)惠計算與優(yōu)惠分?jǐn)?/h3>

早期的淘寶，商品就一個價格，即售賣價，對于商家、用戶來說都足夠簡單，所見即所得。但這種平衡很快被一個功能打破——購物車。購物車的上線標(biāo)志著淘寶進(jìn)入營銷時代，后來我們熟知的滿減、滿折、滿贈、M元N件等促銷玩法都要仰仗購物車。那么訂單優(yōu)惠是怎么計算的呢？

1）遞進(jìn)式門檻計算

既然促銷活動有了，有促銷就會有優(yōu)惠，這些優(yōu)惠怎么算呢，讓我們記住這個詞【遞進(jìn)式門檻計算】，就是它，讓很多用戶抓狂。

提問：購買兩件商品A和B，A單品優(yōu)惠價100元；B單品優(yōu)惠價200元，參加店鋪促銷滿300減50，店鋪優(yōu)惠券滿280減40；同時還參加跨店鋪滿減，每滿290減50。問：在遞進(jìn)式門檻計算規(guī)則下，到手價是多少?

按照【遞進(jìn)式門檻計算】最終到手是：250，這就是一頓操作猛如虎，一看優(yōu)惠兩塊五。

遞進(jìn)式優(yōu)惠計算核心規(guī)則即：根據(jù)上一層級優(yōu)惠扣減后的金額來判斷是否滿足下一層級的優(yōu)惠門檻。所以在【遞進(jìn)式門檻計算】時期，經(jīng)常出現(xiàn)用戶看到某一商品參加了多種活動、領(lǐng)取了各種優(yōu)惠券，最終結(jié)算時僅可以使用一種優(yōu)惠而大罵商家、平臺虛假營銷的情況。

2）平行式門檻計算

前文我們提到：購物體驗是平臺型電商的核心競爭力，在此背景下，淘寶、京東于18年、19年相繼用【平行式門檻計算】替代【遞進(jìn)式門檻計算】。

采用平行式門檻計算規(guī)則后，優(yōu)惠計算清晰明了，以前要糾結(jié)各級優(yōu)惠的觸發(fā)門檻，現(xiàn)在湊單只需要盯著各類優(yōu)惠里門檻最高那個就行，如圖：

此規(guī)則的上線對于平臺用戶、商家來說無疑是利好的，用戶能夠一目了然感知優(yōu)惠力度，商家也能清楚掌握讓利程度。

但這里面存在一個大坑，即平臺在切換優(yōu)惠計算規(guī)則時歷史產(chǎn)生的促銷活動、優(yōu)惠券怎么辦？不處理，商家就要大出血，如圖。

淘寶、京東面對此坑時也是毅然在上線前將平臺所有滿減、滿折、滿贈等促銷活動及優(yōu)惠券作廢。

3. 訂單狀態(tài)的定義

我們常見的訂單狀態(tài)，如下：待付款-待發(fā)貨-已發(fā)貨-已完成-已評價 (已評價狀態(tài)有時也不作為主狀態(tài)存在)

已關(guān)閉、異常

作為電商行業(yè)從業(yè)者需要經(jīng)常跟訂單打交道，每個人都能隨口說出訂單狀態(tài)包含哪些，甚至連會網(wǎng)購的大媽都能說出個123。訂單狀態(tài)算是一套很成熟的體系，對于缺少電商行業(yè)經(jīng)驗的產(chǎn)品來說，在定義訂單狀態(tài)時直接照搬這一套，大概率都不會出錯。

但在這里我還是想聊一下對于訂單狀態(tài)的思考：

首先，說一下狀態(tài)，這個詞對于產(chǎn)品經(jīng)理來說一定不陌生，日常工作中各種單據(jù)、邏輯判斷都會用到。什么是狀態(tài)？我的理解:事物處于某個穩(wěn)定的情態(tài)，在無外力的影響下會一直處于一個穩(wěn)定態(tài)，這個穩(wěn)定態(tài)就可以稱為狀態(tài)。

那么反過來說，在外力的作用下狀態(tài)是可以改變的，這里就衍生出來產(chǎn)品設(shè)計中的一個法則叫“一動一態(tài)”即兩狀態(tài)間有任何數(shù)量級的操作都可以抽象為一個動作，一動一態(tài)的好處主要體現(xiàn)在：降低用戶認(rèn)知成本;便于制定、處理各種狀態(tài)值

回到訂單狀態(tài)，如圖，用戶下單后的一系列操作其實是由三個維度的狀態(tài)(支付狀態(tài)、物流 狀態(tài)、評價狀態(tài))構(gòu)成，但多維度狀態(tài)的存在容易引起認(rèn)知混亂，為解決這一問題，我們傾向于創(chuàng)建一個全局維度的狀態(tài)——訂單狀態(tài)

但如上圖中所示，構(gòu)建后的全局維度涉及訂單下單-配送-簽收評價全流程，涉及：待支付、待發(fā)貨、待攬件、運輸中、派件中、已簽收、已評價，狀態(tài)值依然龐雜。想

一下，我們創(chuàng)建全局維度狀態(tài)要解決的就是降低使用者(商家、消費者)認(rèn)知成本，知道在什么步驟需要執(zhí)行什么操作，所以我們歸納下上述訂單狀態(tài)流轉(zhuǎn)時進(jìn)行相關(guān)操作的執(zhí)行角色：

• 消費者：支付、簽收、評價
• 商家：發(fā)貨
• 物流公司：攬件、走件、派件

我們會發(fā)現(xiàn)，需要消費者、商家操作的僅有：支付、發(fā)貨、簽收、評價。在定義一動一態(tài)法則時我們講到：任何數(shù)量級操作都可以抽象為一個操作，為了降低使用者(商家、消費者)認(rèn)知成本，我們可以把[發(fā)貨、攬件、走件、派件] 這一流程抽象為一個操作——發(fā)貨。這樣一來就明了了

4. 訂單號的設(shè)計

訂單號的設(shè)計是一門藝術(shù)，能夠參與訂單號規(guī)則設(shè)計是一件令人興奮的事情，這種機(jī)會通常只在電商項目從0到1的時候有。那么訂單號的設(shè)計應(yīng)遵循哪些原則呢？

1）唯一性

訂單號作為訂單表的主鍵，需要確保唯一性。

2）易讀性

這里易讀性主要體現(xiàn)在系統(tǒng)易讀性和溝通易讀性。

要求訂單號不宜過長且盡量為純數(shù)字，不宜出現(xiàn)字母、符號、數(shù)字混用的情況，否者對于系統(tǒng)存儲、查詢性能、以及與用戶的溝通成本來說都是一種負(fù)擔(dān)。

3）安全性

非特殊情況盡量不要在訂單號中帶入平臺運營特征信息，如訂單數(shù)量，避免泄露運營數(shù)據(jù)。除非故意要讓競對知道你的運營數(shù)據(jù)。

瑞幸咖啡較早之前門店訂單量就是逐一增加，后續(xù)也加入了隨機(jī)因子，就是擔(dān)心外界通過訂單編號獲得店鋪每天成交量。

4）擴(kuò)展性

訂單號設(shè)計需要考慮擴(kuò)展性，如隨著平臺業(yè)務(wù)發(fā)展，訂單量激增訂單號不夠用的情況

5）語義性

訂單編號規(guī)則中加入帶有語義的特征信息，能在一定程度上提升平臺人員處理訂單的效率與便捷性。

常見的特性信息有：訂單生成時間(年月日)、下單渠道、支付渠道、業(yè)務(wù)類型等，但訂單編號中不宜攜帶過多特征信息，否則會出現(xiàn)不法分子通過描述訂單信息博取用戶信任進(jìn)行實施詐騙。

說到語義性，細(xì)心的同學(xué)會發(fā)現(xiàn)，自己淘寶訂單號后6位都是一樣的。訂單號后6位其實就是用戶id后6位。那么淘寶訂單編號中用了用戶id后6位是否代表了語義性？答案是否定的，因為只用后6位id并不能準(zhǔn)確定位到某一個用戶。

那么淘寶訂單編號后6位用戶id后6位的目的是什么？

翻遍了百度、知乎，沒有找到答案。

我是偶然間翻到一份淘寶技術(shù)演變PPT，看到訂單表分庫的邏輯時才恍然大悟。

一般的平臺型電商，訂單量大，為保證查詢檢索速度，都會采用分庫的形式，將巨量的訂單信息分庫存儲，一般情況下訂單系統(tǒng)同時維護(hù)了一個訂單號和userid的關(guān)聯(lián)關(guān)系，先根據(jù)訂單號查到userid，再根據(jù)userid確定分表進(jìn)而查詢得到內(nèi)容。而淘寶在訂單號上下功夫，通過訂單號后6位直接鎖定庫表，大大提升高并發(fā)下的系統(tǒng)查詢性能。

從這個策略我們也可以看到淘寶用戶訂單庫是按照用戶id后6位存儲的，例如：XXXX452154格式的用戶訂單都是儲存在一個分庫中。

本文由 @阿鐵 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議