交易平台遇到的挑戰
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+業務資産庫，新業務可快速進行快速複制、調整并釋出。
原文釋出時間為：2018-03-6
本文作者：毗盧