汽車之家電商系統架構演進與平台化架構實踐

★ 目錄★

前言 2.3主數據階段2.4平台化架構階段 3.4開發工具化 3.6知識沉澱尾音

01
	#02 架構演進  2.1開始階段# 2.2微服務階段
	03 平台化架構實務# 3.1業務身分化  3.2服務編排化   3.3業務配置化
# 3.5資料視覺化	04

### 4.1探索新零售############ 4.2架構升級##### ##############

前言

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

架構演進

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

開始階段

網路大環境在2011~2013年經過千團大戰、電商大戰‍[1]之後，電商業務已經成了網路流量變現除廣告模式外的另外一塊戰略高地。 在2013年「雙十一」期間，汽車之家推出購車服務，將交易環節視為一個重要發展方向[2]。在業務起步階段 對技術的要求就是快速迭代上線，以驗證產品可行性。在滿足業務日常需求的同​​時，技術架構上的思考也未停止過。考慮到未來電商系統的可擴展性，參考業界阿里巴巴的技術體系，2014年開始研發技術堆疊也逐步從.NET體系變成Java體系，並與2015年5月30日完成所有的應用切換，上線完整的線上線上購車平台車商城。

微服務階段

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

這個時候的系統支撐面臨巨大的挑戰，系統架構必須升級演化。我們開始做分散式策略，把原來的單一系統分割成多個高內聚，低耦合的中心化系統。也就是現在的用戶中心、商品中心、訂單中心、促銷中心、優惠券中心、商家中心，每個獨立的系統可以獨立設計、獨立接需求、獨立發布，整個研發效率和系統穩定性都上了一個台階。在這個階段我們在技術上完成支撐汽車電商百萬級商品系統[3]、訂單系統[4]、優惠券系統[5]構建，並完成了應用的全部上雲[ 6]、自動化測試平台建置[7]。

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

主資料階段

電商發展的速度實在太快了，到了2019年公司內已經有了多種線上交易模式，例如旅遊類、車品與後市場服務類、積分兌換類等。公司基於發展策略決定搭建電商中台，一方面為了集中公司優質的產品資源、營運資源，打造具影響力的垂直類電商交易平台，另一方面也是為了合理管控技術資源，實現電商系統的統一。在此背景之下，我所在的團隊承擔起了搭建電商中台的任務，由於各個系統間的業務形態、技術架構差異很大，所以我們面臨的第一個問題就是用什麼方式能夠實現交易類系統的整合。為此我們一方面開始熟悉不同業務場景下的交易系統的現狀，另一方面也在技術方案上進行思考與討論。最後我們選擇了「以資料歸一為基礎，提供標準化中台服務，從下層向上層逐個系統整合」的方案。

資料歸一

資料是公司的核心資產，任何系統尤其是交易類別系統，資料更是重中之重。主資料的建構一方面能夠統一資料模型，打破系統障礙；另一方面也能夠透過集中的資料進行經營性資料分析，為業務決策提供依據，因此我們將主資料的建構作為了系統整合的第一步。在交易流程中，最重要的資料集中在商家、商品、訂單、促銷活動這四個領域，我們結合公司交易場景的現狀，分別對這四個領域的主資料進行抽象，統一建模，盡可能的適配大多數的交易場景。以下是訂單主資料核心資料模型結構的示意圖：

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

API標準化

完成了主資料建設，下一步我們便開始進行基於主資料的API標準化建設，API可以看做是系統的神經，高品質的API可以串連起一個優質的系統，統一了API在某種程度上也實現了系統的收口。為此，我們遵循單一職責的原則，按照領域進行區分，明確邊界，做到所有底層API功能原子化，便於上游使用者靈活組裝API完成業務邏輯，同時統一API的參數結構和響應結果的結構，統一錯誤碼，基於API網關統一發布、調用，API的資料統計監控、降級、限流實現統一管控。

API讀寫切換

