2017雙11交易系統TMF2.0技術揭祕，實現全鏈路管理

摘要： 本文是《2017雙11交易系統TMF2.0技術揭祕》演講整理，主要講解了基於TMF2.0框架改造的交易平臺，經過業務管理域與運行域分離、業務與業務的隔離架構，大幅度提升了業務在可擴展性、研發效率以及可維護性問題，同時以更好的開放模式，讓業務方能自助進行無侵入的需求開發。

12月13-14日，由雲棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中爲你們分享了2017雙11背後的黑科技。本文是《2017雙11交易系統TMF2.0技術揭祕》演講整理，主要講解了基於TMF2.0框架改造的交易平臺，經過業務管理域與運行域分離、業務與業務的隔離架構，大幅度提升了業務在可擴展性、研發效率以及可維護性問題，同時以更好的開放模式，讓業務方能自助進行無侵入的需求開發。內容以下。

阿里巴巴資深技術專家 毗盧

毗盧，阿里巴巴資深技術專家，主導設計了TMF2.0框架，並基於該框架完成交易平臺架構升級改造，目前負責商品中心，專一電商領域業務建模與工程交付相結合的研究與平臺推廣。

交易平臺遇到的挑戰
在剛剛過去的2017雙11，交易峯值達到了32.5萬筆/秒，這給整個交易系統帶來了很是大的挑戰。一方面，系統須要支撐全集團幾十個事業部的全部交易類需求：要考慮如何能更快響應需求、加快發佈週期；如何能爲新小業務提供快速支撐、下降准入門檻；是否足夠開放使得業務方能作到自助式擴展；新需求是否已經在其餘事業部有可複用資產等問題。另外一方面，整個電商體系涉及的應用高達7000+：要考慮需求的評估是否具備全鏈路視角；業務需求的技術評估是否分析全面、技術方案的影響範圍是否評估到位；業務的全鏈路穩定性保障、調用鏈路監控、強弱依賴等問題。此外面對天天幾百個業務需求，500+個獨立的發佈變動：要考慮各業務方的需求發佈是否會相互產生影響；需求代碼是否對平臺有侵入、致使平臺腐化；高頻率的需求發佈下如何管控質量；可否按業務維度進行業務監控、故障分析等等。

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

業務可視化：平臺能力、業務規則決定是否對外透出；
需求結構化支持：基於透出的業務能力、已有的業務規則完成需求結構化分解下降溝通成本；
業務配置化：這是可視化的前提，要在需求明確的狀況下在線配置業務、快速發佈上線；
業務測試一體化：根據修改的代碼進行自動化用例篩選、自動化測試；
業務監控：以精細化的業務維度進行監控，而不只僅侷限於交易大盤；
故障排查：當業務故障時快速拿到故障快照、還原故障現場以及迅速定位問題緣由。
針對以上六大關鍵問題，TMF2.0的關鍵設計點有如下三個層面。

首先，須要實現業務/平臺分離插件化架構。平臺提供插件包註冊機制，實現業務方插件包在運行期的註冊。業務代碼只容許存在於插件包中，與平臺代碼嚴格分離。業務包的代碼配置庫也與平臺的代碼庫分離，經過二方包的方式，提供給容器加載。

其次，要統一業務身份。平臺須要能有按「業務身份」進行業務與業務之間邏輯隔離的能力，而不是傳統SPI架構不區分業務身份，簡單過濾的方式。如何設計這個業務身份，也成爲業務與業務之間隔離架構的關鍵。

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

下文將針對這三塊的內容分別展開來詳細介紹。

業務定製包與平臺分離的架構

如上所示的業務定製包與平臺分離架構能夠分爲四個層次。最底層是交易規範層，包括一些交易模型、交易領域的劃分、業務領域的劃分、以及交易啓動環境下的配置項。基於這個理論模型，就能夠進行一些定義及規範工做，好比接口定義、流程規範、模型規範等，並且其中的不少內容均可以在不一樣的領域進行復用。

上面一層是解決方案層。你們都知道阿里巴巴目前正在走國際化的戰略，因此面對不一樣的市場會構建不一樣的解決方案，不一樣的解決方案中也就有本身不一樣的業務玩法、業務邏輯。因此要將不一樣的市場解決方案和他們自身的流程、規則結合起來。可是這一過程當中會發現，不一樣的市場解決方案會有不少能夠複用的地方，好比營銷模式。因此造成的可複用基礎實現就能夠在不一樣的解決方案中獲得複用，所那麼在面對不一樣的市場時就不用考慮可複用基礎實現的內容，只須要關注市場相關的業務就能夠了。

往上一層是業務定製層。即便是在一個市場內，也會有各類細分的定製玩法，這些不一樣的細分點就會有各自不一樣的業務邏輯，這就是制定業務定製層的緣由。團隊會根據底層的需求點來進行一些業務定製包的組裝，就能夠實現不一樣的業務邏輯和玩法了。

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

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

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

業務管理域與運行域分離的框架

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

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

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

垂直維度，也可稱之爲「行業」。每每一個特定的「業務對象」（如商品），在靜態期就能確認其具體歸屬於哪一個行業。行業與行業之間的業務規則是不會有疊加的。好比，付款超時時間，各能夠都設置爲1天超時。但「天貓汽車」把超時時間改了，必定不會聯動改其餘業務的超時設置。橫向維度，也稱爲產品維度，特色有：產品是能夠被多個垂直業務所使用的、一個垂直業務是可使用多個產品的、產品是否生效是須要結合業務會話的。好比，「電子憑證」是否生效，要看用戶是否選擇了「電子憑證」的交付方式。

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

TMF 2.0的關鍵模型介紹
基於以上的業務域介紹，下面詳細闡述一下TMF 2.0的關鍵模型，主要包括業務配置主線和業務運行主線。

在業務配置主線中，由項目的業務PD來看一下當前業務涉及到哪些業務域，以及這些業務域下面有哪些功能和產品能夠去使用，哪些業務點是能夠去擴展的。這其中就須要能力域模型的支撐，經過這個模型所透出的結構化數據，來研究平臺中每一個域具有的能力、每一個能力具備的可變點，從而有針對性地進行設置。在配置模型裏，經過關鍵的視圖模板，進行模板透出，而後保存、下發配置數據到業務運行主線。業務配置主線和業務運行主線是相交互的。

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

在實際應用中，基於TMF2.0交易平臺改造效果具體以下：

業務需求平均開發週期縮短至12天。好比汽車4S服務中，在老系統上作了一個月（未完成），新系統7天完成；五道口業務中，在老系統中評估工做量兩個月，新系統12個工做日完成；餓了麼業務中，老系統評估要兩週，基於新系統2天完成。平臺與業務解耦。目前已完成的業務，其業務定製均只存在於業務包；在平臺未改動狀況下，業務方的發佈更加靈活（有屢次單業務發佈，不須要其餘業務方進行迴歸的案例）。業務資產庫。積累造成了50+業務資產庫，新業務可快速進行快速複製、調整併發布。