手撕商城系統架構設計與實現

背景
商城整體架構
訂單系統
商品系統
促銷系統
支付系統
推薦系統
積分系統
會員系統
總結

1. 背景

隨著網際網路技術廣泛應用，各行各業都依託線上平臺進行商務活動。小到個人帶貨，大到企業商業活動，都少不了需要少不了線上交易。於是，到處可見商城影響，不管是加盟大的電商平臺如淘寶、京東、拼多多，或是企業自建商城平臺，目的基本都是擴大生意渠道，賣貨增加業績收入。

下面基於我們公司自建商城平臺，來談談我們商城架構設計方案。

2. 商城整體架構

一般來說，商城系統按單體服務方案去構思的話，按模組劃分至少包括：商品、訂單、會員、促銷、支付、積分、倉儲、物流、風控、企業內部erp、財務系統等。

公司原有技術架構是SpringCloud微服務架構，所以商城系統也是在這個體系下，同時根據我們公司實際業務特殊和複雜性，對各個模組進行微服務劃分，業務領域分成多個業務中臺和資料中臺。

設計商城整架構如下：

一個完整商城體系結構是比較複雜的，涉及到很多關聯絡統和子系統模組。

採用分層設計，從系統分層設計角度考慮，可以劃分：前端接入層、應用表示層、中臺服務、後端服務層、基礎服務層。

3. 訂單系統

2.1、訂單系統邊界

在搭建企業訂單系統之前，需要先梳理整體業務系統之間的關係和訂單系統上下游關係，只有劃分清業務系統邊界，才能確定訂單系統的職責與功能，進而保證各系統之間高效簡潔的工作。

對外服務展示，所有給企業外部使用者使用的系統都在這一層，包括WEB、普通使用者使用的C端，還包括給商戶使用的商家後臺和在各個銷售渠道進行分銷的系統，比如與銀行信用卡中心合作、微信合作在合作商的平臺展示出本產品。這類系統站在與客戶接觸的最前線，是企業實現商業模式的橋頭堡。

中後臺系統，每個C端的業務形態都會有一個對應的系統模組，如負責管理平臺交易的訂單系統，管理優惠資訊的促銷系統，管理平臺所有產品的產商品系統，以及管理所有對外系統顯示內容的內容系統（CMS）等。

基礎服務系統，隨著企業的發展，資訊化建設到達一定程度後，企業需要將通用功能服務化、平臺化，以保證應用架構的合理性，提升服務效率。這類系統主要給其他應用系統提供基礎服務能力支援。

由此可見，訂單系統對上接收使用者資訊，將使用者資訊轉化為產品訂單，同時管理並跟蹤訂單資訊和資料，承載了整個交易線的重要對客環節。

對下則銜接產品系統、促銷系統、倉儲系統、會員系統、積分系統、支付系統等，對整個電商平臺起著承上啟下的作用。

2.2、訂單系統業務架構

訂單服務，該模組的主要功能是使用者日常使用的服務和頁面，主要有訂單列表、訂單詳情、線上下單等，還包括為公共業務模組提供的多維度訂單資料服務。

訂單邏輯，訂單系統的核心，起著至關重要的作用，在訂單系統負責管理訂單建立、訂單支付、訂單生產、訂單確認、訂單完成、取消訂單等訂單流程。還涉及到複雜的訂單狀態規則、訂單金額計算規則以及增減庫存規則等。

底層服務，資訊化建設達到一定程度的企業，一般會將公共服務模組化和中臺化，比如：產品，會構建對應的產品系統，程式碼、資料庫，介面等相對獨立。但是，這也帶來了一個問題，比如：訂單建立的場景下需要獲取的資訊分散在各個系統。組裝資訊的時候會比較麻煩。

如果需要從各個中臺系統呼叫：一是會花費大量時間，二是程式碼的維護成本非常高。因此，訂單系統接入所需的公共服務模組聚合介面，在訂單系統即可完成對接公共系統的服務。

2.3、訂單核心功能

功能腦圖

為了使訂單系統能夠對訂單進行高效、精準的管理和跟蹤，訂單會儲存關於產品、優惠、使用者、支付資訊等一系列的訂單實時資料，來和下游系統，如：促銷、倉儲、物流進行互動。

以一個通用B2C商城的訂單為例，梳理其包含的資訊如下：

這裡要注意的是訂單型別，隨著平臺業務的不斷髮展，品類豐富、交易方式豐富後，需要對訂單進行多維度的分類管理，同時訂單型別利於訂單系統的擴充套件性。每種訂單型別將會對應一套流程及一套狀態，便於對訂單進行分類管理和複用。

2.4、訂單正向流程

2.4.1、訂單建立

使用者下單後，系統需要生成訂單，此時需要先獲取下單中涉及的商品資訊，然後獲取該商品所涉及到的優惠資訊，如果商品不參與優惠資訊，則無此環節。

接著獲取該賬戶的會員權益，這裡要注意的是：優惠資訊與會員權益的區別，比如：商品滿減是優惠資訊，會員全場9.8折指的是會員權益，一個是針對商品，另一個是針對賬戶。其次就是優惠活動的疊加規則和優先順序規則等。

增減庫存規則是指訂單中的商品，何時從庫存系統中對相應商品庫存進行扣除，目前主流有兩種方式：

（1）下單減庫存——即使用者下單成功時減少庫存數量

優勢：使用者體驗友好，系統邏輯簡潔。

缺點：會導致惡意下單或下單後卻不買，使得真正有需求的使用者無法購買，影響真實銷量。

解決辦法：

設定訂單有效時間，若訂單建立成功N分鐘不付款，則訂單取消，庫存回滾；

限購，用各種條件來限制買家的購買件數，比如一個賬號、一個ip，只能買一件；