有了標準化的API，自然需要讓業務方進行使用才能體現出API的價值，為了防止步子邁的太大，我們也是依照業務的重要性以及量級，採用讀寫分階段的方案逐一進行呼叫切換，看似很合理的步驟，在實際執行過程中也暴露了很多問題：1) 在讀寫強依賴的場景，例如：用戶下單完成後馬上會跳到訂單詳情查看訂單，這個時候在未完成寫API切換的時候，由於資料同步延遲會導致透過讀API讀取資料失敗，這時就沒有辦法按照先讀後寫分階段切換，最好的方法是讀寫同時切換。 2) 對於業務切換影響最小的方式，當然是相容原介面的參數和回傳結果，如果我們強加業務方按照我們標準的API進行切換，勢必給業務方帶來切換成本和不必要的負作用。這時候我們自然要從對方的角度出發做一些取捨。我們採用的方式是在標準API之上增加了一層適配層，用於新舊協議的轉換，讓業務方只需要切換域名和請求的URL即可，其他邏輯不變，最大限度的做到對業務方友善。 3) 由於我們提供的底層API都是原子的，但在實際場景中，尤其是前後端分離的項目，前端是不大願意為了一個結果多次調用接口獲取，面對這種情況，我們也是在後端增加了一層閘面層，基於底層原子API組合成滿足業務場景的API對外提供，對於差異化的介面邏輯做適度相容。 4) 讀寫切換不可能一蹴而就，在這個過程中勢必會存在主資料API和原業務API並存的場景，鑑於所有API的入口都將由我們統一提供，因此我們也是採用了路由的機制，通過路由層的location進行區分轉發，所有API做到對呼叫方的透明。 5) 在實際API切換的過程中，還有一個特殊的場景，因為最終要實現系統的整合，對於那些後續會被整合掉的功能強行做API切換其實也是一種資源的浪費，因此我們也是提前做了預判，可以適度的不做切換，等待功能整合後將整體功能切換。

系統功能整合

在完成API讀寫切換之後，基於主資料的功能基本上完成了聚合，此時就需要將通用功能進行系統化的統一，例如：統一的商家管理後台、統一的營運後台、統一的C端交易體驗等，系統層級的統一整合目的是為了給使用者一個統一的操作介面，體現平台的專業性。在系統整合的過程中，我們採用了「共性沉澱，差異取捨」的原則，對於那些通用的能力，例如：商品發布、訂單清單等功能，我們會抽像出通用的能力，提供統一的單元化的操作介面，滿足各業務方的使用訴求。對於業務方特有的功能，我們會建議業務方去實現，而對於那些目前還無法形成通用能力但未來有可能作為通用能力的功能，我們會按照MVP原則，用最快的方式實現小版本的上線，隨著業務的迭代不斷的實作功能沉澱。在整個系統整合的過程中，必然會出現在整合原有系統功能的同時又有新需求的加入，面對這種場景，我們的採用的方式是新舊系統同步開發，看似增加了成本，其實對於新系統的整合是有好處的，一方面能夠不影響業務的開展，不會因為技術性的整合對業務造成停滯，另一方面可以透過新舊系統的對比，找出新系統可能存在的問題，這也會是驗證整合後的新系統功能的最佳途徑。在完成絕大部分的系統整合工作之後，電商核心的交易鏈路已經可以跑通，並且在線上經歷了長時間的驗證，從商家入駐、商品發布、商品展示、下單、支付、履約、售後，到最終的結算，期間遇到的問題也正在一一化解。在這個階段我們完成了公司內3大交易系統的整合，並進行了電商平台秒殺系統的架構升級[8]，優惠券系統的架構升級，支撐了2020-2021的818晚會、雙11、雙12等大型活動的秒殺、發券場景。另外我們也在積極探索領域驅動模型DDD的理論與業界實踐，並在發票總庫系統的重構中進行了落地實踐[9]，這也為後續的平台化架構升級提供了技術支撐。

平台化架構階段

在電商業務中台繼續向業務的「逼近」過程中，系統的抽象和建設難度也成指數型增加，出現了一系列新問題：1）隨著建設中台項目的結束，人員的撤離，電商業務中台在集成這麼多業務線的邏輯之後，代碼裡充斥著大量條件判斷，每次需求迭代的開發成本和測試迴歸成本都很高，如何隔離不同業務之間的邏輯，減少業務之間的耦合度？ 2）如何抽像出已接入電商業務中台的多條業務線的共通能力，以避免重複建設呢？ 3）當新業務接入電商業務中台，如何基於現有的能力和解決方案快速組裝上線，以支撐業務快速迭代創新？ 4) 如何能夠利用技術手段幫助產品運作日常工作提效呢？綜上所述，電商業務中台在建設過程中抽象業務線的共性能力以及共性能力的複用性設計與實現尤其重要，業務中台要做到能力復用和靈活多變才能讓中台建設在企業的發展過程中扮演降本增效的效果。系統架構必須升級，這就進入了平台化架構階段。

平台化架構實踐

