近幾年來中臺的概念開始被廣泛討論，電商企業要不要採用中臺的架構？有從戰略角度考量的，也有從業務需求角度考量的。Javashop的客戶之中也有搭建中臺的需求，總結我們爲客戶落地電商中臺系統的經驗，在這裏分享給大家。
一、大型企業電商面臨的問題點是什麼
1．跨領域性
大型企業一般業務覆蓋廣泛，子業務橫跨多領域，導致業務模型的共性和差異化並存。跨領域導致從操作體驗到流程變得繁雜，在電商落地中要梳理清楚每個子業務，並進行抽象，落實到軟件需求。
2．一箇中心
很多集團型企業在面對繁雜子業務的時候，需要一箇中心、一套規範來進行整合系統。做到數據中心化、核心業務中心化、接口中心化，規範的統一實現功能的複用，提高效率降低成本。
3．多端多觸點
緊隨互聯網時代的步伐，實現微信H5/小程序/App/Pc多端支持，組合支撐企業業務發展。
4．靈活運維
電商營銷運維本身要求靈活多變，且企業落地電商業務可能非原有熟悉領域,運維團隊需要不斷嘗試“新玩法”，這要求系統可以快速響應變化，實現敏捷變更。
二、如何助力企業電商落地
推動企業電商落地我們從以下三點出發：
1．Javashop電商中臺抽象出業務中臺，涵蓋用戶中心、商品中心、訂單中心、營銷中心、售後中心、支付中心。業務中臺對企業內部暴漏統一的標準服務接口，通過消息總線子業務實現各自的訂單業務流轉。
2．Javashop電商中臺的前後端分離式架構，允許前端靈活點接入業務中臺，統一的用戶中心使得前端複用業務中臺能力，達到靈活響應、快速實現的目的。
3．業務中臺使得企業可以快速、重複的使用電商系統標準、基本的能力，又可以滿足各個子業務部門個性化的需求，即允許子部門“各自爲戰”、又可以形成統一的數據、業務中心。
三、Javashop中臺總體架構
-
基礎設施
目前大型企業都有自己的paas平臺，或自己搭建、或購買的私有云產品（如騰訊、阿里、青雲等）。
-
電商平臺
在基礎設施之上我們提供了一套標準的電商中臺，包含用戶中心、商品中心、訂單中心、營銷中心、售後中心、支付中心，提供了通用的電商業務能力支撐，如創建訂單、支付等。
-
根據業務抽象的多端多觸點
Javashop提供了一套標準的電商前端支撐：PC、WAP、小程序、APP，這部分是通用的電商邏輯，客戶會根據自己業務情況定製前端，提供個性化的功能、交互體驗等，這些個性化是來源於企業內部個性化的需求。
四、中臺落地預覽
我們以個性化的票務子業務爲例，說明基於中臺業務的落地。如上圖所示，根據子業務的需求（如票務）抽象出子業務前端的功能流程、操作體驗：
展示門票的有效期、座位情況等，點擊購買時直接轉入結算頁，並提供選座界面，點擊“確定購買”按鈕直接下單、支付。
對於商品名稱、相冊等通用信息展示，前端通過調用“中臺核心api”實現，這部分api是中臺提供的，現成的，不用開發，只需要前端適配api即可。
對於有效期、座位情況的個性化需求，需要子業務的api提供，這部分是子業務需要開發提供的api，然後又子業務前端整合。
同樣地，訂單的創建、支付如果中臺的通用api不能滿足，也需要子業務調用核心api來共同完成。
下面我們以常見的訂單創建和支付爲例介紹一下常見的幾個中心：會員中心、商品中心、訂單中心和支付中心
會員中心
核心需求是要解決集團型企業用戶來源的多樣性，比如線下渠道、非電商用戶、OA用戶、erp用戶等等。用戶中心要解決這些用戶方便的接入電商系統，方便的進行sso（統一認證）的改造，甚至可以形成整個集團的用戶中心。
-
統一的註冊api
可提供子業務或其他系統調用
-
統一的身份驗證機制
基於token式的身份認證，方便其他系統接入以及sso的實現
商品中心
核心需求是統一的商品存儲和管理，方便子業務取用商品數據（庫存、索引等）。
-
商品基礎api
可提供子業務存取商品的基本信息（商品名稱、相冊等）
-
sku api
可提供子業務存取商品的sku信息
-
庫存
可提供子業務對商品庫存的存取
訂單中心
-
統一的訂單創建接口，不依賴購物車，方便其他子業務調用。
-
訂單的查詢接口
-
訂單消息總線，提供訂單變化消息
支付中心
獨立的支付中心，統一支付接口
-
獨立的支付中心（配置、api)
-
面向賬單的支付體系
集團型企業子業務衆多，但需要有統一的支付中心，以便提供統一的參數配置、統一的收款臺，方便財務數據的管理。
下面我們以景區售票業務場景做爲一個子業務來說明支付中心的架構：
用戶到景區購票時，可能通過掃碼或人工等手段觸發景區子業務創建訂單操作，接下來子業務引導客戶到子業務的收款臺。
客戶點擊確認支付時，在子業務中檢測是否可以支付（如庫存鎖定是否成功等），如果可以支付，調用支付中心付款接口調起支付，支付中心要檢測此子業務的訂單號是否已經有支付賬單、金額是否一致，進而調用第三方支付接口形成調起支付的參數，返回給子業務、引導客戶付款。
客戶在收款臺完成支付操作，當第三方支付系統（支付寶、微信等）確認付款成功後會通知支付中心，支付中心會發出支付賬單狀態變更MQ消息通知子業務，子業務收到支付成功消息後出票（人工、機器等）。
當子業務發生退票時，調用支付中心退款接口將款項退給客戶，退款成功後會發出賬單變化消息通知子業務。
支付中心還有一個賬單狀態查詢接口供子業務查詢狀態使用。
總結
綜合以上我們的分享，Javashop中臺系統希望提供一種能夠滿足大中型企業的電商落地解決方案，近年來關於中臺的討論、爭論愈演愈烈，我們的看法是“適合自己的纔是做好的”，一定要從自己的業務模型出發，不能一味的追求“流行”，技術應該爲業務服務，中臺方式的架構的確一定程度上提供了技術的重用，提高了效率，但如果企業業務沒有足夠複雜，或者團隊對分佈式開發、服務式開發不夠了解，建議還是先不採用中臺式的方案，簡單的需求的話，傳統的、垂直的架構更快、更靈活，可能經過一段時間的發展，倒逼團隊更新架構，那時再服務化、中臺化也未嘗不可。歡迎大家在評論區中發表自己的看法。
易族智匯（javashop）原創文章