★ 目錄 ★

前言

汽車之家電商系統(tǒng)誕生在2014年，成長于2016~2019年，并經(jīng)歷多年雙11、818晚會的洪峰考驗，沉淀了穩(wěn)定可靠、性能卓越的在線交易能力。隨著業(yè)務(wù)中臺的建設(shè)浪潮興起，2019年進(jìn)入中臺化建設(shè)階段，輸出其在汽車電商領(lǐng)域五年沉淀的能力，助力汽車電商行業(yè)發(fā)展，加速企業(yè)數(shù)字化轉(zhuǎn)型！

架構(gòu)演進(jìn)

這個部分主要講一下汽車之家電商系統(tǒng)的架構(gòu)發(fā)展歷程，每個階段的業(yè)務(wù)狀況、技術(shù)挑戰(zhàn)和技術(shù)體系的應(yīng)對策略。

起步階段

互聯(lián)網(wǎng)大環(huán)境在2011~2013年經(jīng)過千團(tuán)大戰(zhàn)、電商大戰(zhàn)?[1]之后，電商業(yè)務(wù)已經(jīng)成了互聯(lián)網(wǎng)流量變現(xiàn)除廣告模式外的另外一塊戰(zhàn)略高地。在2013年“雙十一”期間，汽車之家推出購車服務(wù)，將交易環(huán)節(jié)作為一個重要發(fā)展方向[2]。在業(yè)務(wù)起步階段 對技術(shù)的要求就是快速迭代上線，驗證產(chǎn)品可行性。在滿足業(yè)務(wù)日常需求的同時，技術(shù)架構(gòu)上的思考也未停止過。考慮到未來電商系統(tǒng)的可擴(kuò)展性，參考業(yè)界阿里巴巴的技術(shù)體系，2014年開始研發(fā)技術(shù)棧也逐步從 .NET體系變成Java體系，并與2015年5月30日完成所有的應(yīng)用切換，上線完整的在線網(wǎng)上購車平臺車商城。

微服務(wù)階段

隨著電商業(yè)務(wù)迅猛發(fā)展，技術(shù)人員的增加，到2016年技術(shù)團(tuán)隊已經(jīng)有了上百人。單體架構(gòu)之痛迎面撲來，就以一個前臺的商城git項目而言，就幾乎近30個maven的子項目，遇上需求并行開發(fā)，經(jīng)常出現(xiàn)代碼的合并沖突、需求上線等待、線上慢SQL等問題，整個系統(tǒng)的開發(fā)效率和系統(tǒng)穩(wěn)定性都變差了。

這個時候的系統(tǒng)支撐面臨巨大的挑戰(zhàn)，系統(tǒng)架構(gòu)必須升級進(jìn)化。我們開始做分布式戰(zhàn)略，把原來的單一系統(tǒng)拆分成多個高內(nèi)聚，低耦合的中心化系統(tǒng)。也就是現(xiàn)在的用戶中心、商品中心、訂單中心、促銷中心、優(yōu)惠券中心、商家中心，每個獨立的系統(tǒng)可以獨立設(shè)計、獨立接需求、獨立發(fā)布，整個研發(fā)效率和系統(tǒng)穩(wěn)定性都上了一個臺階。在這個階段我們在技術(shù)上完成 支撐汽車電商百萬級商品系統(tǒng)[3]、訂單系統(tǒng)[4]、優(yōu)惠券系統(tǒng)[5]構(gòu)建，并完成了應(yīng)用的全部上云[6]、自動化測試平臺構(gòu)建[7]。

同時在業(yè)務(wù)上探索了自營整車電商模式 、開放平臺模式、B2B2C模式、報價單模式、顧問模式、TPCC模式、平行進(jìn)口車售賣等各種經(jīng)營模式。

主數(shù)據(jù)階段

