本文作者：京東科技-市場與平臺運營中心-平臺研發部，晏銀喜、張學君、袁寶龍、高傳江、楊迎心、遊斌平、付達。

特別感謝：楊廣興、張然、姬英澤、趙寧、張彤，在系統建設過程中的貢獻。

1、概述

1.1 交易履約是什麼？

首先定義下什麼是交易履約，交易履約是在甲乙雙方達成交易產生訂單後，乙方按照訂單條款為甲方提供服務或交付約定物的行為。

1.2 交易履約訂單中心是個什麼系統？

交易履約訂單中心為履約行為提供必要的系統能力支撐，交易履約訂單中心記錄了交易流通的過程和狀態，包括交易主體、產品資訊、成交金額、計費、支付、業務資訊等全流程資訊，為上下游提供資料標準化、全集資料查詢和串聯流程的功能。目前已接入的場景有：京音業績匹配、交易資料看板、京音線上化結算、 交易流程串聯等。目前交易履約訂單中心年訂單量 1.5 億+，在電銷、企微、金店、開放平臺、使用者增長等場景下，有效支援了消金、財富、保險、支付、分期商城等各大業務線的線上、線下的業務發展。

2、名詞解釋

資料來源：交易資料的來源，包含業務資訊、聯絡人、資料接入協定等。

訂單模版：交易履約訂單中心採用泛化的格式儲存交易資料，針對每個交易場景設定一個訂單模版，模版上設定對映規則來解析資料。

跟單：履約訂單中心接收滿足某些條件的交易資料。

補單：當資料來源的資料不完整或不滿足業務場景需求，履約訂單中心請求外部介面來補充交易資料。

推播模版：履約訂單中心將交易資料推播到下游系統。

3、設計實現

3.1 整體架構

整體架構主要分成四個部分（如下圖的藍色部分），依據高內聚、低耦合的設計原則，每個分層只專注處理自己的業務邏輯，分層之間通過 MQ 訊息驅動資料流轉。

接收層：負責接收上游產品層的交易資料，目前支援 MQ 訊息和傑夫介面兩種協定。

資料處理層：負責對資料進行解析、冪等判斷、交易時序判斷、補充資料完整性、對映訂單模型等。

資料推播層：負責對資料按照指定的規則格式化、推播到下游系統，目前支援 MQ 和傑夫兩種協定。

查詢服務：負責資料的查詢和匯出。

3.2 業務接入設定化

經過對整體架構的設計和抽象以後，我們發現各個業務線的資料處理流程具有高度的一致性：資料接收、資料處理、資料推播，而在不同的業務線產品的交易場景下會存在一些特定的差異，比如，只接收滿足某些條件的交易資料、金條借款的訂單與基金購買的訂單模型不同、只有滿足某些條件的資料才推播給結算系統等。為了提高業務的接入效率、降低接入成本，我們抽象了一套通用的資料處理流程，流程中的分支通過條件表示式來識別，同時提供一套完整的設定化頁面供產品和運營同學使用，最終實現了業務接入設定化、自助化，如下圖：

3.2.1 設定資料來源和訂單模版

資料接收層通過設定的資料來源協定編碼路由到訂單模版，不同的業務產品交易場景會設定不同的訂單模版。

3.2.2 設定模版內容

在資料的處理環節，我們要解決不同資料來源的資料解析、模型對映、冪等判斷、時序判斷等問題，不同來源的差異化我們通過設定化來支援，如下圖所示的設定內容，將要解析的資料設定成 JsonPath，資料處理程式通過讀取欄位型別是「交易單號」的設定，來解析交易單號並完成冪等判斷；通過讀取「交易時間」的設定，來解析並完成資料時序的判斷。

Fastjson 1.2.0 之後的版本支援 JSONPath，可以在 java 框架中當作物件查詢語言（OQL）來使用。

// 解析貸款單號
Object loanId = JSONPath.extract(jsonStr, "$.jt_df_success.loanId");
// 解析還款單號
Object loanNo = JSONPath.extract(jsonStr, "$.jt_repayment.taskData.loanNo");

3.2.3 設定表示式

前面提到過，在通用的資料流程中存在這樣的分支流程：當滿足一定條件時做某些事情，具體的條件根據業務場景的訴求確定，要做的事情是可以列舉和抽象的，比如過濾訂單訊息或者呼叫某個服務等。這種場景類似於一個輕量級的規則引擎，我們通過開源的 MVEL 類庫來實現這個表示式引擎（特點：靈活、效能高、無型別限制）。下圖所示為一個過濾訊息的設定範例：

MVEL 類庫在訂單中心主要的應用場景是對預設定的表示式進行邏輯運算。

 Object result = MVEL.executeExpression("$actExt3$=='SECOBT_JD'&&$accountType$==21", context);

3.3 業務交易明細看板設定化

我們提供了通用的資料查詢介面和通用的查詢頁面，來滿足資料檢索的訴求。針對不同業務產品的交易場景，下游系統都有個性化的查詢訴求，比如那些欄位需要作為查詢條件、哪些欄位要在列表頁展示、哪些欄位需要匯出等，類似這樣的個性化訴求我們一樣是通過設定化來支援的，如下圖的設定範例所示：

通用的查詢頁面通過切換業務線來聯動更新查詢條件和列表欄位：

3.4 業務資料推播設定化

我們也具備將上游產品層的資料轉發給下游系統的能力，目前支援傑夫介面和 MQ 訊息兩種協定，針對下游介面標準不統一的情況，我們同樣通過設定化的方式來支援：

下游介面的欄位可以靈活設定，推播程式執行時解析推播設定，以交易資料為上下文組裝推播引數，泛化呼叫下游介面。

4、規劃

交易履約訂單中心經過 2 年的建設與推廣使用，已經完成了系統的基本能力建設，通過設定化能滿足多數交易場景的資料接入需求。但是對於運營效率提升、資料核對與告警等需求支援的還不完善，為了更好的發揮系統價值，進一步提升運營效率，交易履約訂單中心有以下幾個方面的規劃：

完善設定化功能：優化設定頁面互動方式，降低使用門檻、提高運營效率。

提升穩定性：建立熔斷機制、應急響應機制等。

提升數位化能力：建設支援更多維度的資料看板、建立資料核對與告警機制。