風控，從技術角度進行判斷，遮蔽惡意賬號，禁止惡意賬號購買。

（2）付款減庫存——即使用者支付完成並反饋給平臺後再減少庫存數量

優勢：減少無效訂單帶來的資源損耗。

缺點：因第三方支付返回結果存在時差，同一時間多個使用者同時付款成功，會導致下單數目超過庫存，商家庫存不足容易引發斷貨和投訴，成本增加。

解決辦法：

付款前再次校驗庫存，如確認訂單要付款時再驗證一次，並友好提示使用者庫存不足；

增加提示資訊：在商品詳情頁，訂單步驟頁面提示不及時付款，不能保證有庫存等。

綜上所述，兩種方式各有優缺點，因此，需結合實際場景進行考慮，如：秒殺、搶購、促銷活動等，可使用下單減庫存的方式。而對於產品庫存量大，並行流量沒有那麼強的產品使用付款減庫存的方式（秒殺系統設計是在另外檔案中專題描述）。

將兩種方式帶入到銷售場景中，關聯商品型別、促銷型別、供需關係等，靈活使用，以充分發揮計算機系統的優勢。

2.4.2、訂單支付

使用者支付完訂單後，需要獲取訂單的支付資訊，包括支付流水號、支付時間等。支付完訂單接著就是等商家發貨，但在發貨過程中，根據平臺業務模式的不同，可能會涉及到訂單的拆分。

訂單拆分一般分兩種：

一種是使用者挑選的商品來自於不同渠道（自營與商家，商家與商家）；

另一種是在SKU層面上拆分訂單：不同倉庫，不同運輸要求的SKU，包裹重量體積限制等因素需要將訂單拆分。

訂單拆分也是一個相對獨立的模組，可以採用子母單的形式，也可以採用服務單和訂單形式，總的來說就是1：N關係。

2.4.3、訂單生產

訂單生產，是指產品從企業到使用者這一流程的概述。如電商平臺中，商家發貨過程已有一個標準化的流程，訂單內容會傳送到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送（在我們這裡一般是由供應商完成）。

2.4.4、訂單確認

收到貨後，訂單系統需要在快遞被簽收後提醒使用者對商品做評價。這裡要注意，確認收到貨不代表交易成功，而是售後服務的開始。

2.4.5、訂單完成

訂單完成是指在收到貨X天的狀態，此時訂單不在售後的支援時間範圍內。到此，一個訂單的正向流程就算走完了。

2.4、訂單逆向流程

上面說到逆向流程是各種修改訂單、取消訂單、退款、退貨等操作，需要梳理清楚這些流程與正向流程的關係，才能理清訂單系統完整的訂單流程。

2.4.1、訂單修改

可梳理訂單內資訊，根據資訊關聯程度及業務訴求，設定訂單的可修改範圍是什麼，比如：客戶下單後，想修改收貨人地址及電話。此時只需對相應資料進行更新即可。

2.4.2、訂單取消

使用者提交訂單後沒有進行支付操作，此時使用者原則上屬於取消訂單，因為還未付款，則比較簡單，只需要將原本提交訂單時扣減的庫存補回，促銷優惠中使用的優惠券，權益等視平臺規則，進行相應補回。

2.4.3、退款

使用者支付成功後，客戶發出退款的訴求後，需商戶進行退款稽核，雙方達成一致後，系統應以退款單的形式完成退款，關聯原訂單資料。因商品無變化，所以不許考慮與庫存系統的互動，僅需考慮促銷系統及支付系統互動即可。

2.4.4、退貨

使用者支付成功後，客戶發出退貨的訴求後，需商戶進行退款稽核，雙方達成一致後，需對庫存系統進行補回，支付系統、促銷系統以退款單形式完成退款。最後，在退款/退貨流程中，需結合平臺業務場景，考慮優惠分攤的邏輯，在發生退款/退貨時，優惠該如何退回的處理規則和流程。

2.5、狀態機設計

狀態機是管理訂單狀態邏輯的工具。狀態機可歸納為3個要素，即現態、動作、次態。

現態：是指當前所處的狀態。

動作：動作執行完畢後，可以遷移到新的狀態，也可以仍舊保持原狀態。

次態：動作滿足後要遷往的新狀態，「次態」是相對於「現態」而言的，「次態」一旦被啟用，就轉變成新的「現態」了。

狀態機的設計需要結合平臺實際業務場景，將狀態間的切換細化成了執行了某個動作。

以一個B2C商城的訂單系統舉例，狀態分類如下：

訂單系統為了高效的對訂單進行跟蹤和管理，會對訂單流程當中的關鍵節點，抽象出訂單狀態。而訂單狀態從不同使用者的角度可分為：系統訂單狀態、商家訂單狀態、買家訂單狀態等。

對於訂單系統來說，訂單狀態細分的顆粒度越細、越明確，訂單系統管理的精度和可靠性就越高，比如：在待付款和待發貨兩個狀態中，訂單系統後臺會細分為：訂單超時取消、訂單支付失敗、訂單付款完成等。

因此，訂單狀態模組中，通常會維護狀態對映表，以不同的使用者角色對系統訂單狀態進行重新劃分，以滿足不同使用者的需求。

除此以外，隨著業務的不斷髮展，不同的業務型別，所對應的訂單狀態都會有所區別。所以，訂單系統中一般會儲存多套狀態機，以滿足不同的訂單型別來使用。

2.5、關鍵程式碼片斷

稍候補上。。。。。

3. 產品商品系統

由於寫在一起篇幅太長，拉上拉下的設定一格式實在不好編輯；另外各位看官看文章太長也心思看完，看久也累！故每個子系統分開寫！

請看下一篇》》》》產商品系統架構設計