基於“大中臺，小前臺”思想構建的電商系統總體架構設計介紹
架構總原則：
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個。以交易為例，可以將交易的系統合併為一個系統，但在工程的組織結構上是對立的，方便將來的拆分。
這次先介紹這些整體框架，後面還會有陸續的文章推出，按照每個部分一到多個專題介紹核心設計。對這塊有興趣的歡迎交流技術方案和產品玩法。
聯絡郵箱：[email protected]
(未經同意，請勿轉載)