架構師教你：如何實現兩個完全獨立閉環業務系統的融合。

本篇文章講述的是京東服務市場和京麥服務市場融合的專案內容，兩個系統完全是獨立的閉環業務系統，都有自己完整的服務商流程、服務釋出（服務類商品）流程、訂單支付流程等，如何實現兩個系統的融合，是我們面臨的最大挑戰，期間有過多版方案的爭吵，最終的實現也是曲折的。

梳理系統

首先對服務市場和外掛市場進行了系統的功能梳理，並對頁面、功能、流程、資料的融合進行了架構拆解。

最終架構

在明確系統融合的大方針之後，就是進入融合流程的細節討論，其中主要包括如下幾個環節：

資料的融合：完成底層服務商、服務（細分版本、模組，按模組）、訂購、訂單、結算、退款資料融合

流程的融合：完成訂單訂購流程、交易支付流程、服務釋出稽核流程、結算流程、發票流程、退款流程、取消訂單流程、評價評分流程、服務搜尋流程融合

功能的整合/遷移：服務商後臺完成服務管理、交易管理、結算管理、運營管理、資訊管理、合同管理功能遷移，運營後臺完成服務管理（服務、訂單、訂購管理、退款、發票管理）、結算管理（結算明細、結算對賬）、基礎管理（work管理）功能遷移

對外服務改造：完成伺服器啟動流程改造，前後端分離架構改造

服務融合

1. 服務釋出稽核流程融合

原流程 服務商後臺ifw釋出服務到服務市場後提供服務，服務商工作臺isv釋出服務到外掛市場提供服務，兩套服務釋出流程一樣相互獨立。

過渡方案 服務融合上線後，在服務商後臺ifw點選發布釋出服務時，重定向到服務商工作臺isv，由此實現釋出入口的統一。但由於上游應用流程未融合，所以會出現兩個地方建立應用一個地方釋出服務，所以對於外掛市場建立的應用在釋出服務時，要新增單邊流程的雙寫機制，這裡的雙寫是指在釋出服務時判斷是外掛市場的時候，不僅要寫入服務市場資料庫，也要回源外掛市場的資料庫。

最終方案 關閉服務商後臺的入口，只有服務商工作臺的入口可以釋出服務。同時在上游應用流程融合完畢之後，對外掛市場雙寫流程下線，由商品中臺統一對前臺提供服務查詢。

2. 評價評分流程融合

原流程服務市場檢視、釋出評論直接訪問服務市場資料庫；服務商後臺對商家評論進行回覆直接訪問服務市場資料庫。外掛市場評論評分功能已關閉。

過渡方案服務市場檢視、釋出評價流程不變；服務商後臺對商家評論時重定向服務商工作臺，在服務商工作臺進行評價回覆，評價呼叫商品中臺寫入服務市場資料庫。

最終方案服務市場前臺檢視、釋出評價資訊也呼叫商品中臺進行資料庫操作。

3. 服務搜尋流程融合

溫馨提示：java專業交流群  705194503

原流程服務搜尋的邏輯是通過定時任務，先查詢服務市場和外掛市場資料庫的商品資料，進行資料組裝後寫入快取和Solr，從而提供給前臺列表頁和單品頁的服務查詢。服務市場和外掛市場是有兩個定時任務單獨執行。

過渡方案將兩個定時任務合併為一個，在商品資料融合後，統一查詢新商品庫獲取原服務市場和外掛市場的所有商品資料，而每個服務商品的使用（訂購）人數則通過呼叫訂購履約中臺進行查詢，最後通過資料組裝寫入服務市場Solr，對外提供統一查詢服務。

最終方案將Solr改為Es。

交易融合

溫馨提示：java專業交流群  705194503

1. 訂單訂購流程融合

原流程 服務市場訂購訂單寫服務市場資料庫，從服務市場資料庫提供服務；外掛市場訂單訂購寫外掛市場資料庫，從外掛市場資料庫提供服務。兩個流程完全獨立。

過渡方案 由於服務市場和外掛市場融合切換是無縫的（不能停服務），且兩側訂購、訂單資料結構又不完全一致，同時資料切流又是逐步放量。所以訂購、訂單流程的融合採用資料庫雙寫的方式，所謂雙寫方式，是在寫原服務市場資料庫和外掛市場資料庫時，通過訂閱Binlog，使用BinLake框架訂閱寫入sql再整理資料寫入新資料庫。最終所有服務通過呼叫新庫進行查詢服務。

這種雙寫機制可以很好的進行回滾，當新流程出現問題的時候，可以切回到老資料庫進行降級。當新訂購流程出現問題時，也可以通過關閉切流控制影響範圍，採用老流程進行訂購訂單處理流程。

最終方案 在完成訂購、訂單完成切流之後，去掉雙寫流程，統一由訂購履約中臺提供前臺、後臺等服務呼叫。同時，外掛市場服務整體下線。屆時，商品資料統一由商品中臺提供服務，支付能力由支付中心提供。

2. 結算流程融合

溫馨提示：java專業交流群  705194503

原流程結算流程有些複雜，簡單講一筆訂購會產生一筆訂單，一筆訂單會產生三筆正向結算單，一筆退款會產生三筆逆向結算單。三筆結算單包括服務費、貨款和佣金，其中服務費是商家向京東結算，貨款是京東向服務商結算，佣金是服務商向京東結算。服務市場結算資料寫入服務市場資料庫，外掛市場結算資料寫入外掛市場資料庫。

