作者 | 方利

編輯 | 賈亞寧

本文由大廠案例轉(zhuǎn)載自汽車之家主機(jī)廠事業(yè)部 - 技術(shù)部高級研發(fā)工程師方利首發(fā)于之家技術(shù)公眾號(hào)的文章。

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

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

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

1. 起步階段

互聯(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é)作為一個(gè)重要發(fā)展方向 [2]。

在業(yè)務(wù)起步階段對技術(shù)的要求就是快速迭代上線，驗(yàn)證產(chǎn)品可行性。在滿足業(yè)務(wù)日常需求的同時(shí)，技術(shù)架構(gòu)上的思考也未停止過?？紤]到未來電商系統(tǒng)的可擴(kuò)展性，參考業(yè)界阿里巴巴的技術(shù)體系，2014 年開始研發(fā)技術(shù)棧也逐步從 .NET 體系變成 Java 體系，并與 2015 年 5 月 30 日完成所有的應(yīng)用切換，上線完整的在線網(wǎng)上購車平臺(tái)車商城。

2. 微服務(wù)階段

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

這個(gè)時(shí)候的系統(tǒng)支撐面臨巨大的挑戰(zhàn)，系統(tǒng)架構(gòu)必須升級進(jìn)化。我們開始做分布式戰(zhàn)略，把原來的單一系統(tǒng)拆分成多個(gè)高內(nèi)聚，低耦合的中心化系統(tǒng)。也就是現(xiàn)在的用戶中心、商品中心、訂單中心、促銷中心、優(yōu)惠券中心、商家中心，每個(gè)獨(dú)立的系統(tǒng)可以獨(dú)立設(shè)計(jì)、獨(dú)立接需求、獨(dú)立發(fā)布，整個(gè)研發(fā)效率和系統(tǒng)穩(wěn)定性都上了一個(gè)臺(tái)階。

在這個(gè)階段我們在技術(shù)上完成支撐汽車電商百萬級商品系統(tǒng) [3]、訂單系統(tǒng) [4]、優(yōu)惠券系統(tǒng) [5] 構(gòu)建，并完成了應(yīng)用的全部上云 [6]、自動(dòng)化測試平臺(tái)構(gòu)建 [7]。

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

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

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

為此我們一方面開始熟悉不同業(yè)務(wù)場景下的交易系統(tǒng)的現(xiàn)狀，另一方面也在技術(shù)方案上進(jìn)行著思考和討論。最終我們選擇了“以數(shù)據(jù)歸一為基礎(chǔ)，提供標(biāo)準(zhǔn)化中臺(tái)服務(wù)，從下層向上層逐個(gè)系統(tǒng)整合”的方案。

3.1 數(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ù)集中在商家、商品、訂單、促銷活動(dòng)這四個(gè)領(lǐng)域，我們結(jié)合公司交易場景的現(xiàn)狀，分別對這四個(gè)領(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、SQL Server）進(jìn)行數(shù)據(jù)加工的方式完成初期的數(shù)據(jù)同步導(dǎo)入，這也是對業(yè)務(wù)侵入最小、最快的實(shí)現(xiàn)方案。

3.2 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)起一個(gè)優(yōu)質(zhì)的系統(tǒng)，統(tǒng)一了 API 在一定程度上也就實(shí)現(xiàn)了系統(tǒng)的收口。

為此，我們遵循單一職責(zé)的原則，按照領(lǐng)域進(jìn)行區(qū)分，明確邊界，做到所有底層 API 功能原子化，便于上游使用者靈活組裝 API 完成業(yè)務(wù)邏輯，同時(shí)統(tǒng)一 API 的參數(shù)結(jié)構(gòu)和響應(yīng)結(jié)果的結(jié)構(gòu)，統(tǒng)一錯(cuò)誤碼，基于 API 網(wǎng)關(guān)統(tǒng)一發(fā)布、調(diào)用，API 的數(shù)據(jù)統(tǒng)計(jì)監(jiān)控、降級、限流實(shí)現(xiàn)統(tǒng)一管控。

