轉載：原文來自于https://www.shushangyun.com/article-3752.html
架構總原則：
大中台+小前台的架構思路
業務中台采用領域驅動設計（DDD），在其上建構業務能力SAAS，持續不斷進行疊代演進。
平台化定位，進行了業務隔離設計，友善一套系統支撐不同玩法的業務類型和便于定制化擴充。
前後端分離，通過服務接入層進行路由适配轉發。
天然的分庫分表，消息解耦和分布式緩存設計，支援彈性擴容，以支援大資料高并發場景。
系統邏輯架構圖：
接下來将分别介紹每個部分。
電商中台:
中台部分在邏輯上分成了基礎能力和平台産品兩層，這樣做的好處是，基礎能力層聚焦于穩定收斂的業務模型和基礎服務本身，不會随着業務和前台産品的調整發生變化，可以簡單了解為業務模型的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個。以交易為例，可以将交易的系統合并為一個系統，但在工程的組織結構上是對立的，友善将來的拆分。
為什麼要用業務中台化思想來架構交易系統
上面介紹了交易業務中台的設計理念，本篇會詳細的來說為何要用中台的思想來架構交易系統。要說明白這個問題，我們必須回看系統的演化路徑是怎樣随着業務規模的增長進行變化的。
首先來看初創公司/新業務系統是如何演進的；以基于雲計算為基礎的架構模式，大部分的初創的系統架構圖如下
對于一個業務規模很小，業務也比較單一，該架構也是最高效的方式，一到兩個web系統，數個微服務業務系統，一到兩個前台系統。微服務業務系統将會把會員，商品，類目，店鋪，交易，庫存，物流這些劃分成不同的子產品/包放在一到幾個系統，這樣做的好處是非常明顯的，每個人都熟悉所有的代碼，代碼量不大，開發效率高，這在公司剛起步時，是非常接地氣的和最适合的架構。
随着公司業務規模群組織的壯大，會基于上面的架構，疊代演進N次，直到系統不再是制約公司發展的瓶頸，這期間最重要的架構更新是系統和資料庫的垂直拆分，異步消息解耦，分布式事務機制，穩定性保障。為了快速說明問題，我們将忽略中間演進版本，直通基于中台的版本。
在介紹業務中台模式之前，先來看看中台概念的産生背景，中台研發模式最早産生于芬蘭著名遊戲公司supercell. Supercell有員工180人，後被騰訊以100億美金估值收購，其鼎峰時期全球排名top10的遊戲，有5個來自supercell, 其能快速推出高品質的遊戲，其大中台功不可沒。阿裡借鑒了supercell的“大中台，小前台”的模式，以解決快速創新試錯的前端業務和日益沉重的淘寶天貓這些核心系統之間的沖突，以提升研發效率和跨團隊合作。
可以進一步的設想，如果公司業務高速發展，特别是網際網路的業務模式，出現10倍增速的發展也很正常，這會面臨業務和技術團隊規模變大，業務也會越來越複雜，就以交易為例，最初就是簡單支撐實物購買場景（消費者付款購買，平台/商家發貨），随着使用者和業務的發展，會出現，虛拟商品交易，團購，拼團，拍賣，秒殺，預售等等交易業務模式。
最初就是一個系統單純的支援一個單一的業務，到了階段二支援三個業務，你還能勉強活着，到了階段三如果還是使用之前的架構和開發模式，你會陷入泥潭，在階段三必然會出現以下問題：
[if !supportLists]1.[endif]業務之間的需求互相影響，修改和測試回歸成本非常高，但還是會發生意想不到的線上問題。
[if !supportLists]2.[endif]由于支撐的需求越來越多，沒有人能掌控全局，修改無存下手，開發越來越不敢接需求。
[if !supportLists]3.[endif]多個需求并行的開發是場噩夢，團隊經常加班，還是滿足不了業務需求的開發，團隊越來越是瓶頸，經常接到業務方的投訴。
業務中台化也就是解決這些問題的最佳選擇，将交易域的核心能力和服務，通過梳理抽象沉澱為穩定外化的服務，通過預留的擴充點，來支援個性化擴充。擴充點的開發完全可以由業務團隊的技術來進行，交易中台研發将專注于中台的建設和穩定性，這樣講大大改善開發協作效率，一個業務能不能跑的快，主要依賴于前台，當然業務中台的技術團隊需要做好業務隔離和中台本身的穩定高效進化。
了解交易的一般業務流程
本篇是用來講交易的，結果扯了太多業務中台的東西，現在直奔交易，看看交易的兩個業務流程。
交易訂單建立流程：
簡化的逆向退款流程：
隻舉例2個業務流程，其他的大同小異，對交易業務的分析和梳理，不難發現，交易涉及的業務域可以歸類為以下幾個方面：價格，優惠，庫存，拆單，支付，限購，傳遞，訂單，逾時，售後。
交易業務中台架構
通過對交易業務流程和業務的分析和梳理，采用20/80原則，可以模組化抽象出基礎能力層
交易是很多契約的組合體，基礎能力服務是最原子性的，還需要将這些通過流程編排組合成有業務價值的交易産品來統一對外輸出和管理，這就是交易平台産品層的職責，解決共性和差異性的問題。
此外交易系統需要依賴會員，商品，店鋪，庫存，優惠，支付和物流等這樣的業務服務才能完成一個真正的交易，加上這些我們基本可以确定交易的業務中台架構圖，如下：
有了整體的全局大圖，接下來我們将會按照如下的架構來詳細介紹每個部分。
總體設計：
核心業務領域模型：
領域模型的設計，還是遵守DDD的原則，這塊做的好壞，關鍵是對這塊業務的了解和未來一段時間的預判，加上抽象歸納。
核心類圖：
從總體設計的角度看，總體的類圖應當是關注業務模型本身，按照之前約定，我們先看BA層的業務模型
這個類圖，隻畫了宏觀和重要的業務域類，其他用來支撐的類圖，将在BA層做展示，目前幫助了解交易這些類圖足夠說明問題，太多反而沒有重點。
PA層是對外開放的服務層，按照慣例設計，會有與其DO對應的DTO類，此外考慮到購車更多的是承擔前台層的功能，BA層不會引入購車，而将其放到了PA層。
PA層的業務對象類圖，除了dto 類型外，還增加了消息事件對象，用來将交易的業務變化通過事件消息通知給對其感興趣的訂閱方，要說明的一點是BA層的DO對象，PA層是完全可以使用的。
核心服務設計：
服務接入層更多的是前後端互動restful service的設計，交易的PA層實質上已經做了對外開放的微服務設計（使用dubbo架構），服務接入層的restful service幾乎是對微服務進行包裝參數轉換的處理，就沒有必要單獨說明restful
service，直接看PA 最重要的幾個服務。
核心鍊路時序設計：
通過最正常的下單購買和支付流程來說明交易的核心調用鍊路是怎麼樣的過程，為了簡化說明下面的時序圖簡化了異常鍊路的處理過程和人為減少了依賴的業務系統。進行核心鍊路依賴的設計，是為了在設計階段更好的去評估依賴的合理性，確定交易的性能，安全性和容災處理方面的要求。有了核心調用鍊路圖，你才能在設計階段确定哪些調用是可以減少的，哪些地方可以異步處理，哪些地方可以使用前置緩存，哪些地方需要異步重試，哪些地方不能逾時，哪些地方要確定最終一緻性，哪些要做幂等處理等等，此外也對下遊系統更好的評估自己的流量和響應時間提供了參考依據。
交易這塊的技術設計點非常多，分布式高并發系統遇到的經典技術問題，幾乎都在着有出現，限于篇幅，将通過接下來的一篇專題文章專門介紹。