汽車之家10年系統架構演進與平臺化架構實踐

　　 一、前言

　　汽車之家電商系統誕生在2014年，成長於2016~2019年，並經歷多年雙11、818晚會的洪峰考驗，沉澱了穩定可靠、效能卓越的線上交易能力。隨著業務中臺的建設浪潮興起，2019年進入中臺化建設階段，輸出其在汽車電商領域五年沉澱的能力，助力汽車電商行業發展，加速企業數字化轉型！

　　 二、架構演進

　　這個部分主要講一下汽車之家電商系統的架構發展歷程，每個階段的業務狀況、技術挑戰和技術體系的應對策略。　　

　　1、起步階段

　　網際網路大環境在2011~2013年經過千團大戰、電商大戰‍[1]之後，電商業務已經成了網際網路流量變現除廣告模式外的另外一塊戰略高地。在2013年“雙十一”期間，汽車之家推出購車服務，將交易環節作為一個重要發展方向[2]。

　　在業務起步階段 對技術的要求就是快速迭代上線，驗證產品可行性。在滿足業務日常需求的同時，技術架構上的思考也未停止過。考慮到未來電商系統的可擴充套件性，參考業界阿里巴巴的技術體系，2014年開始研發技術棧也逐步從 .NET體系變成Java體系，並與2015年5月30日完成所有的應用切換，上線完整的線上網上購車平臺車商城。

　　2、微服務階段

　　隨著電商業務迅猛發展，技術人員的增加，到2016年技術團隊已經有了上百人。單體架構之痛迎面撲來，就以一個前臺的商城git專案而言，就幾乎近30個maven的子專案，遇上需求並行開發，經常出現程式碼的合併衝突、需求上線等待、線上慢SQL等問題，整個系統的開發效率和系統穩定性都變差了。　　

　　這個時候的系統支撐面臨巨大的挑戰，系統架構必須升級進化。我們開始做分散式戰略，把原來的單一系統拆分成多個高內聚，低耦合的中心化系統。也就是現在的使用者中心、商品中心、訂單中心、促銷中心、優惠券中心、商家中心，每個獨立的系統可以獨立設計、獨立接需求、獨立釋出，整個研發效率和系統穩定性都上了一個臺階。

　　在這個階段我們在技術上完成 支撐汽車電商百萬級商品系統[3]、訂單系統[4]、優惠券系統[5]構建，並完成了應用的全部上雲[6]、自動化測試平臺構建[7]。

　　同時在業務上探索了自營整車電商模式 、開放平臺模式、B2B2C模式、報價單模式、顧問模式、TPCC模式、平行進口車售賣等各種經營模式。

　　3、主資料階段

　　電商發展的速度實在太快了，到了2019年公司內已經有了多種線上交易模式，比如旅遊類、車品與後市場服務類、積分兌換類等。公司基於發展戰略決定搭建電商中臺，一方面為了集中公司優質的產品資源、運營資源，打造具有影響力的垂直類電商交易平臺，另一方面也是為了合理管控技術資源，實現電商系統的統一。在此背景之下，我所在的團隊承擔起了搭建電商中臺的任務，由於各個系統間的業務形態、技術架構差異很大，所以我們面臨的第一個問題就是用什麼方式能夠實現交易類系統的整合。

　　為此我們一方面開始熟悉不同業務場景下的交易系統的現狀，另一方面也在技術方案上進行著思考和討論。最終我們選擇了“以資料歸一為基礎，提供標準化中臺服務，從下層向上層逐個系統整合”的方案。　　

　　（1）資料歸一

　　資料是公司的核心資產，任何系統尤其是交易類系統，資料更是重中之重。主資料的建設一方面能夠統一資料模型，打破系統壁壘；另一方面也能夠透過集中的資料進行經營性資料分析，為業務決策提供依據，因此我們將主資料的建設作為了系統整合的第一步。

　　在交易流程中，最重要的資料集中在商家、商品、訂單、促銷活動這四個領域，我們結合公司交易場景的現狀，分別對這四個領域的主資料進行抽象，統一建模，儘可能的適配大多數的交易場景。

　　以下是訂單主資料核心資料模型結構的示意圖：　　

