近年來的數(shù)據(jù)中臺、業(yè)務(wù)中臺等系統(tǒng)架構(gòu)興起，大多數(shù)企業(yè)在不清楚的中臺背景的情況下就盲目追求，最后只會導(dǎo)致自身平臺丟失原有的優(yōu)勢框架。在這里，我們來總結(jié)下業(yè)務(wù)架構(gòu)總原則：大中臺+小前臺框架思維：

1、業(yè)務(wù)中臺系統(tǒng)采用領(lǐng)域驅(qū)動設(shè)計（DDD），在其上構(gòu)建業(yè)務(wù)能力SAAS，持續(xù)不斷進行迭代演進。

2、中臺平臺化定位，進行了業(yè)務(wù)隔離設(shè)計，方便一套系統(tǒng)支撐不同玩法的業(yè)務(wù)類型和便于定制化擴展。

3、前后端分離，通過服務(wù)接入層進行路由適配轉(zhuǎn)發(fā)。

4、天然的分庫分表，消息解耦和分布式緩存設(shè)計，支持彈性擴容，以支持業(yè)務(wù)中臺大數(shù)據(jù)高并發(fā)場景。

數(shù)商云為各位分別介紹每個部分。

電商中臺邏輯分布：

電商中臺部分在邏輯上分成了基礎(chǔ)能力和平臺產(chǎn)品兩層，這樣做的好處是，基礎(chǔ)能力層聚焦于穩(wěn)定收斂的業(yè)務(wù)模型和基礎(chǔ)服務(wù)本身，不會隨著業(yè)務(wù)和前臺產(chǎn)品的調(diào)整發(fā)生變化，可以簡單理解為業(yè)務(wù)模型的DAO。電子商務(wù)平臺產(chǎn)品層則專注于通過流程編排類的技術(shù)手段，將基礎(chǔ)能力構(gòu)建成業(yè)務(wù)的解決方案，解決共性和個性化的問題。我們將以交易的設(shè)計為例來說明這個分層理念。

通過對電商交易業(yè)務(wù)中臺系統(tǒng)的深入分析，可以確定幾乎所有的交易都會涉及下圖中所有的領(lǐng)域（庫存，優(yōu)惠，價格…），而單看每個域，玩法都是很少變化的，將這些域的基礎(chǔ)能力完全可以沉淀下來形成原子的基礎(chǔ)能力，通過擴展點方式應(yīng)對將來特殊的場景個性化擴展。

電商業(yè)務(wù)中臺系統(tǒng)產(chǎn)品層為了應(yīng)對不同的交易場景（一口價，拍賣，貨到付款，預(yù)售…）將原子的基礎(chǔ)能力編排成滿足不同場景的解決方案，以服務(wù)的方式透出出去。

業(yè)務(wù)中臺服務(wù)接入層：

業(yè)務(wù)服務(wù)中臺接入層是連接前臺產(chǎn)品和中臺產(chǎn)品層的紐帶，實質(zhì)就是之前的web應(yīng)用，不同的是現(xiàn)在前后端分離后，只包含java代碼，使用springBootweb。做參數(shù)轉(zhuǎn)換，路由分發(fā)，調(diào)用中臺服務(wù)，結(jié)果封裝。這塊需要做好前后端的交互規(guī)范，請求路由映射規(guī)范，web工程目錄結(jié)構(gòu)，負載均衡方案，跨越問題和安全問題。

公用基礎(chǔ)組件：

沉淀和抽象出通用獨立的公共基礎(chǔ)組件，這些組件在服務(wù)本項目，本團隊的同時，可以開源出去服務(wù)更多的人；抽幾個非常重要的組件講一下這么做的目的。

1、數(shù)據(jù)訪問組件：抽象封裝分庫分表訪問，讀寫分離，主備切換。