什麼是平台化架構？就是要把基礎能力跟每個業務方的特性業務拆分，要把業務和業務之間的邏輯隔離。平台化最核心的是業務抽象建模和系統架構的開放性，業務抽象解決共通性的80%問題，系統架構開放性解決20%的個人化問題。在參考ThoughtWorks給出的《現代企業架構白皮書》的方案[10]以及業界的互聯網公司美團[11]、有讚[12]的中台解決方案，我們給出了適合之家電商平台的解決方案：透過領域驅動建模抽像出電商業務中台多業務線的共性能力並預留擴展點，然後利用服務編排對共性能力進行組合。其原理如圖所示:每一個在電商業務中台運行的業務可以理解為：業務身份 業務流程 規則，業務流程透過流程服務編排來實現，擴展點透過擴展點機制來實現。在整個交易流程中B端的商家入駐、商品發布相對通用，不同的業務的主要流程差異體現在訂單收單前以及支付後的訂單履約，這些流程往往都是需要客製化開發，為此整個解決方案核心在於訂單平台化的架構設計。

如圖所示：整個訂單平台化架構分為四層，從下往上依序為：

• 基礎架構層：提供儲存、訊息、RPC等中介軟體
• 基礎服務層：按網域組織的基礎服務、網域服務內針對不同業務的差異提供擴充點。
• 業務能力層：串聯不同域服務形成可供外部使用的業務能力，例如下訂單、支付等。
• 業務流程層：將業務能力編排、形成訂單交易流程、完成訂單交易流程。
• 業務層：制定業務身分、擴充點實作以及業務流程配置等，實現不同業務差異。

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

業務身份化

業務身份的概念最早由阿里巴巴提出，業務平台在對各業務同時提供服務時，需要能區分每一次業務服務請求的業務身份要素，以便提供差異化個性化的服務；因此需要對企業各業務的身份和特徵進行建模和區分，其產出即為業務身份。業務身分具有唯一性，業務身分類似於身分證號碼一樣，需要保證在整個業務中台上必須是唯一的。有了業務身分業務中台就可以針對抽象這個業務流程和業務規則，並基於業務身分實現服務路由、業務監控。其次業務身分就類似SAAS系統中的租戶的概念，不同的業務方在中台透過業務身分進行資料權限隔離，這樣能確保各業務的營運只能看見自己業務部分的資料。

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

服務編排化

電商業務中台整體採用微服務架構、將整個電商系統分割為商家中心、用戶中心、商品中心、促銷中心、交易中心、履約中心、售後中心。每個中心在邏輯上分成了帶有業務屬性的能力和不帶業務屬性的基礎能力兩層。基礎能力層關注領域模型的實體屬性、行為、事件，不會隨著業務的需求調整而改變，聚焦於產業共性行為、收斂業務模型，保障基礎服務的穩定性。帶有業務屬性的能力是在基礎能力層之上透過服務組合、流程編排之類的技術手段，構成以業務為導向的解決方案，完成業務共通性到個人化的轉變。有兩種常見的做法如下：其一是使用硬編碼來實現。隨著不同業務線的邏輯不斷增加，各個業務能力呼叫的基礎能力會變得盤根錯節，很難做到可設定、靈活化。當需求變更發生的時候，測試人員很難評估修改的影響範圍，迴歸測試的成本週期長，這樣很難真正做到敏捷開發、快速回應業務。其二是使用服務編排。透過服務編排現有微服務進行服務組合服務，然後一次性的返回前台所需的資訊。不同業務線的能力執行不同的流程，透過圖形化、XML、JSON的編排框架，也就是可以讓流程清晰，也可以屏蔽程式碼細節。服務拆分的好處無需贅述，但是要實現業務價值，不是看單一服務的能力，而是要協調所有服務保證企業端到端業務流程的成功。業務中台是企業業務的整合平台，整合技術必須鬆散地耦合組成流程的應用程式和資源，否則流程的邏輯將被硬編碼到特定的技術平台中，更改可能代價高昂，從而違背業務流程復用的整個目標。

服務編排框架

在服務編排領域，已經有很多的工業界解決方案，我們參考了基於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]。 以下是一個簡單的服務流程編排範例：

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

擴充點框架

擴充點的全名是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管理租戶一樣管理業務，不同業務身份在不同場景下對預定義的擴展點進行擴展。阿里巴巴的業務中台也正是基於擴展點的思想，實現的核心業務邏輯和技術細節的分離和解耦，共享事業部才能對集團內幾百條業務線進行支撐的。

服務編排擴展點應用舉例

