電商系統之訂單系統
01
概述
訂單系統作為電商系統的“紐帶”貫穿了整個電商系統的關鍵流程。其他模塊都是圍繞訂單系統進行完善的。訂單系統的演化也是隨著電商平臺的業務變化而漸漸演化進化著，接出來就和你們一上去解析電商平臺的“生命紐帶”。
上帝視角訂單系統
訂單系統的作用是：管理訂單類型、訂單狀態，搜集關于商品、優惠、用戶、收貨信息、支付信息等一系列的訂單實時數據，進行庫存更新、訂單下發等一系列動作。訂單系統業務的基本模型涉及用戶、商品（庫存）、訂單、付款，訂單基本流程是下訂單——>減庫存，這兩步必須同時完成，不能下了訂單不減庫存（超買），或則減了庫存沒有生成訂單（少賣）。超買店家庫存不足，消費者下了單買不到東西，體驗不好；少賣店家庫存積壓或則須要反復更改商品信息，反復麻煩，體驗也不好。
02
訂單基本概念
設計訂單系統時包含幾個大的方向須要考慮，這種內容決定了訂單系統的穩定性和可持續性。
訂單的多樣性特征
主要來歷源和操作的多樣造成了訂單多樣性點。
訂單數組
訂單數組包含了訂單中須要記錄的信息，他的作用主要用于溝通其他系統，為下游系統提供信息根據。
訂單信息
訂單號作為訂單辨識的標示，通常依照某種特定規則生成，依照訂單的降低進行自增，同時在設計訂單號的時侯考慮訂單無序設置（避免競爭者或則第三方來計算訂單量）。訂單號后續用作訂單惟一標識用于對接WMS（倉存管理系統）和TMS（運輸管理系統）時的訂單辨識。
訂單狀態
訂單狀態在下邊章節會詳盡描述
用戶信息
指賣家的相關信息，包括名稱、地址、手機號。O2O就會多一種情況就是自提點，這樣地址則會變為自提點的地址。地址信息在后續會作用在WMS和TMS上用于區分區域和配送安排。
商品信息
商品的基本信息和庫存，金額因為比較特殊所以我把金額獨立在商品信息以外說，不過邏輯上似乎都屬于商品信息范疇。商品信息主要影響庫存更新和WMS形成。
金額信息
訂單形成的商品信息，這兒面不僅要記錄最終的金額，過程金額也須要記錄。例如商品均攤的讓利金額、支付金額，應付金額等。在后續的訂單結算、退換貨、財務等環節都須要使用。
時間信息
記錄訂單每位狀態節點的觸發時間。
03
訂單流程
訂單流程是指整個訂單從形成到完成整個流轉過程，包括了正向和逆向流程的過程。
正向流程
這兒面主要是涉及主流電商系統中的通用訂單流程，部份細節可以依照自己平臺的特殊性進行調整。
須要注意的地方
訂單生成環節存在超時未支付手動取消的過程，庫存的占用會在訂單取消后釋放。
假如選擇COD（貨到付款）則支付環節相應轉移到訂單配送以后，而過程中所有與貨款相關的邏輯變為只操作金額數字，不對結算和帳戶進行打退票操作。
金額平攤須要到商品
訂單系統初審主要對惡意用戶或則刷單情況進行處理。系統可依照白名單、黑名單、消費頻次、促銷品訂購量方面做風控規則。假如后續會步入到人工初審，則規則上可以適當從寬。當觸發規則須要進行訂單退訂的行為。此處設計時要當心對用戶體驗的損害，常常前臺文案上說明當前節點是初審狀態或則是等待接單。
傳統電商則是通過關聯第三方貨運的貨運信息進行跟蹤。
預售等貨和移倉須要弄成SOA服務，便于在交易頁面估算預計時間和預計到貨時間。移倉處理依賴庫房的情況，也會涉及到后續分拆和合并包裹的邏輯。
訂單形成時先要判定報缺情況，若果出現報缺問題則要考慮整單報缺、部分報缺、換貨或則換轉退的情況（庫存，匆忙調撥和退票）。報缺情況分為系統報缺和實物報缺，這是承接但相對獨立的兩個環節。
電商系統要考慮7天無理由退款的情境，即訂單狀態完成后申請退款。此時主要涉及的是金額上的估算以及一些財務程序（如收據等）問題的處理。
逆向流程
逆向流程指訂單發生取消、退貨等情況時引起的訂單流程過程。
觸發逆向流程的觸發主要有幾種情況：
關注點
訂單狀態（某一節點后如訂單形成后不容許取消訂單）
當退單被店家拒絕后須要轉到客服仲裁的環節
部份退的訂單促銷通常保持享用狀態，但金額根據均攤的金額進行退票
訂單狀態
從訂單狀態設計目的和存在價值去剖析和理解它背后設計機制：維度及維度顆粒度大小。
1.正向和逆向流程維度
2.服務對象維度
訂單推送
當狀態發生變化時，須要將對應的變化情況告知給相關人員便于了解當前訂單的情況，這就是訂單推送的作用。
訂單推送的觸發依賴于狀態機的變化，涉及到的信息包括
04
訂單系統設計的挑戰和實踐
訂單系統需求演化
第一步：實現訂購流程
1.實現訂單的創建、發貨、確認等信息閉環
2.支持訂單初審（早期可支持人工初審即可）
3.支持用戶端顯示訂單相關信息
4.支持促銷金額的估算
第二步：提供服務
1.提供訂單分布式服務
2.支持跨平臺交易單生成（即同一個大交易單內既有店家商品又有自營商品或則是多個店家的商品）
3.支持拆單、合并邏輯（配送單、支付單等）
4.提供更豐富的訂單推送服務，建立訂單狀態
第三步：支持不同營銷手段下的訂單類型
平臺發展到足夠大的規模，提效、穩定弄成一個重要的話題。可以提供不同營銷場景下的訂單，如：團購、預購等。
訂單系統構架的演化
第一代：簡單粗魯
第一代的問題
第一代系統因為，訂單狀態是在特定的服務器進行處理，假如服務一旦出現問題都會導致訂單的遺失，造成訂單流程難以進行下去。
總結：
1、服務單點
2、數據庫單點
第二代：無狀態異步驅動
第二代系統對于第一代有了挺好的提高，應用服務器不再保留訂單狀態，并且這樣的系統設計同時也給數據庫服務器導致了高頻查詢帶來的壓力，造成數據庫相對比較脆弱。
總結：
狀態掃描帶來的負載
第三代：隊列模式
第三代是對于第二代的升級，訂單的狀態流轉不再借助高頻查詢數據庫來獲得，通過隊列模式，挺好減少了數據庫的壓力，而且第三代仍然有問題，就是該系統中成了核心，該模塊的維護都會顯得很復雜，這也是構架設計的關鍵，沒有完全的完美構架，只能得到一個平衡構架。
三代系統演化中的最佳實踐
實踐1:重試和補償
實踐2:冪等性
實踐3:一致性實踐
實踐4:工作流()
無狀態的，分布式布署，分布式儲存工作流狀態
定時器、重試、冪等性、強一致性的狀態
工作流的描述和執行描述相分離,支持異步觸發
系統優化
數據庫讀寫分離
基本的原理是讓主數據庫處理事務性查詢，而從數據庫處理查詢。數據庫復制被拿來把事務性查詢造成的變更同步到集群中的從數據庫。其實，主服務器也可以提供查詢服務。使用讀寫分離最大的作用無非是環境服務器壓力。
用處
降低冗余
降低了機器的處理能力
對于讀操作為主的應用微信訂單系統，使用讀寫分離是最好的場景，由于可以確保寫的服務器壓力更小，而讀又可以接受點時間上的延后。
讀寫分離提升性能之緣由
化學服務器降低，負荷降低
主從只負責各自的寫和讀，極大程度的減輕X鎖和S鎖爭用
從庫可配置引擎，提高查詢性能以及節省系統開支
從庫同步主庫的數據和主庫直接寫還是有區別的，通過主庫發送來的恢復數據，并且，最重要區別在于主庫向從庫發送是異步的，從庫恢復數據也是異步的
讀寫分離適用與讀遠小于寫的場景，假如只有一臺服務器，當好多時，和會被那些訪問中的數據堵塞，等待結束，并發性能不高。對于寫和讀比列相仿的應用，應當布署雙主互相復制
可以在從庫啟動是降低一些參數來提升其讀的性能，比如--skip-、--skip-bdb、--low--以及--delay-key-write=ALL。其實這種設置也是須要依照具體業務需求來定得，不一定能用上
平攤讀取。如果我們有1主3從，不考慮上述1中提及的從庫單方面設置，假定現今1分鐘內有10條寫入，150條讀取。這么，1主3從相當于共計40條寫入，而讀取總量沒變，因而平均出來每臺服務器承當了10條寫入和50條讀取（主庫不承當讀取操作）。為此，即使寫入沒變，然而讀取大大平攤了，增強了系統性能。另外，當讀取被平攤后，又間接提升了寫入的性能。所以，總體性能提升了，說白了就是拿機器和帶寬換性能。
MySQL復制另外一大功能是降低冗余，提升可用性，當一臺數據庫服務器宕機后能通過調整另外一臺從庫來以最快的速率恢復服務，因而不能光看性能微信訂單系統，也就是說1主1從也是可以的。
實現方案
數據庫分庫分表
不管是采用何種分庫分表框架或則平臺，其核心的思路都是將原先保存在單表中太大的數據進行分拆，將那些數據分散保存到多個數據庫的多個表中，防止由于單表數據量太大給數據的訪問帶來讀寫性能的問題。所以在分庫分表場景下，最重要的一個原則就是被分拆的數據盡可能的平均拆分到前端的數據庫中，假如分拆的不均勻，就會形成數據訪問熱點，同樣存在熱點數據由于下降過快而又面臨數據單表數據量過大的問題。
而對于數據以哪些樣的經度進行分拆，你們看見好多場景中都是對業務數據的ID(大部份場景此ID是以自下降的形式)進行HASH取模的方法將數據進行平均分拆，這個簡單的方法確實在好多場景下都是十分合適的分拆方式，但并不是在所有的場景中這樣分拆的方法都是最優的選擇。也就是說數據怎么分拆并沒有所謂的金科玉律，更多的是須要結合業務數據的結構和業務場景來決定。
下邊以你們最熟悉的電商訂單數據分拆為例，訂單是任何一個電商平臺都有的業務數據，每位平臺用戶遞交訂單就會在平臺前端生成訂單相關的數據，通常記錄一條訂單數據的數據庫表結構如下：
訂單數據主要由三張數據庫表組成，主訂單表對應的就是用戶的一個訂單，每遞交一次就會生成一條主訂單表的數據。在有些情況下，用戶可能在一個訂單中選擇不同買家的商品，而每位買家又會根據該訂單中自己提供的商品估算相關的商品讓利（如滿100元減10元）以及根據不同的收貨地址設置不同的貨運配送，所以會出現子訂單的相關概念，即一個主訂單會由多個子訂單組成，而真正對應到具體每位商品訂單信息，則保存在訂單詳情表中。
假如一個電商平臺的業務發展健康的話，訂單數據是比較容易出現由于單個數據庫表中的數據量過大而導致性能的困局，所以須要對他進行數據庫的分拆。此時從理論上對訂單分拆是可以由兩個經度進行的，一個經度是通過訂單ID（通常為自下降ID）取模的方法，即以訂單ID為分庫分表鍵；一個是通過賣家用戶ID的經度進行哈希取模，即以賣家用戶ID為分庫分表鍵。
兩種方案做一下對比：
1、如果是根據訂單ID取模的方法，例如按1024取模，則可以保證主訂單以及相關子訂單，訂單詳情數據平均落入到前端1024個數據庫表中，原則上挺好地滿足了數據盡可能平均分拆的原則。
2、通過采用賣家ID取模的方法，例如也是根據1024取模，技術上則也能保證訂單數據分拆到前端的1024個數據庫表中，但這兒都會出現一個業務場景中帶來的問題，就是假如有些買家是交易量十分大的，那這種買家的訂單數據量（非常是訂單詳情表的數據量）會比其他買家要多處不少，也就是會出現數據不平均的現象，最終造成這種買家的訂單數據所在的數據庫會相對其他數據庫提早步入數據歸檔（為防止在線交易數據庫的數據的減小帶來數據庫性能的問題，通常將3個月內的訂單數據保存在線交易數據庫中，超過3個月的訂單會歸檔前端專門的歸檔數據庫）。
所以從對『數據盡可能平均分拆』這條原則來看，根據訂單ID取模的形式看上去更能保證訂單數據的平均分拆，但我們暫時不要那么快下推論，也要按照不同的業務場景和最佳實踐角度多思索不同經度帶來的異同點。
總結
電商平臺的需求始終在變化，驟然訂單系統的構架也會急劇變化，構架設計就是一個持續改進的過程，這篇文章還有很多細節未提到，假如你想把訂單系統做的更好，須要愈發深入系統的每一個環節，例如：容災、災備、分流、流控都須要漸漸雕鑿，在構架中沒有完美的構架只有平衡的架構，不要追求單點的完美，而是要追求多點的平衡。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
