背景
在電商交易中臺團隊工作了一段時間，越發覺自己需要學習的東西還有很多，因此想要定期整理、反思一下所見、所想，因此先從接觸的訂單中心開始。
訂單是什麼，我所理解，訂單就是交易行爲的記錄。是用戶某一刻在平臺上購買的憑證，訂單當時對應的商品、優惠等信息是不可更改的。換一種說法就是訂單是交易行爲的快照。在按下”快門“（下單）的一刻，所有信息都被鎖定了。
訂單在公司業務中也是起一個大上下文的作用，保存着完整的元數據，下游需要時自取。因此對訂單的設計註定是更加看重擴展性的。不然每來一個新的業務，都需要通過加字段或者和產品說這個需求做不了，那就證明訂單的設計還有待提升。
目標
訂單中心要能搭載整個電商平臺的訂單，使用統一、穩定的模型支撐不同的業務。提供穩定、可靠、原子的訂單api服務。
模型設計說明
訂單模型該怎麼設計？訂單模型該考慮哪些點？訂單表該有哪些字段？
訂單表的設計不是騰空降下來的，每個點、每個字段都應該是有憑有據的。
三級訂單
訂單聯繫着這麼多領域，不同領域關心的訂單維度不一樣，如何更好的服務着各個領域呢？
爲了訂單引入了三級訂單模型：
支付級訂單(L1訂單)、店鋪級訂單(L2訂單)、商品級訂單(L3訂單)。
支付級：L1訂單，對應的用戶付款，也就是合併支付單，用戶的一次交易行爲實付款就在這邊，平臺級的優惠也記錄在此。
店鋪級：L2訂單，對應店鋪，下單按照店鋪的維度拆分而得，也是c端用戶可見的訂單，店鋪級優惠、運費記錄在此。（仔細看看京東、淘寶都不是都是按照此維度拆單的）
商品級：L3訂單，對應商品，下單按照sku的維度拆分而得，商品級優惠記錄在此。
三級訂單之間通過”父子”的方式相互關聯，店鋪級訂單的父訂單是支付級，商品級訂單的父訂單是店鋪級。
支付級 1:n 店鋪級 1:n 商品級
三個維度的訂單，其實大部分字段是相同的，因此就不創建三張表，而是合併在一個訂單中，通過level區分到底是哪一級訂單。
訂單模型詳細設計
那麼支撐電商平臺全業務的訂單表主要包含哪些字段呢？我使用腦圖的方式列幾個大概點
這個多信息，訂單都要記，訂單表那得有多少字段啊？
仔細分析，非也。有很多數據是無需作爲單獨字段存儲在訂單主表的，就比如商品、店鋪的完整快照，作用只是爲了留存，完全沒有必要放在主表中。
一些平常偶有查詢需求的信息，可以放在訂單的擴展字段中，使用大json保存，方便擴展，可讀性也好。
不過排除了這些”冷“字段後，訂單表還是有很多字段，畢竟是要作爲訂單中心支撐電商全業務，字段比一般業務的表要多，也無可厚非了。
容量規劃
目標是支持平臺未來n年的發展，因此分庫分表是必須的，按照電商數據的使用場景維度，劃分爲買家庫、賣家庫是最爲常見的。
買家庫，顧名思義，根據買家id作爲分片鍵路由到某一分表，但訂單號作爲訂單表的”硬通貨“，其使用場景比買家id還要多。因此訂單表的分片鍵需要有兩個（買家id和訂單id是或的關係）。一次sql操作條件必須包含買家id或訂單id，兩個分片鍵怎麼保證路由到同一分表呢？數據一樣，路由算法一樣，那麼肯定會路由到同一分表，因此想到在訂單號中添加用戶id就是一個可行的方案。路由函數用最簡單的分片鍵取模分片數。根據分片的數量來計算出訂單號中冗餘買家id的位數，比如我需要分256片，那麼訂單號末尾增加用戶id的後三位即可。
什麼，你問我有支持這種兩個分片鍵的分庫分表中間件嗎？阿里雲drds奉上 阿里雲drds，range_hash拆分函數。
什麼，你問我有免費的嗎？sharding-jdbc 改造下路由策略即可，我司就是之前用的drds，後來遷移至自研sharding-jdbc上。
差點忘了，還有賣家庫。想象一下，如果我們是下單系統在下單時不僅要插入買家庫，還有賣家庫，那下單接口的tps就會嚴重受限，why？創建訂單本就是一個很重的操作，兩個很重的sql執行，又慢，大促時還增加了數據庫抖動造成下單失敗的概率。
我們仔細分析下場景，買家庫服務於c端用戶，數據實時性要求高，我下了一單，去訂單列表結果發現沒有？那問題就嚴重了。
但用戶下了一單，賣家在後臺列表短時間沒看到，這是完全可以接受的，賣家是爲了發貨，就算實時看到，也不能立馬發貨。
因此在賣家庫數據的產生上，我們使用異步的方式優化。
主要方案是，監聽買家庫的binlog，插入到賣家庫中。賣家庫不允許直接修改，完全由binlog保障與買家庫的一致性。
方案的優勢：提升了下單接口的性能，使用binlog + 消息解耦了賣家庫數據的產生。
方案的弊端：一致性不能完全保障，後續需要對賬系統進行嚴格保障。大促數據量大，賣家庫可能會有較大的延時。
總結
我認爲電商訂單中心要想設計的”好“，首先對電商全鏈路業務必須有一定的瞭解，不然可能考慮點會欠缺一點，還可能會產生一些額外的過度設計。建立穩定的數據模型與業務模型，系統可以慢慢不斷實踐、總結、優化，最終朝着目標慢慢迭代。