在驗證功能後對電商交易系統的的場景進行了分類，首先選取用戶感知度小、即使出問題也對用戶影響最小的節點進行重構試用，如未支付訂單逾時關閉、使用者取消訂單。以使用者取消訂單場景為例，在修改前各業務的使用者取消訂單的邏輯為修改訂單狀態為已取消狀態然後執行同一個流程，流程的執行順序為硬編碼，偽代碼如圖所示：

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

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

整個系統的應用效果明顯，主要體現在效能提升和人效提升。效能提升主要體現在系統的回應時間變短，在修改後取消訂單的介面的生產環境的TP99提升百分比約為30%。人效提升方面主要體現在取消訂單增加新流程節點的測試所花費的時間對比，在修改前，各業務流程之間的程式碼是耦合的，修改流程增加新節點需要對以前的各業務進行回歸測試，修改後不需要進行各業務的迴歸測試。

業務配置化

在平台化架構實務中我們將那些影響業務流程的核心配置統一提取出來，並依照業務身分進行屬性值的配置，確保整個交易流程連結的標準統一，減少對交易核心連結程式碼的頻繁修改，不同業務根據不同的屬性值在相同的交易流程中的不同節點進行靈活切換。例如：商品是否自動推送到資源池、下單是否需要填寫身分證、付款成功是否推送線索、超過N天未確認收貨是否自動確認收貨完成等等，所有配置項目均透過配置管理後台進行統一維護。此外，對於電商中台中包括業務身份在內的所有元數據，我們也透過組態管理後台進行了統一的管理並提供統一的API對外提供查詢服務。

開發工具化

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

資料視覺化

電商系統的效能指標、資源利用率指標、呼叫量等系統維度的指標透過公司雲端平台能夠實現統一的監控，對於業務資料同理，我們需要提供統一的業務資料視覺化工具，為業務方提供做相關決策的參考依據。為此，我們採用即時 離線的方式開發了訂單視覺化大螢幕系統，透過這個系統能夠按照業務線、訂單狀態、區域等多個維度即時監控訂單量的變化。如果固定時間內的訂單量波動超過了我們事先配置的閾值，也會發送釘釘訊息及時通知業務方注意。

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

知識沉澱

#我所在的這個團隊在公司內部的電商領域是一個專業的團隊，多年來累積了許多技術以及產品營運層面的經驗。在整個電商中台的建造過程中，我們也是將這些經驗以及日常問題的解決辦法，作為一種財富不斷的沉澱，以往都是採用wiki這種文檔管理工具進行匯總。為了能讓這些知識產生價值，我們也開始建立自己的電商知識庫系統，將所有能夠作為知識沉澱的內容，按照不同的領域分類錄入到知識庫系統內，整套知識庫對外提供了快速檢索和定位的功能，能夠服務技術人員、產品營運人員，進一步培養大家知識累積的意識，提升大家的工作效率。

尾聲

#

二十年前，網路剛開始在中國流行，資訊都是透過資訊的方式展示，幾乎沒有線上交易；十年前，網路經過快速發展，消費者可以在淘寶、天貓、京東為代表的線上商城上購買自己需要或喜歡的商品進行線上交易；而如今各種電商形態不斷湧現，已成百花齊放的趨勢，例如內容電商小紅書、興趣電商抖音快手，社交電商微商、拼多等，會員電商天貓88vip、京東plus等。這些線上交易形態充分證明了電商在網路領域流量變現的重要一環，已成為網路企業基礎設施的水力發電煤。電商中台的建設不光是一個技術體系的搭建，也是一個組織結構重新塑造的過程。但隨著時間的推移，中台其價值的成長空間會愈發狹窄，這就需要有意識的尋找創新點，突破現有系統的邊界，跨界思考，於是我們也開始與前台業務走的更近，積極開展對新業務探索和技術架構升級。

探索新零售

在過往探索汽車電商的業務模式，我們發現核心痛點在無法繞過4S店提供服務。近年來特斯拉和國內造車新勢力的異軍突起，新興的直銷模式一舉打破傳統車企4S經銷體系的生態；國內購車群體也日益年輕化讓我們看到了線上訂車線下交付的新零售模式正在變成可能。透過升級電商系統的現有能力，商品支持了SKU選配，訂單支援大小定金組合支付、退款，新增交付系統，為工業協會定制車業務、汽車新零售線下店的業務提供了業務支持。未來將繼續打造業界對齊的新能源選配價格浮動模式以及商品可選配套的服務包模式。

架構升級

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

以上是汽車之家電商系統架構演進與平台化架構實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！