電商發(fā)展的速度實在太快了，到了2019年公司內(nèi)已經(jīng)有了多種在線交易模式，比如旅游類、車品與后市場服務(wù)類、積分兌換類等。公司基于發(fā)展戰(zhàn)略決定搭建電商中臺，一方面為了集中公司優(yōu)質(zhì)的產(chǎn)品資源、運營資源，打造具有影響力的垂直類電商交易平臺，另一方面也是為了合理管控技術(shù)資源，實現(xiàn)電商系統(tǒng)的統(tǒng)一。在此背景之下，我所在的團(tuán)隊承擔(dān)起了搭建電商中臺的任務(wù)，由于各個系統(tǒng)間的業(yè)務(wù)形態(tài)、技術(shù)架構(gòu)差異很大，所以我們面臨的第一個問題就是用什么方式能夠?qū)崿F(xiàn)交易類系統(tǒng)的整合。為此我們一方面開始熟悉不同業(yè)務(wù)場景下的交易系統(tǒng)的現(xiàn)狀，另一方面也在技術(shù)方案上進(jìn)行著思考和討論。最終我們選擇了“以數(shù)據(jù)歸一為基礎(chǔ)，提供標(biāo)準(zhǔn)化中臺服務(wù)，從下層向上層逐個系統(tǒng)整合”的方案。

數(shù)據(jù)歸一

數(shù)據(jù)是公司的核心資產(chǎn)，任何系統(tǒng)尤其是交易類系統(tǒng)，數(shù)據(jù)更是重中之重。主數(shù)據(jù)的建設(shè)一方面能夠統(tǒng)一數(shù)據(jù)模型，打破系統(tǒng)壁壘；另一方面也能夠通過集中的數(shù)據(jù)進(jìn)行經(jīng)營性數(shù)據(jù)分析，為業(yè)務(wù)決策提供依據(jù)，因此我們將主數(shù)據(jù)的建設(shè)作為了系統(tǒng)整合的第一步。在交易流程中，最重要的數(shù)據(jù)集中在商家、商品、訂單、促銷活動這四個領(lǐng)域，我們結(jié)合公司交易場景的現(xiàn)狀，分別對這四個領(lǐng)域的主數(shù)據(jù)進(jìn)行抽象，統(tǒng)一建模，盡可能的適配大多數(shù)的交易場景。以下是訂單主數(shù)據(jù)核心數(shù)據(jù)模型結(jié)構(gòu)的示意圖：

完成了統(tǒng)一的數(shù)據(jù)模型后，下一步就需要將現(xiàn)有的異構(gòu)型數(shù)據(jù)導(dǎo)入到主數(shù)據(jù)庫中，我們采用了讀取數(shù)據(jù)庫binlog（mysql、sqlserver）進(jìn)行數(shù)據(jù)加工的方式完成初期的數(shù)據(jù)同步導(dǎo)入，這也是對業(yè)務(wù)侵入最小、最快的實現(xiàn)方案。

API標(biāo)準(zhǔn)化

完成了主數(shù)據(jù)建設(shè)，下一步我們便開始進(jìn)行基于主數(shù)據(jù)的API標(biāo)準(zhǔn)化建設(shè)，API可以看做是系統(tǒng)的神經(jīng)，高質(zhì)量的API可以串聯(lián)起一個優(yōu)質(zhì)的系統(tǒng)，統(tǒng)一了API在一定程度上也就實現(xiàn)了系統(tǒng)的收口。為此，我們遵循單一職責(zé)的原則，按照領(lǐng)域進(jìn)行區(qū)分，明確邊界，做到所有底層API功能原子化，便于上游使用者靈活組裝API完成業(yè)務(wù)邏輯，同時統(tǒng)一API的參數(shù)結(jié)構(gòu)和響應(yīng)結(jié)果的結(jié)構(gòu)，統(tǒng)一錯誤碼，基于API網(wǎng)關(guān)統(tǒng)一發(fā)布、調(diào)用，API的數(shù)據(jù)統(tǒng)計監(jiān)控、降級、限流實現(xiàn)統(tǒng)一管控。

API讀寫切換

