基於大中臺架構的電商業務中臺最佳實踐之二：交易業務中臺核心設計

時間 2019-11-16

原文原文鏈接

爲何要用業務中臺化思想來架構交易系統

上一篇文章已經簡要介紹了交易業務中臺的設計理念，本篇會詳細的來講爲什麼要用中臺的思想來架構交易系統。要說明白這個問題，咱們必須回看系統的演化路徑是怎樣隨着業務規模的增加進行變化的。前端

首先來看初創公司/新業務系統是如何演進的；以基於雲計算爲基礎的架構模式，大部分的初創的系統架構圖以下web

對於一個業務規模很小，業務也比較單一，該架構也是最高效的方式，一到兩個web系統，數個微服務業務系統，一到兩個前臺系統。微服務業務系統將會把會員，商品，類目，店鋪，交易，庫存，物流這些劃分紅不一樣的模塊/包放在一到幾個系統，這樣作的好處是很是明顯的，每一個人都熟悉全部的代碼，代碼量不大，開發效率高，這在公司剛起步時，是很是接地氣的和最適合的架構。數據庫

隨着公司業務規模和組織的壯大，會基於上面的架構，迭代演進N次，直到系統再也不是制約公司發展的瓶頸，這期間最重要的架構升級是系統和數據庫的垂直拆分，異步消息解耦，分佈式事務機制，穩定性保障。爲了快速說明問題，咱們將忽略中間演進版本，直通基於中臺的版本。後端

在介紹業務中臺模式以前，先來看看中臺概念的產生背景，中臺研發模式最先產生於芬蘭著名遊戲公司supercell. Supercell有員工180人，後被騰訊以100億美金估值收購，其鼎峯時期全球排名top10的遊戲，有5個來自supercell, 其能快速推出高質量的遊戲，其大中臺功不可沒。阿里借鑑了supercell的「大中臺，小前臺」的模式，以解決快速創新試錯的前端業務和日益沉重的淘寶天貓這些核心系統之間的矛盾，以提高研發效率和跨團隊合做。緩存

能夠進一步的設想，若是公司業務高速發展，特別是互聯網的業務模式，出現10倍增速的發展也很正常，這會面臨業務和技術團隊規模變大，業務也會愈來愈複雜，就以交易爲例，最初就是簡單支撐實物購買場景（消費者付款購買，平臺/商家發貨），隨着用戶和業務的發展，會出現，虛擬商品交易，團購，拼團，拍賣，秒殺，預售等等交易業務模式。安全

最初就是一個系統單純的支持一個單一的業務，到了階段二支持三個業務，你還能勉強活着，到了階段三若是仍是使用以前的架構和開發模式，你會陷入泥潭，在階段三必然會出現如下問題：restful

[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 最重要的幾個服務。

核心鏈路時序設計：

經過最常規的下單購買和支付流程來講明交易的核心調用鏈路是怎麼樣的過程，爲了簡化說明下面的時序圖簡化了異常鏈路的處理過程和人爲減小了依賴的業務系統。進行核心鏈路依賴的設計，是爲了在設計階段更好的去評估依賴的合理性，確保交易的性能，安全性和容災處理方面的要求。有了核心調用鏈路圖，你才能在設計階段肯定哪些調用是能夠減小的，哪些地方能夠異步處理，哪些地方可使用前置緩存，哪些地方須要異步重試，哪些地方不能超時，哪些地方要確保最終一致性，哪些要作冪等處理等等，此外也對下游系統更好的評估本身的流量和響應時間提供了參考依據。