我們提供的服務有：做網(wǎng)站、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、鼎城ssl等。為數(shù)千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的鼎城網(wǎng)站制作公司

| 本文出處：https://yq.aliyun.com/articles/511876

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

總體介紹

2017年雙11，交易峰值達到了32.5萬筆/秒，這給整個交易系統(tǒng)帶來了非常大的挑戰(zhàn)。一方面，系統(tǒng)需要支撐全集團幾十個事業(yè)部的所有交易類需求：要考慮如何能更快響應需求、加快發(fā)布周期；如何能為新小業(yè)務提供快速支撐、降低準入門檻；是否足夠開放使得業(yè)務方能做到自助式擴展；新需求是否已經(jīng)在其他事業(yè)部有可復用資產(chǎn)等問題。

互聯(lián)網(wǎng)的特點決定了業(yè)務系統(tǒng)是按領域服務建設的分布式架構(gòu)。而電商業(yè)務的特點是業(yè)務生命周期長，從招商、選品、供應鏈、倉儲、營銷/導購、下單、履約、物流、售后等，其業(yè)務鏈路長、業(yè)務邏輯上游對下游又有影響。在這業(yè)務主線的鏈路上，又建設了眾多系統(tǒng)進行支撐，比如商品平臺、購物車系統(tǒng)、下單系統(tǒng)、履約系統(tǒng)、優(yōu)惠系統(tǒng)、物流系統(tǒng)、供應鏈系統(tǒng)等，圍繞這些核心系統(tǒng)，還有數(shù)不清的輔助系統(tǒng)/服務，比如服務平臺、天貓SMC、淘寶CPC等等。

在每一次的業(yè)務需求分析過程中，又是需要能從業(yè)務生命周期的全鏈路視角進行需求分析、技術方案評估、編碼、聯(lián)調(diào)以及發(fā)布。這整個過程，也是一次復雜的跨團隊協(xié)助過程，痛點主要體現(xiàn)在：

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

2）平臺準入門檻高，新小業(yè)務無法快速試錯 

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

4）缺少可復用業(yè)務資產(chǎn)。

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

對業(yè)務需求的跟蹤與管理缺少全業(yè)務鏈路視角，主要體現(xiàn)在：

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

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

平臺能力缺少透出，技術方案評估花費時間長。技術同學在評估需求實現(xiàn)對平臺的改動點時，由于平臺能力缺少透出，業(yè)務與平臺代碼沒有分離，導致技術方案評估時，很難一下評估出針對新續(xù)期，現(xiàn)有平臺有什么能力可以服用？改動對現(xiàn)有哪些業(yè)務會有影響？對相關的周邊哪些系統(tǒng)有影響？工作量有多少？ 這些基本都需要事后去反復翻代碼分析評估。

類似需求重復建設。 需求發(fā)布上線后，隨著時間的推移，人員的更換。就沒有人知道這個需求當時是如何實現(xiàn)的？遇到類似需求的方案評估，又只能翻代碼，或者重復實現(xiàn)一次。

痛點二：平臺準入門檻高，新小業(yè)務無法快速試錯

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

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

2）與其他業(yè)務代碼在運行期分離，不希望對其他業(yè)務或者被其他業(yè)務所影響 

3）業(yè)務發(fā)布節(jié)奏可以自行控制，不希望等待每周一次的全網(wǎng)回歸

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

阿里電商業(yè)務五花八門，各部門的定位也不一樣，有的定位于是面向“垂直”行業(yè)的，比如天貓汽車業(yè)務、盒馬生鮮業(yè)務、航旅業(yè)務等；而有的又是定位于面向?qū)λ行袠I(yè)支撐的平臺業(yè)務，如聚劃算、導購寶等。 所以，業(yè)務本身會分成“垂直”和“水平”兩個維度。在一次業(yè)務交互過程中，其業(yè)務復雜度就在于業(yè)務“垂直”維度與“水平”維度產(chǎn)生的疊加，并由疊加而產(chǎn)生的業(yè)務規(guī)則上的沖突。

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

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

痛點四：缺少可復用業(yè)務資產(chǎn)

一個企業(yè)的IT體系建設是否成熟，業(yè)界是有一些指導框架來進行評估的，比如TOGAF框架。在該信息系統(tǒng)建設框架中，有一個很重要的系統(tǒng)成熟度評估項目 —— Enterprise Continumm（企業(yè)統(tǒng)一體）。

這里面的關鍵是企業(yè)需要建立：

架構(gòu)統(tǒng)一體（Architecture Continuum）： 該統(tǒng)一體能從特定架構(gòu)中提取出可復用的組件到倉庫中（Reposity），為后續(xù)的類似業(yè)務的重用（Gerneralization for future re-use）。在具體應用中，可以從組件倉庫中選擇可復用的組件并進行與實際應用場景適配（Adaptation for use）。

