跳開 DDD 和中臺概念看阿里巴巴交易平臺的問題及解決思路

| 本文出處：

作者Ryu Xin，原文標題《如何實現32.5萬筆/秒的交易峰值？阿里交易系統TMF2.0技術揭秘》，技術瑣話受權轉載。

總體介紹

2017年雙11，交易峰值達到了32.5萬筆/秒，這給整個交易系統帶來了非常大的挑戰。一方面，系統需要支撐全集團幾十個事業部的所有交易類需求：要考慮如何能更快響應需求、加快釋出週期；如何能為新小業務提供快速支撐、降低准入門檻；是否足夠開放使得業務方能做到自助式擴充套件；新需求是否已經在其他事業部有可複用資產等問題。

網際網路的特點決定了業務系統是按領域服務建設的分散式架構。而電商業務的特點是業務生命週期長，從招商、選品、供應鏈、倉儲、營銷/導購、下單、履約、物流、售後等，其業務鏈路長、業務邏輯上游對下游又有影響。在這業務主線的鏈路上，又建設了眾多系統進行支撐，比如商品平臺、購物車系統、下單系統、履約系統、優惠系統、物流系統、供應鏈系統等，圍繞這些核心系統，還有數不清的輔助系統/服務，比如服務平臺、天貓SMC、淘寶CPC等等。

在每一次的業務需求分析過程中，又是需要能從業務生命週期的全鏈路視角進行需求分析、技術方案評估、編碼、聯調以及釋出。這整個過程，也是一次複雜的跨團隊協助過程，痛點主要體現在：

1）缺少全鏈路視角的需求管理機制，協同效率低 

2）平臺准入門檻高，新小業務無法快速試錯 

3）業務與平臺沒有很好分離，無法支撐業務自助式（Self-Service）發展 

4）缺少可複用業務資產。

痛點一： 缺少業務全鏈路視角的需求管理機制，協同效率低

對業務需求的跟蹤與管理缺少全業務鏈路視角，主要體現在：

需求的描述往往就是一句話。詳細的需求描述基本都是靠後期的一些文件、郵件以及組織需求澄清會的形式進行講解。在講解時，會盡可能拉上能想得到的可能會相關的平臺開發同學，場面蔚為壯觀。

需求傳遞低效，需要反覆溝通。業務需求在建模與分解過程中，缺少有效傳遞載體和形式，不能準確無縫傳遞到開發，導致反覆溝通澄清與需求返工以及重複工作量。

平臺能力缺少透出，技術方案評估花費時間長。技術同學在評估需求實現對平臺的改動點時，由於平臺能力缺少透出，業務與平臺程式碼沒有分離，導致技術方案評估時，很難一下評估出針對新續期，現有平臺有什麼能力可以服用？改動對現有哪些業務會有影響？對相關的周邊哪些系統有影響？工作量有多少？ 這些基本都需要事後去反覆翻程式碼分析評估。

類似需求重複建設。 需求釋出上線後，隨著時間的推移，人員的更換。就沒有人知道這個需求當時是如何實現的？遇到類似需求的方案評估，又只能翻程式碼，或者重複實現一次。

痛點二：平臺准入門檻高，新小業務無法快速試錯

新小業務都有一個成長規律，在早期業務模式驗證階段，需要的玩法比較簡單，希望能頻繁的釋出快速試錯。但共享的交易平臺、商品平臺、營銷平臺等雖然能支援各種業務模式與營銷玩法。但對於新小業務而言，這些在早期並不適用，他們希望平臺能靈活裁剪，比如：

1）下單流程是否能裁剪成極簡流程，而不是必須走完整流程 

2）與其他業務程式碼在執行期分離，不希望對其他業務或者被其他業務所影響 

3）業務釋出節奏可以自行控制，不希望等待每週一次的全網迴歸

痛點三：業務與平臺沒有很好分離，無法支撐業務自助式（Self-Service）發展

阿里電商業務五花八門，各部門的定位也不一樣，有的定位於是面向“垂直”行業的，比如天貓汽車業務、盒馬生鮮業務、航旅業務等；而有的又是定位於面向對所有行業支撐的平臺業務，如聚划算、導購寶等。 所以，業務本身會分成“垂直”和“水平”兩個維度。在一次業務互動過程中，其業務複雜度就在於業務“垂直”維度與“水平”維度產生的疊加，並由疊加而產生的業務規則上的衝突。