有了標(biāo)準(zhǔn)化的API，自然需要讓業(yè)務(wù)方進(jìn)行使用才能體現(xiàn)出API的價值，為了防止步子邁的太大，我們也是按照業(yè)務(wù)的重要性以及量級，采用讀寫分階段的方案逐個業(yè)務(wù)進(jìn)行調(diào)用切換，看似很合理的步驟，在實際執(zhí)行過程中也暴露了很多問題：1) 在讀寫強依賴的場景，比如：用戶下單完成后馬上會跳轉(zhuǎn)到訂單詳情查看訂單，這個時候在未完成寫API切換的時候，由于數(shù)據(jù)同步延遲會導(dǎo)致通過讀API讀取數(shù)據(jù)失敗，這時就沒有辦法按照先讀后寫分階段進(jìn)行切換，最好的辦法是讀寫同時切換。2) 對于業(yè)務(wù)切換影響最小的方式，當(dāng)然是兼容原接口的參數(shù)和返回結(jié)果，如果我們強加業(yè)務(wù)方按照我們標(biāo)準(zhǔn)的API進(jìn)行切換，勢必給業(yè)務(wù)方帶來切換成本和不必要的負(fù)作用。這個時候我們自然要從對方的角度出發(fā)做一些取舍。我們采用的方式是在標(biāo)準(zhǔn)API之上增加了一層適配層，用于新老協(xié)議的轉(zhuǎn)換，讓業(yè)務(wù)方只需要切換域名和請求的URL即可，其他邏輯不變，最大限度的做到對業(yè)務(wù)方友好。3) 由于我們提供的底層API都是原子的，但在實際場景中，尤其是前后端分離的項目，前端是不大愿意為了一個結(jié)果多次調(diào)用接口獲取，面對這種情況，我們也是在后端增加了一層門面層，基于底層原子API組合成滿足業(yè)務(wù)場景的API對外提供，對于差異化的接口邏輯做適度兼容。4) 讀寫切換不可能一蹴而就，在這個過程中勢必會存在主數(shù)據(jù)API和原業(yè)務(wù)API并存的場景，鑒于所有API的入口都將由我們統(tǒng)一提供，因此我們也是采用了路由的機(jī)制，通過路由層的location進(jìn)行區(qū)分轉(zhuǎn)發(fā)，所有API做到對調(diào)用方的透明。5) 在實際API切換的過程中，還有一種特殊的場景，因為最終要實現(xiàn)系統(tǒng)的整合，對于那些后續(xù)會被整合掉的功能強行做API切換其實也是一種資源的浪費，因此我們也是提前做了預(yù)判，可以適度的不做切換，等待功能整合后將整體功能進(jìn)行切換。

系統(tǒng)功能整合

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

平臺化架構(gòu)階段

在電商業(yè)務(wù)中臺繼續(xù)向業(yè)務(wù)的“逼近”過程中，系統(tǒng)的抽象和建設(shè)難度也成指數(shù)型增加，出現(xiàn)了一系列新問題：1）隨著建設(shè)中臺項目的結(jié)束，人員的撤離，電商業(yè)務(wù)中臺在集成這么多業(yè)務(wù)線的邏輯之后，代碼里充斥著大量條件判斷，每次需求迭代的開發(fā)成本和測試回歸成本都很高，如何隔離不同業(yè)務(wù)之間的邏輯，減少業(yè)務(wù)之間的耦合度呢？2）如何抽象出已接入電商業(yè)務(wù)中臺的多條業(yè)務(wù)線的共性能力，以避免重復(fù)建設(shè)呢？3）當(dāng)新業(yè)務(wù)接入電商業(yè)務(wù)中臺，如何基于已有的能力和解決方案快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？4) 如何能夠利用技術(shù)手段幫助產(chǎn)品運營日常工作提效呢？綜上所述，電商業(yè)務(wù)中臺在建設(shè)過程中抽象業(yè)務(wù)線的共性能力以及共性能力的復(fù)用性設(shè)計與實現(xiàn)尤其重要，業(yè)務(wù)中臺要做到能力復(fù)用和靈活多變才能讓中臺建設(shè)在企業(yè)的發(fā)展過程中起到降本增效的效果。系統(tǒng)架構(gòu)必須升級，這就進(jìn)入了平臺化架構(gòu)階段。

平臺化架構(gòu)實踐