2、消息中間件組件：這塊的選擇非常多，就開源的就有activeMQ，RabbitMQ，RocketMQ，Kafka等等，如果不對這塊做封裝，對其上應(yīng)用做透明化處理，后期做這塊的適配調(diào)整就會非常痛苦，特別是這套業(yè)務(wù)中臺系統(tǒng)會在不同環(huán)境中進行部署時。

3、地址庫組件：統(tǒng)一地理地址相關(guān)的服務(wù)，如果是有拓展國際市場的需求，這塊會顯得的非常重要，不同文化背景的國家，在這塊的差異會非常大，同時國內(nèi)也涉及3級，4級和5級地址的問題。

云服務(wù)&設(shè)施容器層：

如果電商系統(tǒng)開發(fā)技術(shù)團隊不是非常大，又沒有較強的運維技術(shù)人員，建議不要購買物理機自己搭建環(huán)境，而是直接使用比較成熟的ECS和其他云服務(wù)，這樣會節(jié)省很多時間成本和一些耗時的運維工作，讓其專注于業(yè)務(wù)產(chǎn)品的研發(fā)，同時使用docker容器部署應(yīng)用，不僅需要的機器數(shù)量比較少而且部署非常便捷高效。

業(yè)務(wù)中臺的前臺產(chǎn)品：

ios，androidAPP，H5APP，PC站點，微信支付寶小程序都是屬于這層，前臺產(chǎn)品主要是根據(jù)業(yè)務(wù)形態(tài)和產(chǎn)品的定位來進行構(gòu)建。對于電子商務(wù)平臺業(yè)務(wù)來說，主要是指移動APP商城，H5商城，PC商城，小程序商城，這里將以小程序為例來說明：

為了適應(yīng)小程序，社交電商這樣的熱點，加上有這么優(yōu)秀的一套電商中臺系統(tǒng)，不搞出點有么有樣的電商前臺產(chǎn)品，不是很沒有道理，為此想破腦袋，我們把電商和送禮結(jié)合了起來，做了“禮尚往來”的小程序。

建立穩(wěn)定和安全保障的業(yè)務(wù)交易系統(tǒng)

對電商網(wǎng)站這類在線交易系統(tǒng)，流量會隨著運營活動的波動非常大，特別是到了雙11這類大活動的時候，流量的峰值會是平時的幾十~幾百倍，一些接口會放大的更大。核心電子商務(wù)平臺系統(tǒng)的指標(biāo)，流量，接口調(diào)用量和rt，以及限流和異常的監(jiān)控就顯得非常重要了。

在幾年之前，只有BAT幾個大的公司有能力在這方面做的不錯，隨著全民參與的這種大型促銷活動推動技術(shù)的進步，以及開源社區(qū)和一些大廠將類似方案回饋到開源社區(qū)，目前一個小的電商系統(tǒng)開發(fā)技術(shù)團隊做好這塊也沒有什么難度了?，F(xiàn)將總結(jié)的企業(yè)搭建商城系統(tǒng)用到的框架做個簡單的介紹，更多細節(jié)請參考官方文檔。

1、sentinel：是面向分布式服務(wù)架構(gòu)的輕量級流量控制產(chǎn)品，主要以流量為切入點，從流量控制、熔斷降級、系統(tǒng)負載保護等多個維度來幫助您保護服務(wù)的穩(wěn)定性。該電商系統(tǒng)已經(jīng)過阿里內(nèi)部雙11多年的驗證，穩(wěn)定性和可靠性非常不錯，已于最近開源。

2、dubbokeeper：dubbo的官方監(jiān)控dubbo-monitor-simple在性能上表現(xiàn)非常不好，經(jīng)常卡死，對比了幾個成熟的框架后，最終確定使用dubbokeeper.dubbokeeper社區(qū)版dubboadmin，包括了應(yīng)用管理，動態(tài)配置，統(tǒng)計信息，服務(wù)監(jiān)控和zk信息查看功能。