　　完成了統一的資料模型後，下一步就需要將現有的異構型資料匯入到主資料庫中，我們採用了讀取資料庫binlog（mysql、sqlserver）進行資料加工的方式完成初期的資料同步匯入，這也是對業務侵入最小、最快的實現方案。

　　（2）API標準化

　　完成了主資料建設，下一步我們便開始進行基於主資料的API標準化建設，API可以看做是系統的神經，高質量的API可以串聯起一個優質的系統，統一了API在一定程度上也就實現了系統的收口。

　　為此，我們遵循單一職責的原則，按照領域進行區分，明確邊界，做到所有底層API功能原子化，便於上游使用者靈活組裝API完成業務邏輯，同時統一API的引數結構和響應結果的結構，統一錯誤碼，基於API閘道器統一發布、呼叫，API的資料統計監控、降級、限流實現統一管控。

　　（3）API讀寫切換

　　有了標準化的API，自然需要讓業務方進行使用才能體現出API的價值，為了防止步子邁的太大，我們也是按照業務的重要性以及量級，採用讀寫分階段的方案逐個業務進行呼叫切換，看似很合理的步驟，在實際執行過程中也暴露了很多問題：

　　①在讀寫強依賴的場景，比如：使用者下單完成後馬上會跳轉到訂單詳情檢視訂單，這個時候在未完成寫API切換的時候，由於資料同步延遲會導致透過讀API讀取資料失敗，這時就沒有辦法按照先讀後寫分階段進行切換，最好的辦法是讀寫同時切換。

　　②對於業務切換影響最小的方式，當然是相容原介面的引數和返回結果，如果我們強加業務方按照我們標準的API進行切換，勢必給業務方帶來切換成本和不必要的負作用。

　　這個時候我們自然要從對方的角度出發做一些取捨。我們採用的方式是在標準API之上增加了一層適配層，用於新老協議的轉換，讓業務方只需要切換域名和請求的URL即可，其他邏輯不變，最大限度的做到對業務方友好。

　　③由於我們提供的底層API都是原子的，但在實際場景中，尤其是前後端分離的專案，前端是不大願意為了一個結果多次呼叫介面獲取，面對這種情況，我們也是在後端增加了一層門面層，基於底層原子API組合成滿足業務場景的API對外提供，對於差異化的介面邏輯做適度相容。

　　④讀寫切換不可能一蹴而就，在這個過程中勢必會存在主資料API和原業務API並存的場景，鑑於所有API的入口都將由我們統一提供，因此我們也是採用了路由的機制，透過路由層的location進行區分轉發，所有API做到對呼叫方的透明。

　　⑤在實際API切換的過程中，還有一種特殊的場景，因為最終要實現系統的整合，對於那些後續會被整合掉的功能強行做API切換其實也是一種資源的浪費，因此我們也是提前做了預判，可以適度的不做切換，等待功能整合後將整體功能進行切換。

　　（4）系統功能整合

　　在完成API讀寫切換之後，基於主資料的功能基本完成了聚合，此時就需要將通用功能進行系統化的統一，比如：統一的商家管理後臺、統一的運營後臺、統一的C端交易體驗等，系統層級的統一整合目的是為了給使用者一個統一的操作介面，體現平臺的專業性。

　　在系統整合的過程中，我們採用了“共性沉澱，差異取捨”的原則，對於那些通用的能力，比如：商品釋出、訂單列表等功能，我們會抽象出通用的能力，提供統一的單元化的操作介面，滿足各業務方的使用訴求。

　　對於業務方特有的功能，我們會建議業務方去實現，而對於那些目前還無法形成通用能力但未來有可能作為通用能力的功能，我們會按照MVP原則，用最快的方式實現小版本的上線，隨著業務的迭代不斷的實現功能沉澱。

　　在整個系統整合的過程中，必然會出現在整合原有系統功能的同時又有新需求的加入，面對這種場景，我們的採用的方式是新老系統同步開發，看似增加了成本，其實對於新系統的整合是有好處的，一方面能夠不影響業務的開展，不會因為技術性的整合對業務造成停滯，另一方面可以透過新老系統的對比，找出新系統可能存在的問題，這也會是驗證整合後的新系統功能的優秀途徑。