什么是平臺化架構(gòu)？就是要把基礎(chǔ)能力跟每個業(yè)務(wù)方的特性業(yè)務(wù)拆分，要把業(yè)務(wù)和業(yè)務(wù)之間的邏輯進(jìn)行隔離。平臺化最核心的是業(yè)務(wù)抽象建模和系統(tǒng)架構(gòu)的開放性，業(yè)務(wù)抽象解決共性的80%問題，系統(tǒng)架構(gòu)開放性解決20%的個性化問題。在參考ThoughtWorks給出的《現(xiàn)代企業(yè)架構(gòu)白皮書》的方案[10]以及業(yè)界的互聯(lián)網(wǎng)公司美團(tuán)[11]、有贊[12]的中臺解決方案，我們給出了適合之家電商平臺的解決方案：通過領(lǐng)域驅(qū)動建模抽象出電商業(yè)務(wù)中臺多業(yè)務(wù)線的共性能力并預(yù)留擴(kuò)展點，然后利用服務(wù)編排對共性能力進(jìn)行組合。其原理如圖所示:每一個在電商業(yè)務(wù)中臺運行的業(yè)務(wù)可以理解為：業(yè)務(wù)身份+業(yè)務(wù)流程+規(guī)則，業(yè)務(wù)流程通過流程服務(wù)編排來實現(xiàn)，擴(kuò)展點通過擴(kuò)展點機(jī)制來實現(xiàn)。在整個交易流程中B端的商家入駐、商品發(fā)布相對通用，不同的業(yè)務(wù)的主要流程差別體現(xiàn)在訂單收單前以及支付后的訂單履約，這些流程往往都是需要定制化開發(fā)，為此整個解決方案核心在于訂單平臺化的架構(gòu)設(shè)計。

如圖所示：整個訂單平臺化架構(gòu)分為四層，從下往上依次是：

• 基礎(chǔ)設(shè)施層：提供存儲、消息、RPC等中間件
• 基礎(chǔ)服務(wù)層：按域組織的基礎(chǔ)服務(wù)、域服務(wù)內(nèi)針對不同業(yè)務(wù)的差異提供擴(kuò)展點。
• 業(yè)務(wù)能力層：串聯(lián)不同域服務(wù)形成可供外部使用的業(yè)務(wù)能力，比如下單、支付等。
• 業(yè)務(wù)流程層：對業(yè)務(wù)能力進(jìn)行編排、形成訂單交易流程、完成訂單交易過程。
• 業(yè)務(wù)層：制定業(yè)務(wù)身份、擴(kuò)展點實現(xiàn)以及業(yè)務(wù)流程配置等，實現(xiàn)不同業(yè)務(wù)差異。

整個訂單平臺化架構(gòu)升級實踐過程，總結(jié)為以下幾點：

業(yè)務(wù)身份化

業(yè)務(wù)身份的概念最早由阿里巴巴提出，業(yè)務(wù)平臺在對各業(yè)務(wù)同時提供服務(wù)時，需要能區(qū)分每一次業(yè)務(wù)服務(wù)請求的業(yè)務(wù)身份要素，以便提供差異化個性化的服務(wù)；因此需要對企業(yè)各業(yè)務(wù)的身份和特征進(jìn)行建模和區(qū)分，其產(chǎn)出即為業(yè)務(wù)身份。業(yè)務(wù)身份具有唯一性，業(yè)務(wù)身份類似于身份證號碼一樣，需要保證在整個業(yè)務(wù)中臺上必須是唯一的。有了業(yè)務(wù)身份業(yè)務(wù)中臺就可以針對抽象這個業(yè)務(wù)流程和業(yè)務(wù)規(guī)則，并基于業(yè)務(wù)身份實現(xiàn)服務(wù)路由、業(yè)務(wù)監(jiān)控。其次業(yè)務(wù)身份就類似SAAS系統(tǒng)中的租戶的概念，不同的業(yè)務(wù)方在中臺通過業(yè)務(wù)身份進(jìn)行數(shù)據(jù)權(quán)限隔離，這樣能保證各業(yè)務(wù)的運營只能看見自己業(yè)務(wù)部分的數(shù)據(jù)。

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