3.3 API 讀寫切換

有了標(biāo)準(zhǔn)化的 API，自然需要讓業(yè)務(wù)方進(jìn)行使用才能體現(xiàn)出 API 的價(jià)值，為了防止步子邁的太大，我們也是按照業(yè)務(wù)的重要性以及量級，采用讀寫分階段的方案逐個(gè)業(yè)務(wù)進(jìn)行調(diào)用切換，看似很合理的步驟，在實(shí)際執(zhí)行過程中也暴露了很多問題：

在讀寫強(qiáng)依賴的場景，比如：用戶下單完成后馬上會(huì)跳轉(zhuǎn)到訂單詳情查看訂單，這個(gè)時(shí)候在未完成寫 API 切換的時(shí)候，由于數(shù)據(jù)同步延遲會(huì)導(dǎo)致通過讀 API 讀取數(shù)據(jù)失敗，這時(shí)就沒有辦法按照先讀后寫分階段進(jìn)行切換，最好的辦法是讀寫同時(shí)切換。對于業(yè)務(wù)切換影響最小的方式，當(dāng)然是兼容原接口的參數(shù)和返回結(jié)果，如果我們強(qiáng)加業(yè)務(wù)方按照我們標(biāo)準(zhǔn)的 API 進(jìn)行切換，勢必給業(yè)務(wù)方帶來切換成本和不必要的負(fù)作用。

這個(gè)時(shí)候我們自然要從對方的角度出發(fā)做一些取舍。我們采用的方式是在標(biāo)準(zhǔn) API 之上增加了一層適配層，用于新老協(xié)議的轉(zhuǎn)換，讓業(yè)務(wù)方只需要切換域名和請求的 URL 即可，其他邏輯不變，最大限度的做到對業(yè)務(wù)方友好。

由于我們提供的底層 API 都是原子的，但在實(shí)際場景中，尤其是前后端分離的項(xiàng)目，前端是不大愿意為了一個(gè)結(jié)果多次調(diào)用接口獲取，面對這種情況，我們也是在后端增加了一層門面層，基于底層原子 API 組合成滿足業(yè)務(wù)場景的 API 對外提供，對于差異化的接口邏輯做適度兼容。讀寫切換不可能一蹴而就，在這個(gè)過程中勢必會(huì)存在主數(shù)據(jù) API 和原業(yè)務(wù) API 并存的場景，鑒于所有 API 的入口都將由我們統(tǒng)一提供，因此我們也是采用了路由的機(jī)制，通過路由層的 location 進(jìn)行區(qū)分轉(zhuǎn)發(fā)，所有 API 做到對調(diào)用方的透明。在實(shí)際 API 切換的過程中，還有一種特殊的場景，因?yàn)樽罱K要實(shí)現(xiàn)系統(tǒng)的整合，對于那些后續(xù)會(huì)被整合掉的功能強(qiáng)行做 API 切換其實(shí)也是一種資源的浪費(fèi)，因此我們也是提前做了預(yù)判，可以適度地不做切換，等待功能整合后將整體功能進(jìn)行切換。

3.4 系統(tǒng)功能整合

在完成 API 讀寫切換之后，基于主數(shù)據(jù)的功能基本完成了聚合，此時(shí)就需要將通用功能進(jìn)行系統(tǒng)化的統(tǒng)一，比如：統(tǒng)一的商家管理后臺(tái)、統(tǒng)一的運(yùn)營后臺(tái)、統(tǒng)一的 C 端交易體驗(yàn)等，系統(tǒng)層級的統(tǒng)一整合目的是為了給使用者一個(gè)統(tǒng)一的操作界面，體現(xiàn)平臺(tái)的專業(yè)性。

在系統(tǒng)整合的過程中，我們采用了“共性沉淀，差異取舍”的原則，對于那些通用的能力，比如：商品發(fā)布、訂單列表等功能，我們會(huì)抽象出通用的能力，提供統(tǒng)一的單元化的操作界面，滿足各業(yè)務(wù)方的使用訴求。

