1、電商系統可能是世界上最複雜的業務系統

2、一圖描述電商架構

以下僅展示與電商直接有關聯的系統模塊，而對于一個大型企業的IT系統架構，是遠不止下圖中包含的系統單元的。隨著業務的發展，每個系統單元都需要長時間叠代，其成熟的過程中凝聚了大量的人力物力，鄙人只能管中窺豹，從概念層面來描述，每個系統模塊的大致功能。

3、從一個訂單開始說起

由一個用戶下單的主幹流程，可以看出所有系統之間的交互流程，直接畫圖說明。不同公司的業務、團隊劃分都不同，故此IT架構的劃分也不是絕對的，舉例來說，支付業務，我在圖中劃分到了交易中心，而現實中也有並入結算中心的。

4、庫存怎麽來的？

5、各業務單元概念及作用簡析

由以上2個主幹流程和系統架構圖，可以對電商系統的全鏈路有個基礎了解，下面再用文字描述一下各個系統單元的概念和作用。每個模塊的PRD都可以單獨成章，在一篇文章當中也不可能描述所有細節，但對于部分系統的解析，可以在我的博客中看到，我也會持續更新。

6、大前台

6.1各個銷售前端

一家公司往往有多個銷售渠道，線下有不同類型的加盟店直營店等等，線上也有不同模式的電商，而這些觸點用于直接讓用戶接觸到商品。拿阿裏巴巴來說，在淘寶體系下本身有天貓超市、普通商家端、淘寶直播、天貓APP等等。

6.2 CMS

除了商品頁面之外網站和APP還有其他的內容頁面，比如說店鋪的首頁、維修退換政策、活動頁面等，這些都要用單獨的內容管理系統去承載，直觀的了解來看大家都用過QQ空間，其中空間的裝修就可以理解爲是一個簡單的cms系統。

6.3交易中心

交易中心其實是一個技術的中間件，所有和銷售前端交互的系統都要通過交易中心來完成，此外還要承擔一些用戶主要交易流程當中的邏輯，舉例來說，下單之前需要先調用庫存服務，查詢庫存，用戶加入購物車之後，要通過調用營銷中台來計算購物車內商品活動後的總價等。

7、大中台

7.1商品中心

簡單來說，商品中心就是一個商品的數據庫，會在所有的業務系統當中都用得到，其來源包含第三方的和自主建立的。主要包含的有三層關系，第1層關系是類目，産品的類目分前台類目和後台類目可以在不同的渠道下自定義支持。第2層關系是spu和sku的關聯。第3層關系是屬性，屬性可以綁定在類目下，也可以綁定在spu下或者是sku下，子會繼承父的商品屬性，相關的文章也有很多，我的博客《從小賣鋪開始，聊聊商品和庫存模型》中也有大致介紹。

7.2營銷中台

營銷中台主要包含兩大塊，第1塊爲活動，第2塊爲優惠券碼。可以針對不同的用戶、産品、渠道進行優惠活動的設置，對于用戶感覺來說，優惠活動一般是在購物車當中呈現，而優惠券碼一般是在結算時扣除相應的金額，我的博客《非平台型營銷中台搭建全貌》一文中也有概述。

7.3庫存服務

庫存一般會分爲三級，渠道當前可售庫存、産品可售庫存、倉庫實際庫存。其解決的核心問題是，用戶從下單開始到最終扣除倉庫庫存，在不同環節應該如何去扣減，從而達到最高的庫存使用效率，我的博客《銷售庫存模型講解》一文中也有介紹。

7.4 WPS

WPS解決的核心問題是，商品應該如何調度。具體來看，當訂單接收之後，應該由哪個倉庫來進行滿足，用戶在商城界面看到是否有貨，應該如何判斷。我的博客《多倉模式下的分倉和拆單》一文中也有介紹。

7.5 Express

Express解決的問題是，當商品的發貨任務已經分到了具體的倉庫，我們應該使用哪一家的快遞，才能同時兼顧成本和速度。因爲在不同地區的倉庫，快遞公司的服務響應、成本是不一樣的。其核心邏輯是，對于不同的倉庫，在路線的配置上選取不同的快遞公司。

7.6會員中心

會員中心其實和我們玩王者榮耀的用戶等級很像，是對不同的渠道提取出共性的用戶升級規則，又或者是付費型會員。舉例來說，一個遊客用戶看到的商品價格是100元，當遊客登錄後，會發現用戶的會員等級是付費會員，此時前端頁面會調取商品中心當中的會員價格再呈現給用戶，此時用戶看到的商品價格是80元。

7.7發票中心