針對業務疊加的處理，各系統基本上還是基於SPI擴充套件機制，這些SPI缺少按照業務維度進行組織與隔離。在業務種類少，不同業務在邏輯疊加度小的情況下還是可以在很大程度上解決業務可定製化、多樣化的問題。但隨著各類業務越來越多時，就會導致各類業務在同一個擴充套件點上的疊加效應越來越突出。其中最薄弱的點就是 SPI介面中是否需要執行的過濾方法（filter）的編寫。一旦過濾方法寫得不好，就可能會造成不該執行的邏輯被執行了，或者把後續本該執行的邏輯給跳過了。

在共享的各個平臺中，提供給業務方可擴充套件的SPI多達幾百個。一個業務的最終邏輯是否正確，就需要該業務確保這幾百個SPI決策樹中每個節點註冊的位置正確，過濾方法中的過濾條件正確，同時執行邏輯也必須確。不僅如此，本業務註冊的SPI都正確了，還需要其他的業務註冊的SPI也都是正確的，這最終導致了業務與業務之間高度耦合。這種耦合，又進一步導致了各業務方之間、業務方與平臺之間的大量聯調、整合與迴歸等配合工作，無法做到自助式的業務設計、開發與交付。

痛點四：缺少可複用業務資產

一個企業的IT體系建設是否成熟，業界是有一些指導框架來進行評估的，比如TOGAF框架。在該資訊系統建設框架中，有一個很重要的系統成熟度評估專案 —— Enterprise Continumm（企業統一體）。

這裡面的關鍵是企業需要建立：

架構統一體（Architecture Continuum）： 該統一體能從特定架構中提取出可複用的元件到倉庫中（Reposity），為後續的類似業務的重用（Gerneralization for future re-use）。在具體應用中，可以從元件倉庫中選擇可複用的元件並進行與實際應用場景適配（Adaptation for use）。

解決方案統一體（Solutions Continuum）：與架構統一體類似，在面對不同的市場，需要能從可複用的解決方案庫中選擇並快速複製。對於新興市場的交付，也能提取成可複用的解決方案到資產庫中。

經過多年的發展，我們在淘寶、天貓國內市場中，我們 有各種各樣的業務支撐工具與玩法，比如，電子憑證、預售、購物券、紅包等等，在面對國際化市場交付時，是否能做到業務模式的快速複用？

解決這些問題的思路

整個電商體系涉及的應用高達7000+：要考慮需求的評估是否具有全鏈路視角；業務需求的技術評估是否分析全面、技術方案的影響範圍是否評估到位；業務的全鏈路穩定性保障、呼叫鏈路監控、強弱依賴等問題。此外面對每天幾百個業務需求，500+個獨立的釋出變更：要考慮各業務方的需求釋出是否會相互產生影響；需求程式碼是否對平臺有侵入、導致平臺腐化；高頻率的需求釋出下如何管控質量；能否按業務維度進行業務監控、故障分析等等。

面對這些挑戰，TMF2.0框架需要解決的六大關鍵問題：

業務全鏈路可視：業務分析人員和技術人員能基於同一套業務語言以全鏈路視覺化方式進行需求討論、影響分析以及技術方案評估，在業務檢視上看到的規則就是實際在執行系統上執行的規則。在對大規模的業務交付支撐場景下，業務視覺化對於效率提升是非常必要的。

需求結構化：基於透出的業務能力、已有的業務規則完成需求結構化分解降低溝通成本。

業務配置化：這是視覺化的前提，要在需求明確的情況下線上配置業務、快速釋出上線。

業務測試一體化：根據修改的程式碼進行自動化用例篩選、自動化測試。

業務監控：以精細化的業務維度進行監控，而不僅僅侷限於交易大盤。

故障排查：當業務故障時快速拿到故障快照、還原故障現場以及迅速定位問題原因。

TMF2.0 關鍵設計思想

針對上面提到的問題，TMF2在架構設計上主要的思想是：

業務包與平臺分離的外掛化架構： 平臺提供外掛包序號產生器制，實現業務方外掛包在執行期的註冊。業務程式碼只允許存在於外掛包中，與平臺程式碼嚴格分離。業務包的程式碼配置庫也與平臺的程式碼庫分離，透過二方包的方式，提供給容器載入。

全鏈路統一的業務身份： 平臺需要能有按“業務身份”進行業務與業務之間邏輯隔離的能力，而不是傳統SPI架構不區分業務身份，簡單過濾的方式。如何設計這個業務身份，也成為業務間隔離架構的關鍵。