對于業(yè)務(wù)方特有的功能，我們會(huì)建議業(yè)務(wù)方去實(shí)現(xiàn)，而對于那些目前還無法形成通用能力但未來有可能作為通用能力的功能，我們會(huì)按照 MVP 原則，用最快的方式實(shí)現(xiàn)小版本的上線，隨著業(yè)務(wù)的迭代不斷的實(shí)現(xiàn)功能沉淀。

在整個(gè)系統(tǒng)整合的過程中，必然會(huì)出現(xiàn)在整合原有系統(tǒng)功能的同時(shí)又有新需求的加入。面對這種場景，我們的采用的方式是新老系統(tǒng)同步開發(fā)，看似增加了成本，其實(shí)對于新系統(tǒng)的整合是有好處的，一方面能夠不影響業(yè)務(wù)的開展，不會(huì)因?yàn)榧夹g(shù)性的整合對業(yè)務(wù)造成停滯；另一方面可以通過新老系統(tǒng)的對比，找出新系統(tǒng)可能存在的問題，這也會(huì)是驗(yàn)證整合后的新系統(tǒng)功能的最佳途徑。

在完成絕大部分的系統(tǒng)整合工作之后，電商核心的交易鏈路已經(jīng)可以跑通，并且在線上經(jīng)歷了長時(shí)間的驗(yàn)證，從商家入駐、商品發(fā)布、商品展示、下單、支付、履約、售后，到最終的結(jié)算，期間遇到的問題也在一一化解。在這個(gè)階段我們完成了公司內(nèi) 3 大交易系統(tǒng)的整合，并進(jìn)行了電商平臺(tái)秒殺系統(tǒng) 10 萬級 QPS 的架構(gòu)升級 [8]，優(yōu)惠券系統(tǒng) 10 萬級 QPS 的架構(gòu)升級，支撐了 2020~2021 年的 818 晚會(huì)、雙 11、雙 12 等大型活動(dòng)的秒殺、發(fā)券場景。另外我們也在積極探索領(lǐng)域驅(qū)動(dòng)模型 DDD 的理論與業(yè)界實(shí)踐，并在發(fā)票總庫系統(tǒng)的重構(gòu)中進(jìn)行了落地實(shí)踐 [9]，這也為后續(xù)的平臺(tái)化架構(gòu)升級提供了技術(shù)支撐。

4. 平臺(tái)化架構(gòu)階段

在電商業(yè)務(wù)中臺(tái)繼續(xù)向業(yè)務(wù)的“逼近”過程中，系統(tǒng)的抽象和建設(shè)難度也成指數(shù)型增加，出現(xiàn)了一系列新問題：

隨著建設(shè)中臺(tái)項(xiàng)目的結(jié)束，人員的撤離，電商業(yè)務(wù)中臺(tái)在集成這么多業(yè)務(wù)線的邏輯之后，代碼里充斥著大量條件判斷，每次需求迭代的開發(fā)成本和測試回歸成本都很高，如何隔離不同業(yè)務(wù)之間的邏輯，減少業(yè)務(wù)之間的耦合度呢？如何抽象出已接入電商業(yè)務(wù)中臺(tái)的多條業(yè)務(wù)線的共性能力，避免重復(fù)建設(shè)呢？當(dāng)新業(yè)務(wù)接入電商業(yè)務(wù)中臺(tái)，如何基于已有的能力和解決方案快速組裝上線，以支撐業(yè)務(wù)快速迭代創(chuàng)新？如何能夠利用技術(shù)手段幫助產(chǎn)品運(yùn)營日常工作提效呢？

綜上所述，電商業(yè)務(wù)中臺(tái)在建設(shè)過程中抽象業(yè)務(wù)線的共性能力以及共性能力的復(fù)用性設(shè)計(jì)與實(shí)現(xiàn)尤其重要，業(yè)務(wù)中臺(tái)要做到能力復(fù)用和靈活多變才能讓中臺(tái)建設(shè)在企業(yè)的發(fā)展過程中起到降本增效的效果。系統(tǒng)架構(gòu)必須升級，這就進(jìn)入了平臺(tái)化架構(gòu)階段。