解決方案統(tǒng)一體（Solutions Continuum）：與架構(gòu)統(tǒng)一體類似，在面對不同的市場，需要能從可復用的解決方案庫中選擇并快速復制。對于新興市場的交付，也能提取成可復用的解決方案到資產(chǎn)庫中。

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

解決這些問題的思路

整個電商體系涉及的應用高達7000+：要考慮需求的評估是否具有全鏈路視角；業(yè)務需求的技術評估是否分析全面、技術方案的影響范圍是否評估到位；業(yè)務的全鏈路穩(wěn)定性保障、調(diào)用鏈路監(jiān)控、強弱依賴等問題。此外面對每天幾百個業(yè)務需求，500+個獨立的發(fā)布變更：要考慮各業(yè)務方的需求發(fā)布是否會相互產(chǎn)生影響；需求代碼是否對平臺有侵入、導致平臺腐化；高頻率的需求發(fā)布下如何管控質(zhì)量；能否按業(yè)務維度進行業(yè)務監(jiān)控、故障分析等等。

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

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

需求結(jié)構(gòu)化：基于透出的業(yè)務能力、已有的業(yè)務規(guī)則完成需求結(jié)構(gòu)化分解降低溝通成本。

業(yè)務配置化：這是可視化的前提，要在需求明確的情況下在線配置業(yè)務、快速發(fā)布上線。

業(yè)務測試一體化：根據(jù)修改的代碼進行自動化用例篩選、自動化測試。

業(yè)務監(jiān)控：以精細化的業(yè)務維度進行監(jiān)控，而不僅僅局限于交易大盤。

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

TMF2.0 關鍵設計思想

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

業(yè)務包與平臺分離的插件化架構(gòu)： 平臺提供插件包注冊機制，實現(xiàn)業(yè)務方插件包在運行期的注冊。業(yè)務代碼只允許存在于插件包中，與平臺代碼嚴格分離。業(yè)務包的代碼配置庫也與平臺的代碼庫分離，通過二方包的方式，提供給容器加載。

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

管理域與運行域分離： 業(yè)務邏輯不能依靠運行期動態(tài)計算，要能在靜態(tài)期進行定義并可視化呈現(xiàn)。業(yè)務定義中出現(xiàn)的規(guī)則疊加沖突，也在靜態(tài)器進行沖突決策。在運行期，嚴格按照靜態(tài)器定義的業(yè)務規(guī)則、沖突決策策略執(zhí)行。

業(yè)務包與平臺分離的插件化架構(gòu)

如上所示的業(yè)務定制包與平臺分離架構(gòu)可以分為三個層次。最底層是業(yè)務規(guī)范層，包括一些交易模型、交易領域的劃分、業(yè)務領域的劃分、以及交易啟動環(huán)境下的配置項。基于這個理論模型，就可以進行一些定義及規(guī)范工作，比如接口定義、流程規(guī)范、模型規(guī)范等，而且其中的很多內(nèi)容都可以在不同的領域進行復用。

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

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

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

全鏈路統(tǒng)一的業(yè)務身份

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

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

業(yè)務管理域與運行域分離

業(yè)務身份確定后就要進行業(yè)務定義，這其中就涉及管理域和運行域分離的問題。管理域就是指對業(yè)務生命周期、業(yè)務身份、業(yè)務對象進行定義，包括業(yè)務流程、業(yè)務管理等。這些操作完成之后就會將配置文件下發(fā)到，運行域上的各種平臺就會自動解析配置域所下發(fā)的配置文件，然后將配置文件解析成業(yè)務命令來執(zhí)行。

在上面所講的業(yè)務域中，一個核心的問題就是如何定義業(yè)務：核心三要素是業(yè)務身份、業(yè)務疊加關系、沖突決策，即基于業(yè)務協(xié)議標準定義業(yè)務，執(zhí)行單元按協(xié)議執(zhí)行業(yè)務邏輯。

在業(yè)務疊加關系中，業(yè)務的復雜度就在于業(yè)務規(guī)則在不同維度下產(chǎn)生的沖突。業(yè)務的復雜度可以分為兩個維度，一個是橫向維度，一個是垂直維度。

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

通過業(yè)務復雜度的分析，可以得出一個結(jié)論是：一次業(yè)務會話完整的規(guī)則=1個垂直業(yè)務規(guī)則集合+ N個水平業(yè)務規(guī)則集。所以在做業(yè)務定義和管理的時候，具體就是在管某一個垂直業(yè)務是和哪些橫向業(yè)務在疊加。在疊加之后產(chǎn)生的業(yè)務沖突又是怎么解決的？要基于這一點進行業(yè)務管理。這是比較關鍵的一點。

TMF2.0 關鍵模型介紹

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