　　在完成絕大部分的系統整合工作之後，電商核心的交易鏈路已經可以跑通，並且線上上經歷了長時間的驗證，從商家入駐、商品釋出、商品展示、下單、支付、履約、售後，到最終的結算，期間遇到的問題也在一一化解。在這個階段我們完成了公司內3大交易系統的整合，並進行了電商平臺秒殺系統的架構升級[8]，優惠券系統的架構升級，支撐了2020-2021的818晚會、雙11、雙12等大型活動的秒殺、發券場景。另外我們也在積極探索領域驅動模型DDD的理論與業界實踐，並在發票總庫系統的重構中進行了落地實踐[9]，這也為後續的平臺化架構升級提供了技術支撐。

　　4、平臺化架構階段

　　在電商業務中臺繼續向業務的“逼近”過程中，系統的抽象和建設難度也成指數型增加，出現了一系列新問題：

　　（1）隨著建設中臺專案的結束，人員的撤離，電商業務中臺在整合這麼多業務線的邏輯之後，程式碼裡充斥著大量條件判斷，每次需求迭代的開發成本和測試迴歸成本都很高，如何隔離不同業務之間的邏輯，減少業務之間的耦合度呢？

　　（2）如何抽象出已接入電商業務中臺的多條業務線的共效能力，以避免重複建設呢？

　　（3）當新業務接入電商業務中臺，如何基於已有的能力和解決方案快速組裝上線，以支撐業務快速迭代創新？

　　（4） 如何能夠利用技術手段幫助產品運營日常工作提效呢？

　　綜上所述，電商業務中臺在建設過程中抽象業務線的共效能力以及共效能力的複用性設計與實現尤其重要，業務中臺要做到能力複用和靈活多變才能讓中臺建設在企業的發展過程中起到降本增效的效果。系統架構必須升級，這就進入了平臺化架構階段。

　　 三、平臺化架構實踐

　　什麼是平臺化架構？就是要把基礎能力跟每個業務方的特性業務拆分，要把業務和業務之間的邏輯進行隔離。平臺化最核心的是業務抽象建模和系統架構的開放性，業務抽象解決共性的80%問題，系統架構開放性解決20%的個性化問題。

　　在參考ThoughtWorks給出的《現代企業架構白皮書》的方案[10]以及業界的網際網路公司美團[11]、有贊[12]的中臺解決方案，我們給出了適合之家電商平臺的解決方案：透過領域驅動建模抽象出電商業務中臺多業務線的共效能力並預留擴充套件點，然後利用服務編排對共效能力進行組合。其原理如圖所示：

　　每一個在電商業務中臺執行的業務可以理解為：業務身份+業務流程+規則，業務流程透過流程服務編排來實現，擴充套件點透過擴充套件點機制來實現。在整個交易流程中B端的商家入駐、商品釋出相對通用，不同的業務的主要流程差別體現在訂單收單前以及支付後的訂單履約，這些流程往往都是需要定製化開發，為此整個解決方案核心在於訂單平臺化的架構設計。　　

　　如圖所示，整個訂單平臺化架構分為五層，從下往上依次是：

　　基礎設施層：提供儲存、訊息、RPC等中介軟體

　　基礎服務層：按域組織的基礎服務、域服務內針對不同業務的差異提供擴充套件點。

　　業務能力層：串聯不同域服務形成可供外部使用的業務能力，比如下單、支付等。

　　業務流程層：對業務能力進行編排、形成訂單交易流程、完成訂單交易過程。

　　業務層：制定業務身份、擴充套件點實現以及業務流程配置等，實現不同業務差異。

　　整個訂單平臺化架構升級實踐過程，總結為以下幾點：

　　1、業務身份化

　　業務身份的概念最早由阿里巴巴提出，業務平臺在對各業務同時提供服務時，需要能區分每一次業務服務請求的業務身份要素，以便提供差異化個性化的服務；因此需要對企業各業務的身份和特徵進行建模和區分，其產出即為業務身份。業務身份具有唯一性，業務身份類似於身份證號碼一樣，需要保證在整個業務中臺上必須是唯一的。

　　有了業務身份業務中臺就可以針對抽象這個業務流程和業務規則，並基於業務身份實現服務路由、業務監控。其次業務身份就類似SAAS系統中的租戶的概念，不同的業務方在中臺透過業務身份進行資料許可權隔離，這樣能保證各業務的運營只能看見自己業務部分的資料。