3、pinpoint：現(xiàn)在基于微服務(wù)的架構(gòu)，一個請求從用戶發(fā)起到響應(yīng)，中間調(diào)用鏈路非常長，跨越數(shù)十個系統(tǒng)很正常，并且路徑非常多，要定位一個比較耗時的響應(yīng)，不利用工具，是非常低效的。Pinpoint這樣的工具就是為處理這個問題出現(xiàn)的，Pinpoint的優(yōu)點是對代碼零侵入，運用JavaAgent字節(jié)碼增強技術(shù)，追蹤每個請求的完整調(diào)用鏈路。

4、Telegraf+influxDB+Grafana：主要用來實現(xiàn)業(yè)務(wù)數(shù)據(jù)的實時監(jiān)控方案，如交易額的不正常波動，訂單量的突然下跌等。Telegraf是收集數(shù)據(jù)的代理程序，可以根據(jù)業(yè)務(wù)需要添加插件擴展服務(wù)，收集到的數(shù)據(jù)寫入分布式時序數(shù)據(jù)庫influxDB，再通過grafana可視化的展示出來。

業(yè)務(wù)中臺系統(tǒng)工程結(jié)構(gòu)：

邏輯結(jié)構(gòu)映射到物理的工程結(jié)構(gòu)，每個邏輯單元對應(yīng)為一個子工程，如果是用idea開發(fā)，就是一個model，當(dāng)然model里邊會有子model；至于需要打包構(gòu)建多少個系統(tǒng)其決定性因素是你團隊的規(guī)模，如果團隊規(guī)模較少，業(yè)務(wù)中臺系統(tǒng)合并到3-4個左右就足夠了，如果團非常大，一個團隊負責(zé)一個業(yè)務(wù)板塊的，并為其構(gòu)建多個系統(tǒng)，也是非常正常的，像較大的電商公司，負責(zé)商品的就是一個團隊，商品相關(guān)的系統(tǒng)就有數(shù)10個。以業(yè)務(wù)交易系統(tǒng)為例，可以將交易的系統(tǒng)合并為一個系統(tǒng)，但在工程的組織結(jié)構(gòu)上是對立的，方便將來的拆分。

用業(yè)務(wù)中臺化框架來優(yōu)化電商交易系統(tǒng)優(yōu)勢

上面介紹了交易業(yè)務(wù)中臺的設(shè)計理念，本篇會詳細的來說為何要用中臺的思想來架構(gòu)交易系統(tǒng)。要說明白這個問題，我們必須回看業(yè)務(wù)中臺系統(tǒng)的演化路徑是怎樣隨著業(yè)務(wù)規(guī)模的增長進行變化的。

首先來看初創(chuàng)公司/新業(yè)務(wù)系統(tǒng)是如何演進的：以基于云計算為基礎(chǔ)的架構(gòu)模式，大部分的初創(chuàng)的交易系統(tǒng)架構(gòu)圖如下：

對于一個業(yè)務(wù)規(guī)模很小，業(yè)務(wù)也比較單一，該架構(gòu)也是最高效的方式，一到兩個web系統(tǒng)，數(shù)個微服務(wù)業(yè)務(wù)系統(tǒng)，一到兩個前臺系統(tǒng)。微服務(wù)業(yè)務(wù)系統(tǒng)將會把會員，商品，類目，店鋪，交易，庫存，物流這些劃分成不同的模塊/包放在一到幾個電商系統(tǒng)，這樣做的好處是非常明顯的，每個人都熟悉所有的代碼，代碼量不大，開發(fā)效率高，這在公司剛起步時，是非常接地氣的和最適合的架構(gòu)。

隨著電子商務(wù)平臺公司業(yè)務(wù)規(guī)模和組織的壯大，會基于上面的架構(gòu)，迭代演進N次，直到電商系統(tǒng)不再是制約公司發(fā)展的瓶頸，這期間最重要的架構(gòu)升級是電子商務(wù)系統(tǒng)和數(shù)據(jù)庫的垂直拆分，異步消息解耦，分布式事務(wù)機制，穩(wěn)定性保障。為了快速說明問題，我們將忽略中間演進版本，直通基于中臺的版本。