二、平臺(tái)化架構(gòu)實(shí)踐

什么是平臺(tái)化架構(gòu)？就是要把基礎(chǔ)能力跟每個(gè)業(yè)務(wù)方的特性業(yè)務(wù)拆分，要把業(yè)務(wù)和業(yè)務(wù)之間的邏輯進(jìn)行隔離。平臺(tái)化最核心的是業(yè)務(wù)抽象建模和系統(tǒng)架構(gòu)的開放性，業(yè)務(wù)抽象解決共性的 80% 問題，系統(tǒng)架構(gòu)開放性解決 20% 的個(gè)性化問題。

在參考 Thoughtworks 給出的《現(xiàn)代企業(yè)架構(gòu)白皮書》的方案 [10] 以及業(yè)界的互聯(lián)網(wǎng)公司美團(tuán) [11]、有贊 [12] 的中臺(tái)解決方案，我們給出了適合之家電商平臺(tái)的解決方案：通過領(lǐng)域驅(qū)動(dòng)建模抽象出電商業(yè)務(wù)中臺(tái)多業(yè)務(wù)線的共性能力并預(yù)留擴(kuò)展點(diǎn)，然后利用服務(wù)編排對共性能力進(jìn)行組合。其原理如圖所示:

每一個(gè)在電商業(yè)務(wù)中臺(tái)運(yùn)行的業(yè)務(wù)可以理解為：業(yè)務(wù)身份 + 業(yè)務(wù)流程 + 規(guī)則，業(yè)務(wù)流程通過流程服務(wù)編排來實(shí)現(xiàn)，擴(kuò)展點(diǎn)通過擴(kuò)展點(diǎn)機(jī)制來實(shí)現(xiàn)。在整個(gè)交易流程中 B 端的商家入駐、商品發(fā)布相對通用，不同的業(yè)務(wù)的主要流程差別體現(xiàn)在訂單收單前以及支付后的訂單履約，這些流程往往都是需要定制化開發(fā)，為此整個(gè)解決方案核心在于訂單平臺(tái)化的架構(gòu)設(shè)計(jì)。

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

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

整個(gè)訂單平臺(tái)化架構(gòu)升級實(shí)踐過程，總結(jié)為以下幾點(diǎn)：

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

業(yè)務(wù)身份的概念最早由阿里巴巴提出，業(yè)務(wù)平臺(tái)在對各業(yè)務(wù)同時(shí)提供服務(wù)時(shí)，需要能區(qū)分每一次業(yè)務(wù)服務(wù)請求的業(yè)務(wù)身份要素，以便提供差異化個(gè)性化的服務(wù)；因此需要對企業(yè)各業(yè)務(wù)的身份和特征進(jìn)行建模和區(qū)分，其產(chǎn)出即為業(yè)務(wù)身份。業(yè)務(wù)身份具有唯一性，業(yè)務(wù)身份類似于身份證號(hào)碼一樣，需要保證在整個(gè)業(yè)務(wù)中臺(tái)上必須是唯一的。

有了業(yè)務(wù)身份業(yè)務(wù)中臺(tái)就可以針對抽象這個(gè)業(yè)務(wù)流程和業(yè)務(wù)規(guī)則，并基于業(yè)務(wù)身份實(shí)現(xiàn)服務(wù)路由、業(yè)務(wù)監(jiān)控。其次業(yè)務(wù)身份就類似 SaaS 系統(tǒng)中的租戶的概念，不同的業(yè)務(wù)方在中臺(tái)通過業(yè)務(wù)身份進(jìn)行數(shù)據(jù)權(quán)限隔離，這樣能保證各業(yè)務(wù)的運(yùn)營只能看見自己業(yè)務(wù)部分的數(shù)據(jù)。

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

2. 服務(wù)編排化

