作者介紹
方利，汽車之家-主機廠事業部-技術部。2016年加入汽車之家，先後負責過電商ERP系統、商家系統、線索系統、訂單中心、AIDCC的研發和架構現主要負責電商交易系統的整體技術架構更新和業務處理等工作。
目錄：
一、前言
二、架構演進
- 1、起步階段
- 2、微服務階段
- 3、主資料階段
- 4、平台化架構階段
三、平台化架構實踐
- 1、業務身份化
- 2、服務編排化
- 3、業務配置化
- 4、開發工具化
- 5、資料可視化
- 6、知識沉澱
四、尾聲
- 1、探索新零售
- 2、架構更新
一、前言
汽車之家電商系統誕生在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層、精簡調用鍊、電商接入腳手架等技術手段提升業務的産品力以及營運效率。
>>>>
參考資料
- 【1】盤點：2010-2020年網際網路的十大戰役
- http://www.knowledgeatwharton.com.cn/article/7795/
- 【2】汽車之家：從“吸引眼球”向“電商平台”拓展
- http://www.knowledgeatwharton.com.cn/article/7795/
- 【3】之家學宮:汽車電商商品系統建構實踐
- https://atu.corpautohome.com/course/detail/?bs=list&id=130
- 【4】之家學宮:百萬級汽車電商交易系統建構之路
- https://atu.corpautohome.com/course/detail/?bs=list&id=122
- 【5】之家技術:高可用紅包系統建構實戰
- https://mp.weixin.qq.com/s/aEjpokspkkA861PHoNB6fw
- 【6】之家技術:電商技術團隊雲原生實踐
- https://mp.weixin.qq.com/s/9U7OViprl7CjrsYnaNUXEA
- 【7】之家技術:新車電商測試資料自動化實踐
- https://mp.weixin.qq.com/s/IfgRtG1TAEQ0NbwvlnKfEA
- 【8】之家技術:電商秒殺系統的系統架構
- https://mp.weixin.qq.com/s/YpqoWmsbBUYF84wOU74_wA
- 【9】之家技術: 汽車之家發票總庫DDD實踐
- https://mp.weixin.qq.com/s/8nSxM5lDOzexFBNErdbjWg
- 【10】ThoughtWorks:現代企業架構白皮書
- https://www.sohu.com/a/537498545_407401
- 【11】美團:業務中台之訂單平台化建設實踐
- https://mp.weixin.qq.com/s/PhBUz0_OuCR6fEAcMh0Hyg
- 【12】有贊:中台如何助力标準化業務
- https://mp.weixin.qq.com/s/ELofl-1gffA3XeFGBBC2Pw
- 【13】吳潤.基于API網關的微服務組合政策研究[J].數位世界,2019(03):84-86.
- 【14】辛園園,李俊晖,李陣.微服務組合方法研究進展[J].無線通信技術,2018,27(03):42-
- 【15】楊光.Activiti工作流架構在OA系統中的應用[J].電子設計工程,2021,29(11):65-69.
- 【16】Conductor官方網站. Conductor 官方文檔[EB/OL].
- https://netflix.github.io/conductor/.
- 【17】Zeebe. Zeebe源碼[EB/OL].
- https://github.com/camunda-cloud/zeebe
- 【18】Apache Camel 官方網站. Apache Camel官方文檔
- [EB/OL].https://camel.apache.org/docs/.
- 【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應用架構的最佳實踐
- https://blog.csdn.net/significantfrank/article/details/110934799
作者丨方利
來源丨公衆号：之家技術（ID：Autohometech）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
關于我們
dbaplus社群是圍繞Database、BigData、AIOps的企業級專業社群。資深大咖、技術幹貨，每天精品原創文章推送，每周線上技術分享，每月線下技術沙龍，每季度Gdevops&DAMS行業大會。
關注公衆号【dbaplus社群】，擷取更多原創技術文章和精選工具下載下傳