中臺系統(tǒng)產(chǎn)生背景

在介紹業(yè)務(wù)中臺模式之前，先來看看中臺概念的產(chǎn)生背景，中臺研發(fā)模式最早產(chǎn)生于芬蘭著名游戲公司supercell.Supercell有員工180人，后被騰訊以100億美金估值收購，其鼎峰時期全球排名top10的游戲，有5個來自supercell，其能快速推出高質(zhì)量的游戲，其大中臺功不可沒。阿里借鑒了supercell的“大中臺，小前臺”的模式，以解決快速創(chuàng)新試錯的前端業(yè)務(wù)和日益沉重的淘寶天貓這些核心系統(tǒng)之間的矛盾，以提升研發(fā)效率和跨團隊合作。

可以進一步的設(shè)想，如果一個電子商務(wù)網(wǎng)站公司業(yè)務(wù)高速發(fā)展，特別是互聯(lián)網(wǎng)的電商業(yè)務(wù)模式，出現(xiàn)10倍增速的發(fā)展也很正常，這會面臨業(yè)務(wù)和技術(shù)團隊規(guī)模變大，電子商務(wù)業(yè)務(wù)也會越來越復(fù)雜，就以交易為例，最初就是簡單支撐實物購買場景（消費者付款購買，平臺/商家發(fā)貨），隨著用戶和業(yè)務(wù)的發(fā)展，會出現(xiàn)，虛擬商品交易，團購，拼團，拍賣，秒殺，預(yù)售等等電商交易業(yè)務(wù)模式。

最初就是一個電商系統(tǒng)單純的支持一個單一的業(yè)務(wù)，到了階段二支持三個業(yè)務(wù)，你還能勉強活著，到了階段三如果還是使用之前的商城系統(tǒng)架構(gòu)和開發(fā)模式，你會陷入泥潭，在階段三必然會出現(xiàn)以下問題：

[if!supportLists]1.[endif]業(yè)務(wù)之間的電商需求相互影響，修改和測試回歸成本非常高，但還是會發(fā)生意想不到的線上問題。

[if!supportLists]2.[endif]由于支撐的商城需求越來越多，沒有人能掌控全局，修改無存下手，開發(fā)越來越不敢接需求。

[if!supportLists]3.[endif]多個網(wǎng)站需求并行的開發(fā)是場噩夢，團隊經(jīng)常加班，還是滿足不了業(yè)務(wù)需求的開發(fā)，團隊越來越是瓶頸，經(jīng)常接到業(yè)務(wù)方的投訴。

業(yè)務(wù)中臺化也就是解決這些問題的最佳選擇，將交易域的核心能力和服務(wù)，通過梳理抽象沉淀為穩(wěn)定外化的服務(wù)，通過預(yù)留的擴展點，來支持個性化擴展。擴展點的開發(fā)完全可以由業(yè)務(wù)系統(tǒng)開發(fā)團隊的技術(shù)來進行，交易中臺研發(fā)將專注于中臺的建設(shè)和穩(wěn)定性，這樣講大大改善開發(fā)協(xié)作效率，一個業(yè)務(wù)能不能跑的快，主要依賴于前臺，當(dāng)然業(yè)務(wù)中臺的技術(shù)團隊需要做好業(yè)務(wù)隔離和中臺本身的穩(wěn)定高效進化。

了解交易的一般業(yè)務(wù)流程，交易的兩個業(yè)務(wù)流程：

交易訂單創(chuàng)建流程

簡化的逆向退款流程

只舉例2個業(yè)務(wù)流程，其他的大同小異，對交易業(yè)務(wù)的分析和梳理，不難發(fā)現(xiàn)，交易涉及的業(yè)務(wù)域可以歸類為以下幾個方面：價格，優(yōu)惠，庫存，拆單，支付，限購，交付，訂單，超時，售后。