服務(wù)編排化

電商業(yè)務(wù)中臺整體采用微服務(wù)架構(gòu)、將整個電商系統(tǒng)拆分為商家中心、用戶中心、商品中心、促銷中心、交易中心、履約中心、售后中心。每個中心在邏輯上分成了帶有業(yè)務(wù)屬性的能力和不帶業(yè)務(wù)屬性的基礎(chǔ)能力兩層?；A(chǔ)能力層關(guān)注領(lǐng)域模型的實體屬性、行為、事件，不會隨著業(yè)務(wù)的需求調(diào)整而發(fā)生變化，聚焦于行業(yè)共性行為、收斂業(yè)務(wù)模型，保障基礎(chǔ)服務(wù)的穩(wěn)定性。帶有業(yè)務(wù)屬性的能力是在基礎(chǔ)能力層之上通過服務(wù)組合、流程編排之類的技術(shù)手段，構(gòu)成面向業(yè)務(wù)的解決方案，完成業(yè)務(wù)共性到個性化的轉(zhuǎn)變。有兩種常見的做法如下：其一是使用硬編碼來實現(xiàn)。隨著不同業(yè)務(wù)線的邏輯不斷增加，各個業(yè)務(wù)能力調(diào)用的基礎(chǔ)能力會變得盤根錯節(jié)，很難做到可配置、靈活化。當(dāng)發(fā)生需求變更的時候，測試人員很難評估修改的影響范圍，回歸測試的成本周期長，這樣很難真正做到敏捷開發(fā)、快速響應(yīng)業(yè)務(wù)。其二是使用服務(wù)編排。通過服務(wù)編排現(xiàn)有微服務(wù)進(jìn)行服務(wù)組合服務(wù)，然后一次性的返回前臺需要的信息。不同業(yè)務(wù)線的能力執(zhí)行不同的流程，通過圖形化、XML、JSON的編排框架，即可以讓流程清晰，也可以屏蔽代碼細(xì)節(jié)。服務(wù)拆分的好處無需贅述，但是要實現(xiàn)業(yè)務(wù)價值，不是看單個服務(wù)的能力，而是要協(xié)調(diào)所有服務(wù)保證企業(yè)端到端業(yè)務(wù)流程的成功。業(yè)務(wù)中臺是企業(yè)業(yè)務(wù)的集成平臺，集成技術(shù)必須松散地耦合組成流程的應(yīng)用程序和資源，否則流程的邏輯將被硬編碼到特定的技術(shù)平臺中，更改可能代價高昂，從而違背業(yè)務(wù)流程復(fù)用的整個目標(biāo)。

服務(wù)編排框架

在服務(wù)編排領(lǐng)域，已經(jīng)有很多的工業(yè)界解決方案，我們參考了基于API網(wǎng)關(guān)的服務(wù)編排[13]，基于工作流系統(tǒng)的編排框架Flowable和Activiti[14]、基于微服務(wù)架構(gòu)編排框架的Netflix Conductor[16]和Zeebe[17]。通過對技術(shù)原理進(jìn)行分析，發(fā)現(xiàn)它們都存在某些程度上的不足，無法應(yīng)用到電商業(yè)務(wù)中臺的服務(wù)編排，最終我們選用Apache Camel [18]做為服務(wù)編排的底層引擎進(jìn)行二次封裝開發(fā)。Apache Camel 誕生于2007年，2009年前后成為Apache頂級項目更名為Apache Camel，目前最新版本是3.0。Apache Camel的優(yōu)點在于在發(fā)布后十多年的時間里，已經(jīng)擁有三百多種擴(kuò)展組件；擴(kuò)展機(jī)制也極其方便和靈活；通過開箱即可用的最佳實踐來解決應(yīng)用集成問題；它基于事件驅(qū)動的架構(gòu)，有著良好的性能和吞吐量[19]。以下是一個簡單的服務(wù)流程編排樣例：