一般來說，業務發展到全球化的時候，才會誕生發票中心。因爲不同的國家才會對于開票的規範有不同的要求。其核心流程就是兩個，一個是開票，另一個是沖紅，但是在不同的業務下，可能對于開票和沖紅的時間點會有不同，這一點一般是由訂單中心來進行定義。

7.8客服服務

這一點比較好理解，一般客服系統的搭建現在分爲三大塊。第1塊是在線聊天客服，用戶發起的聊天會分配給系統後台的人工坐席。第2塊是智能知識庫，會將用戶所有的常見問題彙總到知識庫當中，給用戶自動推薦，從而減少人工客服的壓力。第3塊是客服的系統操作台，客服可以幫助用戶人工的幹擾一些訂單的進程，比如修改價格建立退換單等等。

7.9秒殺

由于中國用戶的數量衆多，特價商品的活動，幾乎都會用秒殺的方式來進行。故此秒殺已經成爲了各個中大型電商的基本服務，其核心邏輯就是在于多極緩存，逐級篩選用戶。

7.10風控

風控的應用場景其實有很多，這裏只談談下單場景的應用。如果我們判斷出一個高風險的訂單，這個訂單將會被系統給拒絕，一般我們會從兩個方面去判斷，一個是用戶曆史的行爲，一個是用戶當前的下單風險，前者來說，我們可以看用戶的賬號是否高風險，是否有比平常人更高的拒收率等等，後者來說一般是判斷用戶是否存在技術刷接口的可能性，比如判斷這個用戶在當前下單的時候，是否請求過于頻繁。

7.11結算

一般包含三個步驟，對賬清分和結算。將我們從第三方支付獲取的貨款進行自動結算，告知財務一個結果，從而打到供應商的賬戶當中，一般會和集團的OA審批流進行結合。

7.12數據中心

所有系統的數據都會共享給數據中心然後基于數據去進行各種場景的組合和應用。舉例來說最常見的是用戶畫像平台，運營人員需要通過用戶畫像平台去篩選出用戶的偏好，來進行精准營銷。舉例來說，當我們想主推一款手機殼的時候，運營人員可能先去篩選出最近30天購買過新手機、加購過手機殼、最近30天沒有購買過手機殼的用戶群ID，然後給這些用戶去發PUSH。

7.13訂單中心

所有渠道的訂單都必須彙聚到訂單中心，然後進行統一處理，舉例來說，我們的天貓店，淘寶店，抖音店，快手店以及自營電商平台，用戶提交的訂單都會彙聚到訂單中心，然後再進行下一步的流轉和操作。同時財務的結算也會以訂單中心的訂單狀態爲標准，這樣保障所有系統的上下遊數據都有一個通用的數據源。

8、大後台

8.1WMS

和某一個具體倉庫相關的所有業務流程都在wms管理，具體包含的業務流程有三個出庫，入庫和上架。出庫的類型有很多種，比如說電商訂單的類型就是購買出庫，當倉庫接收到出貨單以後會打印分揀單，倉庫員工會根據分揀單對于貨物進行揀貨、打包等操作，最後將打包完畢的商品放在出庫區等待承運商拉走。入庫的類型也有很多種，一般最常見的就是采購入庫。而商品上架則是需要先根據倉庫的庫位管理劃分很多的區域，然後再將不同的商品商家都不同的區域。

8.2XMS

XMS中文名稱叫售後管理系統，售後的類型有三種退換修，然而退換修需要有不同的備件庫，可能是更換零件進行維修，也可能是直接更換整機。如果是退貨的話，則需要在XMS當中判定用戶發回的貨是滿足退貨條件的，此時在XMS當中會告訴訂單中心，從而再觸發支付和結算業務的退款流程。

8.3用戶中心

用戶中心也就是存儲用戶基礎數據的地方，同時需要承擔用戶的注冊登錄找回密碼，更換手機號的相應流程，對于不同的國家，需要支持不同類型的注冊方式，比如手機號注冊和郵箱注冊或者是谷歌賬戶注冊，同時在技術方案上也要支持不同類型的前端産品，比如說支持Web、Webview、APP等。對于不同風險等級的業務，也要支持不同類型的注冊方式，比如只是電商業務的話，只需要手機號注冊即可，但如果是金融信貸業務，則還需要支持人臉識別或者是身份證認證等。

8.4 SRM

SRM的中文名爲供應商管理系統，核心邏輯是對于不同的供應商進行打分和評判，篩選初優質的供應商。同時對于詢價、采購、物流、財務等供應流程進行數據化管理。

摘自簡書。