電子商務(wù)平臺交易業(yè)務(wù)中臺架構(gòu)

通過對電商網(wǎng)站交易業(yè)務(wù)流程和業(yè)務(wù)的分析和梳理，采用20/80原則，可以建模抽象出基礎(chǔ)能力層：

交易是很多契約的組合體，基礎(chǔ)能力服務(wù)是原子性的，還需要將這些通過流程編排組合成有業(yè)務(wù)價值的交易產(chǎn)品來統(tǒng)一對外輸出和管理，這就是電子商務(wù)交易平臺產(chǎn)品層的職責(zé)，解決共性和差異性的問題。

此外電商交易系統(tǒng)需要依賴會員，商品，店鋪，庫存，優(yōu)惠，支付和物流等這樣的業(yè)務(wù)服務(wù)才能完成一個真正的交易，加上這些我們基本可以確定交易的業(yè)務(wù)中臺架構(gòu)圖，如下：

有了整體的全局大圖，接下來我們將會按照如下的框架來詳細介紹每個部分。

業(yè)務(wù)中臺系統(tǒng)總體設(shè)計：

核心業(yè)務(wù)領(lǐng)域模型，領(lǐng)域模型的設(shè)計，還是遵守DDD的原則，這塊做的好壞，關(guān)鍵是對這塊業(yè)務(wù)的理解和未來一段時間的預(yù)判，加上抽象歸納。

中臺核心類圖：

從總體設(shè)計的角度看，總體的類圖應(yīng)當(dāng)是關(guān)注業(yè)務(wù)模型本身，按照之前約定，我們先看BA層的業(yè)務(wù)模型：

這個類圖，只畫了宏觀和重要的業(yè)務(wù)域類，其他用來支撐的類圖，將在BA層做展示，目前幫助理解交易這些類圖足夠說明問題，太多反而沒有重點。PA層是對外開放的服務(wù)層，按照慣例設(shè)計，會有與其DO對應(yīng)的DTO類，此外考慮到購車更多的是承擔(dān)前臺層的功能，BA層不會引入購車，而將其放到了PA層。

PA層的業(yè)務(wù)對象類圖，除了dto類型外，還增加了消息事件對象，用來將交易的業(yè)務(wù)變化通過事件消息通知給對其感興趣的訂閱方，要說明的一點是BA層的DO對象，PA層是完全可以使用的。

業(yè)務(wù)中臺系統(tǒng)核心服務(wù)設(shè)計：

服務(wù)接入層更多的是前后端交互restfulservice的設(shè)計，交易的PA層實質(zhì)上已經(jīng)做了對外開放的微服務(wù)設(shè)計（使用dubbo框架），服務(wù)接入層的restfulservice幾乎是對微服務(wù)進行包裝參數(shù)轉(zhuǎn)換的處理，就沒有必要單獨說明restful

service，直接看PA最重要的幾個服務(wù)。

核心鏈路時序設(shè)計：

通過最常規(guī)的下單購買和支付流程來說明交易的核心調(diào)用鏈路是怎么樣的過程，為了簡化說明下面的時序圖簡化了異常鏈路的處理過程和人為減少了依賴的業(yè)務(wù)中臺系統(tǒng)。進行核心鏈路依賴的設(shè)計，是為了在設(shè)計階段更好的去評估依賴的合理性，確保交易的性能，安全性和容災(zāi)處理方面的要求。有了核心調(diào)用鏈路圖，你才能在設(shè)計階段確定哪些調(diào)用是可以減少的，哪些地方可以異步處理，哪些地方可以使用前置緩存，哪些地方需要異步重試，哪些地方不能超時，哪些地方要確保最終一致性，哪些要做冪等處理等等，此外也對下游系統(tǒng)更好的評估自己的流量和響應(yīng)時間提供了參考依據(jù)。lw