業(yè)務(wù)中臺使用服務(wù)編排技術(shù)一方面可以將交易的能力自動識別出來作為組件可視化的呈現(xiàn)，形成能力地圖；另一方面，基于這些基礎(chǔ)能力實現(xiàn)服務(wù)流程的編排，能夠通過拖拉拽的方式快速搭建出適合業(yè)務(wù)的全部或者部分交易流程，類似積木，復(fù)用基礎(chǔ)組件，靈活搭配，進(jìn)而實現(xiàn)電商企業(yè)級能力的復(fù)用，節(jié)約開發(fā)成本，快速賦能業(yè)務(wù)的目標(biāo)。

擴(kuò)展點框架

擴(kuò)展點的全稱是Service Provider Interface，簡稱為SPI。是Java提供的一套用來加載和運行第三方擴(kuò)展的接口實現(xiàn)類的機(jī)制，一般用在組件替換和框架擴(kuò)展的場景。SPI將服務(wù)接口與服務(wù)實現(xiàn)分離以達(dá)到解耦、提升了應(yīng)用程序的可擴(kuò)展性。在程序設(shè)計中，模塊之間采用面向接口編程而不做具體的實現(xiàn)類引用，通過動態(tài)加載實現(xiàn)類達(dá)到應(yīng)用程序的插件化。COLA框架是阿里巴巴技術(shù)專家提出的一種應(yīng)用架構(gòu)的擴(kuò)展點框架[20]。COLA框架的擴(kuò)展是通過注解的方式來實現(xiàn)的，Extension擴(kuò)展注解里面使用用例（useCase）、業(yè)務(wù)（bizId）、場景（scenario）三個屬性用來標(biāo)識身份。使用COLA框架的擴(kuò)展點可以在代碼層面支持不同業(yè)務(wù)身份的邏輯隔離，因為不同的邏輯分散在不同的實現(xiàn)類里面，符合軟件設(shè)計的開閉原則。COLA框架在應(yīng)用Spring上下文初始化完畢階段，開始掃描帶有Extension注解的bean進(jìn)行擴(kuò)展點注冊，以Map的結(jié)構(gòu)存儲，Key是useCase、bizId、scenario的字符串拼接，value是該bean。在運行時，通過業(yè)務(wù)身份定位擴(kuò)展點實現(xiàn)類，然后執(zhí)行擴(kuò)展點實現(xiàn)的邏輯。定位擴(kuò)展點實現(xiàn)的時候支持三層路由，首先會按照useCase+bizId+scenario找擴(kuò)展點實現(xiàn)，如果沒有則按照useCase+bizId+scenario默認(rèn)值查找，如果還未找到則根據(jù)useCase+bizId默認(rèn)值+scenario默認(rèn)值查找，具體原理如圖所示：

對于簡單的業(yè)務(wù)場景，對應(yīng)用系統(tǒng)的高擴(kuò)展性、業(yè)務(wù)隔離的非功能性要求并不多。但是隨著同一應(yīng)用系統(tǒng)支撐的業(yè)務(wù)變多、業(yè)務(wù)場景變復(fù)雜，在架構(gòu)層面需要提供統(tǒng)一的擴(kuò)展解決方案，將變化的業(yè)務(wù)規(guī)則固化下來，這不僅有助于統(tǒng)一技術(shù)規(guī)范，還能減少硬編碼的IF-ELSE、策略模式等因開發(fā)人員水平不一致帶來的理解上復(fù)雜度、規(guī)范上的一致性。通過擴(kuò)展點機(jī)制，業(yè)務(wù)中臺就可以從業(yè)務(wù)身份和框架層面實現(xiàn)對不同的業(yè)務(wù)的管理像SAAS管理租戶一樣管理業(yè)務(wù)，不同業(yè)務(wù)身份在不同場景下對預(yù)定義的擴(kuò)展點進(jìn)行擴(kuò)展。阿里巴巴的業(yè)務(wù)中臺也正是基于擴(kuò)展點的思想，實現(xiàn)的核心業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)的分離和解耦，共享事業(yè)部才能對集團(tuán)內(nèi)幾百條業(yè)務(wù)線進(jìn)行支撐的。

服務(wù)編排+擴(kuò)展點應(yīng)用舉例