管理域與執行域分離： 業務邏輯不能依靠執行期動態計算，要能在靜態期進行定義並視覺化呈現。業務定義中出現的規則疊加衝突，也在靜態器進行衝突決策。在執行期，嚴格按照靜態器定義的業務規則、衝突決策策略執行。

業務包與平臺分離的外掛化架構

如上所示的業務定製包與平臺分離架構可以分為三個層次。最底層是業務規範層，包括一些交易模型、交易領域的劃分、業務領域的劃分、以及交易啟動環境下的配置項。基於這個理論模型，就可以進行一些定義及規範工作，比如介面定義、流程規範、模型規範等，而且其中的很多內容都可以在不同的領域進行復用。

業務規範層之上是解決方案層。大家都知道阿里巴巴目前正在走國際化的戰略，所以面對不同的市場會構建不同的解決方案，不同的解決方案中也就有自己不同的業務玩法、業務邏輯。所以要將不同的市場解決方案和他們自身的流程、規則結合起來。但是這一過程中會發現，不同的市場解決方案會有很多可以複用的地方，比如營銷模式。所以形成的可複用基礎實現就可以在不同的解決方案中得到複用，所那麼在面對不同的市場時就不用考慮可複用基礎實現的內容，只需要關注市場相關的業務就可以了。

再往上一層是業務定製層。即使是在一個市場內，也會有各種細分的定製玩法，這些不同的細分點就會有各自不同的業務邏輯，這就是制定業務定製層的原因。團隊會根據底層的需求點來進行一些業務定製包的組裝，就可以實現不同的業務邏輯和玩法了。

在這樣一個複雜的分離架構中，最重要的是要將不同層次間的職責劃分清晰，整個程式碼都嚴格地、有意識地進行分離。所以在最後的部署過程中，首先要完成底層業務的複用，然後形成不同市場的解決方案，再在解決方案下對不同的業務實現差異化的點。

全鏈路統一的業務身份

上面所講的是業務和平臺的分離，在業務和平臺分離之後就要進行業務和業務之間的隔離，即統一的業務身份，類似於身份證號碼，在整個交易鏈路上必須是唯一的。業務身份需要透過人、貨、場三個維度進行抽象，比如市場型別、垂直市場、渠道來源等等，確定了這個唯一的業務身份後就可以將業務流程和業務規則進行關聯。

基於業務識別，團隊也提供了一個基於UIL的業務身份識別方案，總體設計基於標準模型來抽象，自定義語法，統一管理模型。事實上，透過樣品模型、買家模型、賣家模型、類目模型這四個維度，99%的商品都可以有效地進行標識。業務身份確定後，就可以按照業務身份維度，對業務配置、部署進行統一管理，在這其中要注意配置隔離性、熱部署、配置回滾、配置確定性等核心要素。

業務管理域與執行域分離

業務身份確定後就要進行業務定義，這其中就涉及管理域和執行域分離的問題。管理域就是指對業務生命週期、業務身份、業務物件進行定義，包括業務流程、業務管理等。這些操作完成之後就會將配置檔案下發到，執行域上的各種平臺就會自動解析配置域所下發的配置檔案，然後將配置檔案解析成業務命令來執行。

在上面所講的業務域中，一個核心的問題就是如何定義業務：核心三要素是業務身份、業務疊加關係、衝突決策，即基於業務協議標準定義業務，執行單元按協議執行業務邏輯。

在業務疊加關係中，業務的複雜度就在於業務規則在不同維度下產生的衝突。業務的複雜度可以分為兩個維度，一個是橫向維度，一個是垂直維度。

垂直維度，也可稱之為“行業”。往往一個特定的“業務物件”（如商品），在靜態期就能確認其具體歸屬於哪個行業。行業與行業之間的業務規則是不會有疊加的。比如，付款超時時間，各可以設定為1天超時。但“天貓汽車”把超時時間改了，一定不會聯動改其他業務的超時設定。橫向維度，也稱為產品維度，特點有：產品是可以被多個垂直業務所使用的、一個垂直業務是可以使用多個產品的、產品是否生效是需要結合業務會話的。比如，“電子憑證”是否生效，要看使用者是否選擇了“電子憑證”的交付方式。

透過業務複雜度的分析，可以得出一個結論是：一次業務會話完整的規則=1個垂直業務規則集合+ N個水平業務規則集。所以在做業務定義和管理的時候，具體就是在管某一個垂直業務是和哪些橫向業務在疊加。在疊加之後產生的業務衝突又是怎麼解決的？要基於這一點進行業務管理。這是比較關鍵的一點。