　　比如在汽車電商領域，業務身份我們透過人、貨、場三個維度進行抽象。人的維度有是否開通會員、是否是認證車主、開通了哪些增值服務等；貨的維度有商品型別（整車、實物商品、虛擬商品等），交付方式（核銷、兌換、4S店交付）等；場的維度有線上下單、線下下單、在哪個線上商城下單，在哪個交付店下單、商品投放渠道來源等。根據這些維度確定了唯一的業務身份後，每筆交易的業務流程就確定下來了。

　　2、服務編排化

　　電商業務中臺整體採用微服務架構、將整個電商系統拆分為商家中心、使用者中心、商品中心、促銷中心、交易中心、履約中心、售後中心。每個中心在邏輯上分成了帶有業務屬性的能力和不帶業務屬性的基礎能力兩層。基礎能力層關注領域模型的實體屬性、行為、事件，不會隨著業務的需求調整而發生變化，聚焦於行業共性行為、收斂業務模型，保障基礎服務的穩定性。帶有業務屬性的能力是在基礎能力層之上透過服務組合、流程編排之類的技術手段，構成面向業務的解決方案，完成業務共性到個性化的轉變。有兩種常見的做法如下：

　　其一是使用硬編碼來實現。隨著不同業務線的邏輯不斷增加，各個業務能力呼叫的基礎能力會變得盤根錯節，很難做到可配置、靈活化。當發生需求變更的時候，測試人員很難評估修改的影響範圍，迴歸測試的成本週期長，這樣很難真正做到敏捷開發、快速響應業務。

　　其二是使用服務編排。透過服務編排現有微服務進行服務組合服務，然後一次性的返回前臺需要的資訊。不同業務線的能力執行不同的流程，透過圖形化、XML、JSON的編排框架，即可以讓流程清晰，也可以遮蔽程式碼細節。

　　服務拆分的好處無需贅述，但是要實現業務價值，不是看單個服務的能力，而是要協調所有服務保證企業端到端業務流程的成功。業務中臺是企業業務的整合平臺，整合技術必須鬆散地耦合組成流程的應用程式和資源，否則流程的邏輯將被硬編碼到特定的技術平臺中，更改可能代價高昂，從而違背業務流程複用的整個目標。

　　（1）服務編排框架

　　在服務編排領域，已經有很多的工業界解決方案，我們參考了基於API閘道器的服務編排[13]，基於工作流系統的編排框架Flowable和Activiti[14]、基於微服務架構編排框架的Netflix Conductor[16]和Zeebe[17]。透過對技術原理進行分析，發現它們都存在某些程度上的不足，無法應用到電商業務中臺的服務編排，最終我們選用Apache Camel [18]做為服務編排的底層引擎進行二次封裝開發。Apache Camel 誕生於2007年，2009年前後成為Apache高階專案更名為Apache Camel，目前最新版本是3.0。Apache Camel的優點在於在釋出後十多年的時間裡，已經擁有三百多種擴充套件元件；擴充套件機制也極其方便和靈活；透過開箱即可用的優秀實踐來解決應用整合問題；它基於事件驅動的架構，有著良好的效能和吞吐量[19]。

　　以下是一個簡單的服務流程編排樣例：　　

　　業務中臺使用服務編排技術一方面可以將交易的能力自動識別出來作為元件視覺化的呈現，形成能力地圖；另一方面，基於這些基礎能力實現服務流程的編排，能夠透過拖拉拽的方式快速搭建出適合業務的全部或者部分交易流程，類似積木，複用基礎元件，靈活搭配，進而實現電商企業級能力的複用，節約開發成本，快速賦能業務的目標。

　　（2）擴充套件點框架

　　擴充套件點的全稱是Service Provider Interface，簡稱為SPI。是Java提供的一套用來載入和執行第三方擴充套件的介面實現類的機制，一般用在元件替換和框架擴充套件的場景。SPI將服務介面與服務實現分離以達到解耦、提升了應用程式的可擴充套件性。在程式設計中，模組之間採用面向介面程式設計而不做具體的實現類引用，透過動態載入實現類達到應用程式的外掛化。