在驗證功能后對電商交易系統(tǒng)的的場景進(jìn)行了分類，首先選取用戶感知度小、即使出問題也對用戶影響最小的節(jié)點進(jìn)行重構(gòu)試用，如未支付訂單超時關(guān)閉、用戶取消訂單。以用戶取消訂單場景為例，在修改前各業(yè)務(wù)的用戶取消訂單的邏輯為修改訂單狀態(tài)為已取消狀態(tài)然后執(zhí)行同一個流程，流程的執(zhí)行順序為硬編碼，偽代碼如圖所示：

修改后根據(jù)各業(yè)務(wù)的特性的進(jìn)行了精細(xì)編排，如二手車業(yè)務(wù)沒有使用優(yōu)惠券的場景，那么就不需要再有這個環(huán)節(jié)；在積分這個通用能力上，擴(kuò)展的是萬里通積分。偽代碼如圖所示：

旅行家業(yè)務(wù)線的的酒店、機(jī)票業(yè)務(wù)無傳統(tǒng)的商品庫存的概念，那么就不再需要還商品庫存的操作，而是抽象一個新的通用能力：取消供應(yīng)商訂單，并預(yù)置了取消酒店供應(yīng)商訂單的擴(kuò)展以及取消機(jī)票供應(yīng)商訂單2個擴(kuò)展點。偽代碼如圖所示：

整個系統(tǒng)的應(yīng)用效果明顯，主要體現(xiàn)在性能提升和人效提升。性能提升主要體現(xiàn)在系統(tǒng)的響應(yīng)時間變短，在修改后取消訂單的接口的生產(chǎn)環(huán)境的TP99提升百分比約為30%。人效提升方面主要體現(xiàn)在取消訂單增加新流程節(jié)點的測試所用的時間對比，在修改前，各業(yè)務(wù)流程之間的代碼是耦合的，修改流程增加新節(jié)點需要對以前的各業(yè)務(wù)進(jìn)行回歸測試，修改后不需要進(jìn)行各業(yè)務(wù)的回歸測試。

業(yè)務(wù)配置化

在平臺化架構(gòu)實踐中我們將那些影響業(yè)務(wù)流轉(zhuǎn)的核心配置統(tǒng)一提取出來，并按照業(yè)務(wù)身份進(jìn)行屬性值的配置，確保整個交易流程鏈路的標(biāo)準(zhǔn)統(tǒng)一，減少對交易核心鏈路代碼的頻繁修改，不同業(yè)務(wù)根據(jù)不同的屬性值在相同的交易流程中的不同節(jié)點進(jìn)行靈活切換。比如：商品是否自動推送到資源池、下單是否需要填寫身份證、支付成功是否推送線索、超過N天未確認(rèn)收貨是否自動確認(rèn)收貨完成等等，所有配置項均通過配置管理后臺進(jìn)行統(tǒng)一維護(hù)。此外，對于電商中臺中包括業(yè)務(wù)身份在內(nèi)的所有元數(shù)據(jù)，我們也通過配置管理后臺進(jìn)行了統(tǒng)一的管理并提供統(tǒng)一的API對外提供查詢服務(wù)。

開發(fā)工具化

從業(yè)務(wù)和技術(shù)的多維度出發(fā)，針對日常工作中出現(xiàn)的常見業(yè)務(wù)問題或者技術(shù)問題，研發(fā)出各類實用便捷的小工具，實現(xiàn)工作效率的提升、問題的快速定位等效果，比如：消息分發(fā)、檢索工具；商品優(yōu)惠價格速算工具；商品展示價格比對監(jiān)控工具；緩存管理工具；一鍵降級工具等等。隨著大家工具化意識的不斷提升，這類小工具不斷的出現(xiàn)并匯集在一起，就構(gòu)成了研發(fā)人員必不可少的工具箱。

數(shù)據(jù)可視化