電商業(yè)務(wù)中臺(tái)整體采用微服務(wù)架構(gòu)、將整個(gè)電商系統(tǒng)拆分為商家中心、用戶中心、商品中心、促銷中心、交易中心、履約中心、售后中心。每個(gè)中心在邏輯上分成了帶有業(yè)務(wù)屬性的能力和不帶業(yè)務(wù)屬性的基礎(chǔ)能力兩層?；A(chǔ)能力層關(guān)注領(lǐng)域模型的實(shí)體屬性、行為、事件，不會(huì)隨著業(yè)務(wù)的需求調(diào)整而發(fā)生變化，聚焦于行業(yè)共性行為、收斂業(yè)務(wù)模型，保障基礎(chǔ)服務(wù)的穩(wěn)定性。帶有業(yè)務(wù)屬性的能力是在基礎(chǔ)能力層之上通過服務(wù)組合、流程編排之類的技術(shù)手段，構(gòu)成面向業(yè)務(wù)的解決方案，完成業(yè)務(wù)共性到個(gè)性化的轉(zhuǎn)變。有兩種常見的做法如下：

其一是使用硬編碼來實(shí)現(xiàn)。隨著不同業(yè)務(wù)線的邏輯不斷增加，各個(gè)業(yè)務(wù)能力調(diào)用的基礎(chǔ)能力會(huì)變得盤根錯(cuò)節(jié)，很難做到可配置、靈活化。當(dāng)發(fā)生需求變更的時(shí)候，測試人員很難評估修改的影響范圍，回歸測試的成本周期長，這樣很難真正做到敏捷開發(fā)、快速響應(yīng)業(yè)務(wù)。

其二是使用服務(wù)編排。通過服務(wù)編排現(xiàn)有微服務(wù)進(jìn)行服務(wù)組合服務(wù)，然后一次性的返回前臺(tái)需要的信息。不同業(yè)務(wù)線的能力執(zhí)行不同的流程，通過圖形化、XML、JSON 的編排框架，即可以讓流程清晰，也可以屏蔽代碼細(xì)節(jié)。

服務(wù)拆分的好處無需贅述，但是要實(shí)現(xiàn)業(yè)務(wù)價(jià)值，不是看單個(gè)服務(wù)的能力，而是要協(xié)調(diào)所有服務(wù)保證企業(yè)端到端業(yè)務(wù)流程的成功。業(yè)務(wù)中臺(tái)是企業(yè)業(yè)務(wù)的集成平臺(tái)，集成技術(shù)必須松散地耦合組成流程的應(yīng)用程序和資源，否則流程的邏輯將被硬編碼到特定的技術(shù)平臺(tái)中，更改可能代價(jià)高昂，從而違背業(yè)務(wù)流程復(fù)用的整個(gè)目標(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ù)中臺(tái)的服務(wù)編排，最終我們選用 Apache Camel [18] 做為服務(wù)編排的底層引擎進(jìn)行二次封裝開發(fā)。

Apache Camel 誕生于 2007 年，2009 年前后成為 Apache 頂級項(xiàng)目更名為 Apache Camel，目前最新版本是 3.0。Apache Camel 的優(yōu)點(diǎn)在于在發(fā)布后十多年的時(shí)間里，已經(jīng)擁有三百多種擴(kuò)展組件；擴(kuò)展機(jī)制也極其方便和靈活；通過開箱即可用的最佳實(shí)踐來解決應(yīng)用集成問題；它基于事件驅(qū)動(dòng)的架構(gòu)，有著良好的性能和吞吐量 [19]。

以下是一個(gè)簡單的服務(wù)流程編排樣例：

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

擴(kuò)展點(diǎn)框架

擴(kuò)展點(diǎn)的全稱是 Service Provider Interface，簡稱為 SPI。是 Java 提供的一套用來加載和運(yùn)行第三方擴(kuò)展的接口實(shí)現(xiàn)類的機(jī)制，一般用在組件替換和框架擴(kuò)展的場景。SPI 將服務(wù)接口與服務(wù)實(shí)現(xiàn)分離以達(dá)到解耦、提升了應(yīng)用程序的可擴(kuò)展性。在程序設(shè)計(jì)中，模塊之間采用面向接口編程而不做具體的實(shí)現(xiàn)類引用，通過動(dòng)態(tài)加載實(shí)現(xiàn)類達(dá)到應(yīng)用程序的插件化。