　　COLA框架是阿里巴巴技術專家提出的一種應用架構的擴充套件點框架[20]。COLA框架的擴充套件是透過註解的方式來實現的，Extension擴充套件註解裡面使用用例（useCase）、業務（bizId）、場景（scenario）三個屬性用來標識身份。使用COLA框架的擴充套件點可以在程式碼層面支援不同業務身份的邏輯隔離，因為不同的邏輯分散在不同的實現類裡面，符合軟體設計的開閉原則。

　　COLA框架在應用Spring上下文初始化完畢階段，開始掃描帶有Extension註解的bean進行擴充套件點註冊，以Map的結構儲存，Key是useCase、bizId、scenario的字串拼接，value是該bean。

　　在執行時，透過業務身份定位擴充套件點實現類，然後執行擴充套件點實現的邏輯。定位擴充套件點實現的時候支援三層路由，首先會按照useCase+bizId+scenario找擴充套件點實現，如果沒有則按照useCase+bizId+scenario預設值查詢，如果還未找到則根據useCase+bizId預設值+scenario預設值查詢，具體原理如圖所示：　　

　　對於簡單的業務場景，對應用系統的高擴充套件性、業務隔離的非功能性要求並不多。但是隨著同一應用系統支撐的業務變多、業務場景變複雜，在架構層面需要提供統一的擴充套件解決方案，將變化的業務規則固化下來，這不僅有助於統一技術規範，還能減少硬編碼的IF-ELSE、策略模式等因開發人員水平不一致帶來的理解上覆雜度、規範上的一致性。

　　透過擴充套件點機制，業務中臺就可以從業務身份和框架層面實現對不同的業務的管理像SAAS管理租戶一樣管理業務，不同業務身份在不同場景下對預定義的擴充套件點進行擴充套件。阿里巴巴的業務中臺也正是基於擴充套件點的思想，實現的核心業務邏輯和技術細節的分離和解耦，共享事業部才能對集團內幾百條業務線進行支撐的。

　　（3）服務編排+擴充套件點應用舉例

　　在驗證功能後對電商交易系統的的場景進行了分類，首先選取使用者感知度小、即使出問題也對使用者影響最小的節點進行重構試用，如未支付訂單超時關閉、使用者取消訂單。

　　以使用者取消訂單場景為例，在修改前各業務的使用者取消訂單的邏輯為修改訂單狀態為已取消狀態然後執行同一個流程，流程的執行順序為硬編碼，虛擬碼如圖所示：　　

　　修改後根據各業務的特性的進行了精細編排，如二手車業務沒有使用優惠券的場景，那麼就不需要再有這個環節；在積分這個通用能力上，擴充套件的是萬里通積分。虛擬碼如圖所示：　　

　　旅行家業務線的的酒店、機票業務無傳統的商品庫存的概念，那麼就不再需要還商品庫存的操作，而是抽象一個新的通用能力：取消供應商訂單，並預置了取消酒店供應商訂單的擴充套件以及取消機票供應商訂單2個擴充套件點。虛擬碼如圖所示：　　

　　整個系統的應用效果明顯，主要體現在效能提升和人效提升。效能提升主要體現在系統的響應時間變短，在修改後取消訂單的介面的生產環境的TP99提升百分比約為30%。

　　人效提升方面主要體現在取消訂單增加新流程節點的測試所用的時間對比，在修改前，各業務流程之間的程式碼是耦合的，修改流程增加新節點需要對以前的各業務進行迴歸測試，修改後不需要進行各業務的迴歸測試。

　　3、業務配置化

　　在平臺化架構實踐中我們將那些影響業務流轉的核心配置統一提取出來，並按照業務身份進行屬性值的配置，確保整個交易流程鏈路的標準統一，減少對交易核心鏈路程式碼的頻繁修改，不同業務根據不同的屬性值在相同的交易流程中的不同節點進行靈活切換。

　　比如：商品是否自動推送到資源池、下單是否需要填寫身份證、支付成功是否推送線索、超過N天未確認收貨是否自動確認收貨完成等等，所有配置項均透過配置管理後臺進行統一維護。

　　此外，對於電商中臺中包括業務身份在內的所有後設資料，我們也透過配置管理後臺進行了統一的管理並提供統一的API對外提供查詢服務。