電商系統(tǒng)的性能指標(biāo)、資源利用率指標(biāo)、調(diào)用量等系統(tǒng)維度的指標(biāo)通過公司云平臺能夠?qū)崿F(xiàn)統(tǒng)一的監(jiān)控，對于業(yè)務(wù)數(shù)據(jù)同理，我們需要提供統(tǒng)一的業(yè)務(wù)數(shù)據(jù)可視化工具，為業(yè)務(wù)方提供做相關(guān)決策的參照依據(jù)。為此，我們采用實時+離線的方式開發(fā)了訂單可視化大屏系統(tǒng)，通過這個系統(tǒng)能夠按照業(yè)務(wù)線、訂單狀態(tài)、區(qū)域等多個維度實時監(jiān)控訂單量的變化情況。如果固定時間段內(nèi)的訂單量波動超過了我們事先配置的閾值，還會發(fā)送釘釘消息及時通知業(yè)務(wù)方關(guān)注。

此外，對于離線數(shù)據(jù)，我們也是按照日、周、月從多個維度進(jìn)行數(shù)據(jù)統(tǒng)計分析，最終會以郵件和辦公APP消息的形式發(fā)送給業(yè)務(wù)方，這些手段的目的都是為了實現(xiàn)電商數(shù)據(jù)的可視化管理，為業(yè)務(wù)使用方提供更多便捷的工具對電商業(yè)務(wù)進(jìn)行全方位的管控。

知識沉淀

我所在的這個團(tuán)隊在公司內(nèi)部的電商領(lǐng)域是一個專業(yè)的團(tuán)隊，多年來積累了很多技術(shù)以及產(chǎn)品運營層面的經(jīng)驗。在整個電商中臺的建設(shè)過程中，我們也是將這些經(jīng)驗以及日常問題的解決辦法，作為一種財富不斷的沉淀，以往都是采用wiki這種文檔管理工具進(jìn)行匯總。為了能夠讓這些知識產(chǎn)生價值，我們也開始搭建自己的電商知識庫系統(tǒng)，將所有能夠作為知識沉淀的內(nèi)容，按照不同的領(lǐng)域分類錄入到知識庫系統(tǒng)內(nèi)，整套知識庫對外提供了快速檢索和定位的功能，能夠服務(wù)于技術(shù)人員、產(chǎn)品運營人員，進(jìn)一步培養(yǎng)大家知識積累的意識，提升大家的工作效率。

尾聲

二十年前，互聯(lián)網(wǎng)剛開始在中國流行，信息都是通過資訊的方式展示，幾乎沒有在線交易；十年前，互聯(lián)網(wǎng)經(jīng)過快速發(fā)展，消費者可以在淘寶、天貓、京東為代表的在線商城上購買自己需要或喜歡的商品進(jìn)行在線交易；而如今各種電商形態(tài)不斷涌現(xiàn)，已成百花齊放的趨勢，比如內(nèi)容電商小紅書、興趣電商抖音快手，社交電商微商、拼多多等，會員電商天貓88vip、京東plus等。這些在線交易形態(tài)充分證明了電商在互聯(lián)網(wǎng)領(lǐng)域流量變現(xiàn)的重要一環(huán)，已經(jīng)成為互聯(lián)網(wǎng)企業(yè)基礎(chǔ)設(shè)施的水電煤。電商中臺的建設(shè)不光是一個技術(shù)體系的搭建，也是一個組織結(jié)構(gòu)重新塑造的過程。但是隨著時間的推移，中臺其價值的增長空間會愈發(fā)狹窄，這就需要有意識的尋找創(chuàng)新點，突破現(xiàn)有系統(tǒng)的邊界，跨界思考，于是我們也開始與前臺業(yè)務(wù)走的更近，積極開展對新業(yè)務(wù)探索和技術(shù)架構(gòu)升級。

探索新零售

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

架構(gòu)升級

在原有的電商交易下單流程中，設(shè)計對外的服務(wù)都是顆粒度比較小的原子化服務(wù)，這就導(dǎo)致了業(yè)務(wù)方接入成本比較高，用戶體驗也不太好。未來我們將會通過增加BFF層、精簡調(diào)用鏈、電商接入腳手架等技術(shù)手段提升業(yè)務(wù)的產(chǎn)品力以及運營效率。