在業(yè)務配置主線中，由項目的業(yè)務PD來看一下當前業(yè)務涉及到哪些業(yè)務域，以及這些業(yè)務域下面有哪些功能和產(chǎn)品可以去使用，哪些業(yè)務點是可以去擴展的。這其中就需要能力域模型的支撐，通過這個模型所透出的結(jié)構(gòu)化數(shù)據(jù)，來研究平臺中每個域具備的能力、每個能力具有的可變點，從而有針對性地進行設置。在配置模型里，通過關鍵的視圖模板，進行模板透出，然后保存、下發(fā)配置數(shù)據(jù)到業(yè)務運行主線。業(yè)務配置主線和業(yè)務運行主線是相交互的。

基于TMF 2.0關鍵模型，整個交易平臺實現(xiàn)了業(yè)務定義可視、可管、可配。業(yè)務定義可視化包括系統(tǒng)能力可視化、業(yè)務流程可視化、業(yè)務規(guī)則可視化、產(chǎn)品疊加可視化等；業(yè)務可配置，所見即所得的業(yè)務規(guī)則可配置能力，凡是基于TMF2標準構(gòu)建的系統(tǒng)均立刻可獲取業(yè)務可配置能力，不需做額外的開發(fā)；配置版本化，針對業(yè)務配置有完善的版本化管理機制，配置推送可實現(xiàn)按版本快速生效或者回退；業(yè)務多租戶管理，不同的業(yè)務系統(tǒng)之間可以通過租戶完全隔離的。不同的租戶有自己的數(shù)據(jù)空間，以及配置推送策略。

面向業(yè)務維度的運維 & 穩(wěn)定性保障

當業(yè)務與平臺分離并且具有業(yè)務身份的識別后，我們就可以從業(yè)務維度進行可靠性保障，主要有：1）按業(yè)務維度進行故障監(jiān)控 2）按業(yè)務維度分集群部署 3）按業(yè)務維度做穩(wěn)定性保障 等。

1) 按業(yè)務維度進行故障監(jiān)控

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

基于TMF2構(gòu)建的業(yè)務系統(tǒng)，因為有“業(yè)務身份”的標示，我們就可以將業(yè)務身份標示貫穿整個接口調(diào)用鏈路以及寫入日志中。并在各類監(jiān)控大盤中，可以針對業(yè)務維度進行分組展現(xiàn)。

2) 按業(yè)務維度分集群部署

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

基于TMF2構(gòu)建的業(yè)務系統(tǒng)，因為有“業(yè)務身份”的識別。我們就可以根據(jù)業(yè)務身份做前置路由。給不同的業(yè)務身份分配不同的集群，并按集群去分別部署業(yè)務。從物理的隔離，在滿足一些業(yè)務快速迭代發(fā)布的訴求下，還能保障業(yè)務的穩(wěn)定性。

3) 按業(yè)務維度做穩(wěn)定性保障

過去在沒有業(yè)務身份的識別下，在做性能優(yōu)化、大促保障時，是沒法按業(yè)務維度用不同的QoS策略進行差異化的大促保障。比如，無法按照業(yè)務維度進行流量分配進行限流、無法按照業(yè)務維度建立性能基線并進行性能劣化監(jiān)控等。業(yè)務平臺目前正在做的天秤項目，與過去單純監(jiān)控物理指標不一樣的地方，就是在于能按照業(yè)務進行場景化監(jiān)控。例如：

可以按業(yè)務維度建立各業(yè)務在各個調(diào)用場景下的性能基線，如RT、QPS等，一旦某次發(fā)布和預設基線有重大差異，就能快速找到性能劣化的業(yè)務并進行改進

• 可以按業(yè)務維度建立外部服務調(diào)用的強弱依賴關系，結(jié)合強弱依賴關系可制定全局以及業(yè)務維度的各種預案開關。

• 可以按全局或者業(yè)務維度，構(gòu)建全局調(diào)用鏈路監(jiān)控大盤。

交易平臺改造效果

業(yè)務需求平均開發(fā)周期縮短至12天: 比如汽車4S服務中，在老系統(tǒng)上做了一個月（未完成），新系統(tǒng)7天完成；五道口業(yè)務中，在老系統(tǒng)中評估工作量兩個月，新系統(tǒng)12個工作日完成；餓了么業(yè)務中，老系統(tǒng)評估要兩周，基于新系統(tǒng)2天完成。

平臺與業(yè)務解耦: 目前已完成的業(yè)務，其業(yè)務定制均只存在于業(yè)務包；在平臺未改動情況下，業(yè)務方的發(fā)布更加靈活（有多次單業(yè)務發(fā)布，不需要其他業(yè)務方進行回歸的案例）。

業(yè)務資產(chǎn)庫: 積累形成了50+業(yè)務資產(chǎn)庫，新業(yè)務可快速進行快速復制、調(diào)整并發(fā)布。

文章名稱：跳開DDD和中臺概念看阿里巴巴交易平臺的問題及解決思路
本文鏈接：http://jinyejixie.com/article12/gpsedc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供Google、外貿(mào)建站、建站公司、企業(yè)網(wǎng)站制作、品牌網(wǎng)站設計、App設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)