　　4、開發工具化

　　從業務和技術的多維度出發，針對日常工作中出現的常見業務問題或者技術問題，研發出各類實用便捷的小工具，實現工作效率的提升、問題的快速定位等效果，比如：訊息分發、檢索工具；商品優惠價格速算工具；商品展示價格比對監控工具；快取管理工具；一鍵降級工具等等。隨著大家工具化意識的不斷提升，這類小工具不斷的出現並彙集在一起，就構成了研發人員必不可少的工具箱。

　　5、資料視覺化

　　電商系統的效能指標、資源利用率指標、呼叫量等系統維度的指標透過公司雲平臺能夠實現統一的監控，對於業務資料同理，我們需要提供統一的業務資料視覺化工具，為業務方提供做相關決策的參照依據。

　　為此，我們採用實時+離線的方式開發了訂單視覺化大屏系統，透過這個系統能夠按照業務線、訂單狀態、區域等多個維度實時監控訂單量的變化情況。如果固定時間段內的訂單量波動超過了我們事先配置的閾值，還會傳送釘釘訊息及時通知業務方關注。　　

　　此外，對於離線資料，我們也是按照日、周、月從多個維度進行資料統計分析，最終會以郵件和辦公APP訊息的形式傳送給業務方，這些手段的目的都是為了實現電商資料的視覺化管理，為業務使用方提供更多便捷的工具對電商業務進行全方位的管控。　　

　　

　　6、知識沉澱

　　我所在的這個團隊在公司內部的電商領域是一個專業的團隊，多年來積累了很多技術以及產品運營層面的經驗。在整個電商中臺的建設過程中，我們也是將這些經驗以及日常問題的解決辦法，作為一種財富不斷的沉澱，以往都是採用wiki這種文件管理工具進行彙總。

　　為了能夠讓這些知識產生價值，我們也開始搭建自己的電商知識庫系統，將所有能夠作為知識沉澱的內容，按照不同的領域分類錄入到知識庫系統內，整套知識庫對外提供了快速檢索和定位的功能，能夠服務於技術人員、產品運營人員，進一步培養大家知識積累的意識，提升大家的工作效率。

　　 四、尾聲

　　二十年前，網際網路剛開始在中國流行，資訊都是透過資訊的方式展示，幾乎沒有線上交易；十年前，網際網路經過快速發展，消費者可以在淘寶、天貓、京東為代表的線上商城上購買自己需要或喜歡的商品進行線上交易；而如今各種電商形態不斷湧現，已成百花齊放的趨勢，比如內容電商小紅書、興趣電商抖音快手，社交電商微商、拼多多等，會員電商天貓88vip、京東plus等。這些線上交易形態充分證明了電商在網際網路領域流量變現的重要一環，已經成為網際網路企業基礎設施的水電煤。

　　電商中臺的建設不光是一個技術體系的搭建，也是一個組織結構重新塑造的過程。但是隨著時間的推移，中臺其價值的增長空間會愈發狹窄，這就需要有意識的尋找創新點，突破現有系統的邊界，跨界思考，於是我們也開始與前臺業務走的更近，積極開展對新業務探索和技術架構升級。

　　1、探索新零售

　　在過往探索汽車電商的業務模式，我們發現核心痛點在無法繞過4S店提供服務。近年來特斯拉和國內造車新勢力的異軍突起，新興的直銷模式一舉打破傳統車企4S經銷體系的生態；國內購車群體也日益年輕化讓我們看到了線上訂車+線下交付的新零售模式正在變成可能。

　　透過升級電商系統的現有能力，商品支援了SKU選配，訂單支援大小定金組合支付、退款，新增交付系統，為工業協會定製車業務、汽車新零售線下店的業務提供了業務支援。未來還會繼續打造業界對齊的新能源選配價格浮動模式以及商品可選配套的服務包模式。

　　2、架構升級

　　在原有的電商交易下單流程中，設計對外的服務都是顆粒度比較小的原子化服務，這就導致了業務方接入成本比較高，使用者體驗也不太好。未來我們將會透過增加BFF層、精簡呼叫鏈、電商接入腳手架等技術手段提升業務的產品力以及運營效率。