過渡方案 服務市場和外掛市場結算單資料通過BinLake雙寫到新結算資料庫，同訂購訂單雙寫模式相同，最終由新資料庫提供結算單統一查詢服務。其中服務市場運營後臺的退款功能，隨著切流遷移呼叫支付中心進行逆向結算，切流結算資料寫入外掛市場資料庫，通過BinLake雙寫到新結算資料庫。

最終方案 外掛市場下線，去掉結算雙寫流程。訂購訂單和退款融合呼叫訂購履約中臺，由訂購履約中臺呼叫支付中心進行結算，結算資料寫入新結算資料庫，對外統一提供服務。

3. 退款流程融合

原流程退款業務原只有服務市場支援，外掛市場不支援。發起退款一是由ISV發起，另一個是運營發起，由運營稽核後，在運營後臺實現退款業務，退款呼叫下游京米或POP結算進行逆向結算，結算單資料寫入服務市場資料庫，退款單資料寫入服務市場資料庫。

過渡方案融合完畢之後，需要對外掛市場融合的服務支援退款業務。服務商工作臺和運營後臺發起退款，統一改呼叫支付中心完成逆向結算的業務，由運營後臺生成結算單和退款單。

最終方案 將退款業務整合到訂購履約中臺，支付結算能力下沉到支付中心，退款業務通過呼叫支付中心生成逆向結算單，並呼叫後端服務完成退款逆向結算業務，在訂購履約中臺生成退款單，實現整體業務解耦。

4. 取消訂單流程融合

溫馨提示：java專業交流群  705194503

原流程服務市場取消訂單先修改服務市場資料訂單狀態為完成，後直接呼叫下游完成訂單取消。外掛市場取消訂單先通過呼叫支付中心完成訂單取消，後非同步接收支付中心成功訊息後再並修改外掛市場資料訂單狀態為完成，兩個流程完全不同且獨立。

過渡方案服務市場取消訂單改造先修改服務市場資料訂單狀態為完成，後呼叫支付中心完成訂單取消流程；外掛市場取消訂單流程不變。服務市場和外掛市場各自寫入各自資料庫，通過訂閱BinLake同步更新服務市場新資料庫。

最終方案外掛市場入口下線，服務市場先呼叫訂購履約中臺進行取消訂單，中臺呼叫支付中心進行取消訂單，通過接收非同步成功訊息修改服務市場資料庫訂單狀態。

5. 發票流程融合

（1）建立發票流程融合

原流程發票在訂單訂購過程中產生，服務市場寫入服務市場資料庫，外掛市場通過支付中心寫入外掛市場資料庫，兩個流程完全獨立。

過渡方案服務市場隨訂單切流呼叫訂購履約中臺，中臺呼叫支付中心建立發票寫入外掛市場資料庫；未切流訂單依舊寫入服務市場資料庫，通過雙寫訂閱BinLake同步寫入新資料庫，對外提供統一服務。

最終方案外掛市場會下線，服務市場作為唯一入口，在訂購訂單過程中，由訂購履約中臺呼叫支付中心建立發票資訊寫入新資料庫中。

（2）查詢發票流程融合

原流程服務市場、服務商後臺、運營後臺查詢發票會直接讀取服務市場資料庫進行查詢，服務商工作臺查詢發票會直接讀取外掛市場資料庫，兩個系統完全獨立。

過渡方案服務商後臺發票功能遷移服務商工作臺，與服務市場和運營後臺一起改造查詢發票時，通過呼叫訂購履約中臺查詢訂單，由中臺呼叫支付中心查詢發票資訊，在支付中心區分是服務市場訂單或外掛市場訂單，查詢服務市場資料庫發票或外掛市場資料庫發票。

最終方案 隨著訂單切流完畢，發票資料融合完畢，支付中心查詢發票資訊統一從新資料庫進行查詢。

對外服務改造

1. 服務啟動流程改造

由於融合專案涉及到端的服務啟動，那麼對這些服務的改造也是非常關鍵的一部分，原業務邏輯是服務市場前臺（Web）直接呼叫後端服務啟動，而服務要在客戶端（App）內啟動，這些規則、業務、玩法會根據不同場景而不同，所以這些業務放在商品中臺是不合適的，所以新搭建一個系統叫服務引擎，它不涉及資料，而僅是對業務、規則、玩法的加速和處理。由引擎提供不同端的服務支撐。

2. 前後臺分離架構改造

前後臺分離的架構設計是解決H5載入效能慢的問題，技術實現包括jsonp和nginx跳轉，對比之後採用nginx，因為jsonp會產生額外的安全問題。當前端訪問nginx時，根據請求路徑判斷是html資源請求時，則通過nginx的pass_proxy重定向到前端的nginx，由前端nginx去請求html資源，否則直接請求後端服務。與cdn不同的是，前端ngnx是由前端域名，但前端域名是不會暴露給前端。

總結

服務市場系統的技術域側重在質，要求高可用的資料服務穩定性，以及資料一致性。由於是交易系統，資料流的異常會造成資金流的極大問題，如服務費、佣金和貨款等收支不一致等。這有別於之前做閘道器係統，技術域側重於量，要求高併發、高負載、高可用，即無論如何請求都不能造成閘道器係統的癱瘓。而服務市場更多的是服務治理和架構治理。