TMF2.0 關鍵模型介紹

下面詳細闡述一下TMF 2.0的關鍵模型，主要包括業務配置主線和業務執行主線。

在業務配置主線中，由專案的業務PD來看一下當前業務涉及到哪些業務域，以及這些業務域下面有哪些功能和產品可以去使用，哪些業務點是可以去擴充套件的。這其中就需要能力域模型的支撐，透過這個模型所透出的結構化資料，來研究平臺中每個域具備的能力、每個能力具有的可變點，從而有針對性地進行設定。在配置模型裡，透過關鍵的檢視模板，進行模板透出，然後儲存、下發配置資料到業務執行主線。業務配置主線和業務執行主線是相互動的。

基於TMF 2.0關鍵模型，整個交易平臺實現了業務定義可視、可管、可配。業務定義視覺化包括系統能力視覺化、業務流程視覺化、業務規則視覺化、產品疊加視覺化等；業務可配置，所見即所得的業務規則可配置能力，凡是基於TMF2標準構建的系統均立刻可獲取業務可配置能力，不需做額外的開發；配置版本化，針對業務配置有完善的版本化管理機制，配置推送可實現按版本快速生效或者回退；業務多租戶管理，不同的業務系統之間可以透過租戶完全隔離的。不同的租戶有自己的資料空間，以及配置推送策略。

面向業務維度的運維 & 穩定性保障

當業務與平臺分離並且具有業務身份的識別後，我們就可以從業務維度進行可靠性保障，主要有：1）按業務維度進行故障監控 2）按業務維度分叢集部署 3）按業務維度做穩定性保障 等。

1) 按業務維度進行故障監控

在過去沒有做到業務身份識別時，每天的交易大盤監控還比較粗放，只能去從整體去監控交易量趨勢。有些業務，特別是一些新小業務，其早期交易量非常小。即使因為故障交易跌零了，從交易大盤上也無法即使監控到，只有等到客戶投訴了才發現有故障發生。

基於TMF2構建的業務系統，因為有“業務身份”的標示，我們就可以將業務身份標示貫穿整個介面呼叫鏈路以及寫入日誌中。並在各類監控大盤中，可以針對業務維度進行分組展現。

2) 按業務維度分叢集部署

過去淘寶、天貓所有的交易，都是透過同一套BUY、TP進行下單並履約的。當某個業務有新需求或者故障解決等原因，要進行升級部署時，就不可避免的將所有機器都分批進行升級部署。每一次升級釋出，都是一次變更行為，只要有變更就可能會產生新的故障。

基於TMF2構建的業務系統，因為有“業務身份”的識別。我們就可以根據業務身份做前置路由。給不同的業務身份分配不同的叢集，並按叢集去分別部署業務。從物理的隔離，在滿足一些業務快速迭代釋出的訴求下，還能保障業務的穩定性。

3) 按業務維度做穩定性保障

過去在沒有業務身份的識別下，在做效能最佳化、大促保障時，是沒法按業務維度用不同的QoS策略進行差異化的大促保障。比如，無法按照業務維度進行流量分配進行限流、無法按照業務維度建立效能基線並進行效能劣化監控等。業務平臺目前正在做的天秤專案，與過去單純監控物理指標不一樣的地方，就是在於能按照業務進行場景化監控。例如：

可以按業務維度建立各業務在各個呼叫場景下的效能基線，如RT、QPS等，一旦某次釋出和預設基線有重大差異，就能快速找到效能劣化的業務並進行改進

• 可以按業務維度建立外部服務呼叫的強弱依賴關係，結合強弱依賴關係可制定全域性以及業務維度的各種預案開關。

• 可以按全域性或者業務維度，構建全域性呼叫鏈路監控大盤。

交易平臺改造效果

業務需求平均開發週期縮短至12天: 比如汽車4S服務中，在老系統上做了一個月（未完成），新系統7天完成；五道口業務中，在老系統中評估工作量兩個月，新系統12個工作日完成；餓了麼業務中，老系統評估要兩週，基於新系統2天完成。

平臺與業務解耦: 目前已完成的業務，其業務定製均只存在於業務包；在平臺未改動情況下，業務方的釋出更加靈活（有多次單業務釋出，不需要其他業務方進行迴歸的案例）。

業務資產庫: 積累形成了50+業務資產庫，新業務可快速進行快速複製、調整併發布。