基於大中臺架構的電商業務中臺最佳實踐之一：業務中臺整體架構介紹

架構總原則：

1. 大中臺+小前臺的架構思路

2. 業務中臺採用領域驅動設計（DDD），在其上構建業務能力SAAS，持續不斷進行迭代演進。

3. 平臺化定位，進行了業務隔離設計，方便一套系統支撐不一樣玩法的業務類型和便於定製化擴展。

4. 先後端分離，經過服務接入層進行路由適配轉發。

5. 自然的分庫分表，消息解耦和分佈式緩存設計，支持彈性擴容，以支持大數據高併發場景。

系統邏輯架構圖：

接下來將分別介紹每一個部分。

電商中臺:

中臺部分在邏輯上分紅了基礎能力和平臺產品兩層，這樣作的好處是，基礎能力層聚焦於穩定收斂的業務模型和基礎服務自己，不會隨着業務和前臺產品的調整發生變化，能夠簡單理解爲業務模型的DAO。平臺產品層則專一於經過流程編排類的技術手段，將基礎能力構建成業務的解決方案，解決共性和個性化的問題。咱們將以交易的設計爲例來講明這個分層理念。經過對電商交易業務的深刻分析，

能夠肯定幾乎全部的交易都會涉及下圖中全部的領域（庫存，優惠，價格…），而單看每一個域，玩法都是不多變化的，將這些域的基礎能力徹底能夠沉澱下來造成原子的基礎能力，經過擴展點方式應對未來特殊的場景個性化擴展。

平臺產品層爲了應對不一樣的交易場景（一口價，拍賣，貨到付款，預售…）將原子的基礎能力編排成知足不一樣場景的解決方案，以服務的方式透出出去。

服務接入層：

服務接入層是鏈接前臺產品和中臺產品層的紐帶, 實質就是以前的web 應用，不一樣的是如今先後端分離後，只包含java 代碼，使用springBoot web。作參數轉換，路由分發，調用中臺服務，結果封裝。這塊須要作好先後端的交互規範，請求路由映射規範，web工程目錄結構，負載均衡方案，跨越問題和安全問題，

後續會有專題詳細介紹這塊。

公用基礎組件：

沉澱和抽象出通用獨立的公共基礎組件，這些組件在服務本項目，本團隊的同時，能夠開源出去服務更多的人； 抽幾個很是重要的組件講一下這麼作的目的。

數據訪問組件： 抽象封裝分庫分表訪問，讀寫分離，主備切換。

消息中間件組件：這塊的選擇很是多，就開源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等, 再加上阿里雲，AWS, 騰訊雲等提供的和對應的雲版本，會很是多，若是不對這塊作封裝，對其上應用作透明化處理，後期作這塊的適配調整就會很是痛苦，特別是這套系統會在不一樣環境中進行部署時。

地址庫組件： 統一地理地址相關的服務，若是是有拓展國際市場的需求，這塊會顯得的很是重要，不一樣文化背景的國家，在這塊的差別會很是大，同時國內也涉及3級，4級和5級地址的問題。

雲服務&設施容器層

若是技術團隊不是很是大，又沒有較強的運維技術人員，建議不要購買物理機本身搭建環境，而是直接使用阿里雲這些比較成熟的ECS和其餘雲服務，這樣會節省不少時間成本和一些耗時的運維工做，讓其專一於業務產品的研發，同時使用docker 容器部署應用，不只須要的機器數量比較少並且部署很是便捷高效。

業務前臺產品：

ios ,android APP , H5 APP ,PC 站點，微信支付寶小程序 都是屬於這層，前臺產品主要是根據業務形態和產品的定位來進行構建。對於電商業務來講，主要是指移動APP商城，H5商城，PC商城 ，小程序商城。將以小程序爲例來講明。

爲了適應小程序，社交電商這樣的熱點，加上有這麼優秀的一套電商中臺系統，不搞出點有麼有樣的電商前臺產品，不是很沒有道理，爲此想破腦殼，咱們把電商和送禮結合了起來，作了「禮尚往來」的小程序，下面是產品的截圖。

穩定和安全保障系統

對電商這類在線交易系統，流量會隨着運營活動的波動很是大，特別是到了雙11這類大活動的時候，流量的峯值會是平時的幾十~幾百倍，一些接口會放大的更大；核心系統的系統指標，流量，接口調用量和rt, 以及限流和異常的監控就顯得很是重要了。在幾年以前，只有BAT 幾個大的公司有能力在這方面作的不錯，隨着全民參與的這種大型促銷活動推進技術的進步，以及開源社區和一些大廠將相似方案回饋到開源社區，目前一個小的技術團隊作好這塊也沒有什麼難度了。現將咱們用到的框架作個簡單的介紹，更多細節請參考官方文檔。

sentinel:是面向分佈式服務架構的輕量級流量控制產品，主要以流量爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助您保護服務的穩定性。 該系統已通過阿里內部雙11多年的驗證，穩定性和可靠性很是不錯，已於最近開源。

dubbokeeper： dubbo的官方監控dubbo-monitor-simple 在性能上表現很是很差，常常卡死，對比了幾個成熟的框架後，最終肯定使用dubbokeeper. dubbokeeper社區版dubboadmin,包括了應用管理，動態配置，統計信息，服務監控和zk信息查看功能。

pinpoint: 如今基於微服務的架構，一個請求從用戶發起到響應，中間調用鏈路很是長，跨越數十個系統很正常，而且路徑很是多，要定位一個比較耗時的響應，不利用工具，是很是低效的。Pinpoint這樣的工具就是爲處理這個問題出現的，Pinpoint的優勢是對代碼零侵入，運用JavaAgent字節碼加強技術，追蹤每一個請求的完整調用鏈路。

Telegraf+ influxDB+ Grafana：主要用來實現業務數據的實時監控方案，如交易額的不正常波動，訂單量的忽然下跌等。Telegraf 是收集數據的代理程序，能夠根據業務須要添加插件擴展服務，收集到的數據寫入分佈式時序數據庫influxDB,再經過grafana 可視化的展現出來。

工程結構：

邏輯結構映射到物理的工程結構，每一個邏輯單元對應爲一個子工程，若是是用idea 開發，就是一個model, 固然model 裏邊會有子model；至於須要打包構建多少個系統其決定性因素是你團隊的規模，若是團隊規模較少，中臺系統合併到3-4個左右就足夠了，若是團很是大，一個團隊負責一個業務板塊的，併爲其構建多個系統，也是很是正常的，像較大的電商公司，負責商品的就是一個團隊，商品相關的系統就有數10個。以交易爲例，能夠將交易的系統合併爲一個系統，但在工程的組織結構上是對立的，方便未來的拆分。

此次先介紹這些總體框架，後面還會有陸續的文章推出，按照每一個部分一到多個專題介紹核心設計。對這塊有興趣的歡迎交流技術方案和產品玩法。

更多文章歡迎訪問 http://www.apexyun.com/

公衆號:銀河系1號

聯繫郵箱：public@space-explore.com(未經贊成，請勿轉載)