COLA 框架是阿里巴巴技術(shù)專家提出的一種應(yīng)用架構(gòu)的擴(kuò)展點(diǎn)框架 [20]。COLA 框架的擴(kuò)展是通過注解的方式來實(shí)現(xiàn)的，Extension 擴(kuò)展注解里面使用用例（useCase）、業(yè)務(wù)（bizId）、場景（scenario）三個(gè)屬性用來標(biāo)識(shí)身份。使用 COLA 框架的擴(kuò)展點(diǎn)可以在代碼層面支持不同業(yè)務(wù)身份的邏輯隔離，因?yàn)椴煌倪壿嫹稚⒃诓煌膶?shí)現(xiàn)類里面，符合軟件設(shè)計(jì)的開閉原則。

COLA 框架在應(yīng)用 Spring 上下文初始化完畢階段，開始掃描帶有 Extension 注解的 bean 進(jìn)行擴(kuò)展點(diǎn)注冊，以 Map 的結(jié)構(gòu)存儲(chǔ)，Key 是 useCase、bizId、scenario 的字符串拼接，value 是該 bean。

在運(yùn)行時(shí)，通過業(yè)務(wù)身份定位擴(kuò)展點(diǎn)實(shí)現(xiàn)類，然后執(zhí)行擴(kuò)展點(diǎn)實(shí)現(xiàn)的邏輯。定位擴(kuò)展點(diǎn)支持三層路由，首先會(huì)按照 useCase+bizId+scenario 找擴(kuò)展點(diǎn)實(shí)現(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ò)展點(diǎn)機(jī)制，業(yè)務(wù)中臺(tái)就可以從業(yè)務(wù)身份和框架層面實(shí)現(xiàn)對不同的業(yè)務(wù)的管理，像 SaaS 管理租戶一樣管理業(yè)務(wù)，不同業(yè)務(wù)身份在不同場景下對預(yù)定義的擴(kuò)展點(diǎn)進(jìn)行擴(kuò)展。阿里巴巴的業(yè)務(wù)中臺(tái)也正是基于擴(kuò)展點(diǎn)的思想，實(shí)現(xiàn)的核心業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)的分離和解耦，共享事業(yè)部才能對集團(tuán)內(nèi)幾百條業(yè)務(wù)線進(jìn)行支撐的。

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

在驗(yàn)證功能后對電商交易系統(tǒng)的的場景進(jìn)行了分類，首先選取用戶感知度小、即使出問題也對用戶影響最小的節(jié)點(diǎn)進(jìn)行重構(gòu)試用，如未支付訂單超時(shí)關(guān)閉、用戶取消訂單。

以用戶取消訂單場景為例，在修改前各業(yè)務(wù)的用戶取消訂單的邏輯為修改訂單狀態(tài)為已取消狀態(tài)然后執(zhí)行同一個(gè)流程，流程的執(zhí)行順序?yàn)橛簿幋a，偽代碼如圖所示：

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

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

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

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

在平臺(tái)化架構(gòu)實(shí)踐中我們將那些影響業(yè)務(wù)流轉(zhuǎn)的核心配置統(tǒng)一提取出來，并按照業(yè)務(wù)身份進(jìn)行屬性值的配置，確保整個(gè)交易流程鏈路的標(biāo)準(zhǔn)統(tǒng)一，減少對交易核心鏈路代碼的頻繁修改，不同業(yè)務(wù)根據(jù)不同的屬性值在相同的交易流程中的不同節(jié)點(diǎn)進(jìn)行靈活切換。

