★ 目錄 ★

前言

汽車之家電商系統誕生在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層、精簡調用鏈、電商接入腳手架等技術手段提升業務的產品力以及運營效率。