比如：商品是否自動(dòng)推送到資源池、下單是否需要填寫身份證、支付成功是否推送線索、超過 N 天未確認(rèn)收貨是否自動(dòng)確認(rèn)收貨完成等等，所有配置項(xiàng)均通過配置管理后臺(tái)進(jìn)行統(tǒng)一維護(hù)。此外，對于電商中臺(tái)中包括業(yè)務(wù)身份在內(nèi)的所有元數(shù)據(jù)，我們也通過配置管理后臺(tái)進(jìn)行了統(tǒng)一的管理并提供統(tǒng)一的 API 對外提供查詢服務(wù)。

4. 開發(fā)工具化

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

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

電商系統(tǒng)的性能指標(biāo)、資源利用率指標(biāo)、調(diào)用量等系統(tǒng)維度的指標(biāo)通過公司云平臺(tái)能夠?qū)崿F(xiàn)統(tǒng)一的監(jiān)控，對于業(yè)務(wù)數(shù)據(jù)同理，我們需要提供統(tǒng)一的業(yè)務(wù)數(shù)據(jù)可視化工具，為業(yè)務(wù)方提供做相關(guān)決策的參照依據(jù)。

為此，我們采用實(shí)時(shí) + 離線的方式開發(fā)了訂單可視化大屏系統(tǒng)，通過這個(gè)系統(tǒng)能夠按照業(yè)務(wù)線、訂單狀態(tài)、區(qū)域等多個(gè)維度實(shí)時(shí)監(jiān)控訂單量的變化情況。如果固定時(shí)間段內(nèi)的訂單量波動(dòng)超過了我們事先配置的閾值，還會(huì)發(fā)送釘釘消息及時(shí)通知業(yè)務(wù)方關(guān)注。

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

6. 知識(shí)沉淀

我所在的這個(gè)團(tuán)隊(duì)在公司內(nèi)部的電商領(lǐng)域是一個(gè)專業(yè)的團(tuán)隊(duì)，多年來積累了很多技術(shù)以及產(chǎn)品運(yùn)營層面的經(jīng)驗(yàn)。在整個(gè)電商中臺(tái)的建設(shè)過程中，我們也是將這些經(jīng)驗(yàn)以及日常問題的解決辦法，作為一種財(cái)富不斷的沉淀，以往都是采用 wiki 這種文檔管理工具進(jìn)行匯總。

為了能夠讓這些知識(shí)產(chǎn)生價(jià)值，我們也開始搭建自己的電商知識(shí)庫系統(tǒng)，將所有能夠作為知識(shí)沉淀的內(nèi)容，按照不同的領(lǐng)域分類錄入到知識(shí)庫系統(tǒng)內(nèi)，整套知識(shí)庫對外提供了快速檢索和定位的功能，能夠服務(wù)于技術(shù)人員、產(chǎn)品運(yùn)營人員，進(jìn)一步培養(yǎng)大家知識(shí)積累的意識(shí)，提升大家的工作效率。

三、尾聲

二十年前，互聯(lián)網(wǎng)剛開始在中國流行，信息都是通過資訊的方式展示，幾乎沒有在線交易；十年前，互聯(lián)網(wǎng)經(jīng)過快速發(fā)展，消費(fèi)者可以在淘寶、天貓、京東為代表的在線商城上購買自己需要或喜歡的商品進(jìn)行在線交易；而如今各種電商形態(tài)不斷涌現(xiàn)，已成百花齊放的趨勢，比如內(nèi)容電商小紅書、興趣電商抖音快手，社交電商微商、拼多多等，會(huì)員電商天貓 88vip、京東 plus 等。這些在線交易形態(tài)充分證明了電商在互聯(lián)網(wǎng)領(lǐng)域流量變現(xiàn)的重要一環(huán)，已經(jīng)成為互聯(lián)網(wǎng)企業(yè)基礎(chǔ)設(shè)施的水電煤。

電商中臺(tái)的建設(shè)不光是一個(gè)技術(shù)體系的搭建，也是一個(gè)組織結(jié)構(gòu)重新塑造的過程。但是隨著時(shí)間的推移，中臺(tái)其價(jià)值的增長空間會(huì)愈發(fā)狹窄，這就需要有意識(shí)的尋找創(chuàng)新點(diǎn)，突破現(xiàn)有系統(tǒng)的邊界，跨界思考，于是我們也開始與前臺(tái)業(yè)務(wù)走的更近，積極開展對新業(yè)務(wù)探索和技術(shù)架構(gòu)升級。

1. 探索新零售

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

通過升級電商系統(tǒng)的現(xiàn)有能力，商品支持了 SKU 選配，訂單支持大小定金組合支付、退款，新增交付系統(tǒng)，為工業(yè)協(xié)會(huì)定制車業(yè)務(wù)、汽車新零售線下店的業(yè)務(wù)提供了業(yè)務(wù)支持。未來還會(huì)繼續(xù)打造業(yè)界對齊的新能源選配價(jià)格浮動(dòng)模式以及商品可選配套的服務(wù)包模式。

2. 架構(gòu)升級

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

引用

[1] 盤點(diǎn)：2010-2020 年互聯(lián)網(wǎng)的十大戰(zhàn)役

[2] 汽車之家：從“吸引眼球”向“電商平臺(tái)”拓展

[3] 之家學(xué)宮: 汽車電商商品系統(tǒng)構(gòu)建實(shí)踐

[4] 之家學(xué)宮: 百萬級汽車電商交易系統(tǒng)構(gòu)建之路

[5] 之家技術(shù): 高可用紅包系統(tǒng)構(gòu)建實(shí)戰(zhàn)

[6] 之家技術(shù): 電商技術(shù)團(tuán)隊(duì)云原生實(shí)踐

[7] 之家技術(shù): 新車電商測試數(shù)據(jù)自動(dòng)化實(shí)踐

[8] 之家技術(shù): 電商秒殺系統(tǒng)的系統(tǒng)架構(gòu)

[9] 之家技術(shù): 汽車之家發(fā)票總庫 DDD 實(shí)踐

[10] ThoughtWorks: 現(xiàn)代企業(yè)架構(gòu)白皮書

[11] 美團(tuán): 業(yè)務(wù)中臺(tái)之訂單平臺(tái)化建設(shè)實(shí)踐

[12] 有贊: 中臺(tái)如何助力標(biāo)準(zhǔn)化業(yè)務(wù)

[13] 吳潤. 基于 API 網(wǎng)關(guān)的微服務(wù)組合策略研究 [J]. 數(shù)碼世界,2019(03):84-86.

[14] 辛園園, 李俊暉, 李陣. 微服務(wù)組合方法研究進(jìn)展 [J]. 無線通信技術(shù),2018,27(03):42-46.

[15] 楊光.Activiti 工作流框架在 OA 系統(tǒng)中的應(yīng)用 [J]. 電子設(shè)計(jì)工程,2021,29(11):65-69.

[16] Conductor 官方網(wǎng)站. Conductor 官方文檔 [EB/OL].

[17] Zeebe. Zeebe 源碼 [EB/OL].

[18] Apache Camel 官方網(wǎng)站. Apache Camel 官方文檔 [EB/OL].

[19] Amaral C J , Bernardes S P , M Concei??o, et al. Finding new routes for integrating Multi-Agent Systems using Apache Camel. 2019.

[20] COLA 應(yīng)用架構(gòu)的最佳實(shí)踐

作者介紹

方利 汽車之家高級研發(fā)工程師

2016 年加入汽車之家，先后負(fù)責(zé)過電商 ERP 系統(tǒng)、商家系統(tǒng)、線索系統(tǒng)、訂單中心、AIDCC 的研發(fā)和架構(gòu)，現(xiàn)主要負(fù)責(zé)電商交易系統(tǒng)的整體技術(shù)架構(gòu)升級和業(yè)務(wù)處理等工作。

以上就是【原創(chuàng)不看后悔（互聯(lián)網(wǎng)汽車后市場是什么意思）商用車后市場互聯(lián)網(wǎng)公司-汽車之家電商系統(tǒng)架構(gòu)演進(jìn)與平臺(tái)化架構(gòu)實(shí)踐】的全部內(nèi)容。