本文作者：京東科技-市場與平臺運營中心-平臺研發部，晏銀喜、張學君、袁寶龍、高傳江、楊迎心、遊斌平、付達。
特別感謝：楊廣興、張然、姬英澤、趙寧、張彤，在系統建設過程中的貢獻。
1、概述
1.1 交易履約是什麼？
首先定義下什麼是交易履約，交易履約是在甲乙雙方達成交易產生訂單後，乙方按照訂單條款為甲方提供服務或交付約定物的行為。
1.2 交易履約訂單中心是個什麼系統？
交易履約訂單中心為履約行為提供必要的系統能力支撐，交易履約訂單中心記錄了交易流通的過程和狀態，包括交易主體、產品資訊、成交金額、計費、支付、業務資訊等全流程資訊，為上下游提供資料標準化、全集資料查詢和串聯流程的功能。目前已接入的場景有：京音業績匹配、交易資料看板、京音線上化結算、 交易流程串聯等。目前交易履約訂單中心年訂單量 1.5 億+，在電銷、企微、金店、開放平臺、使用者增長等場景下，有效支援了消金、財富、保險、支付、分期商城等各大業務線的線上、線下的業務發展。
2、名詞解釋
資料來源：交易資料的來源，包含業務資訊、聯絡人、資料接入協議等。
訂單模版：交易履約訂單中心採用泛化的格式儲存交易資料，針對每個交易場景配置一個訂單模版，模版上配置對映規則來解析資料。
跟單：履約訂單中心接收滿足某些條件的交易資料。
補單：當資料來源的資料不完整或不滿足業務場景需求，履約訂單中心請求外部介面來補充交易資料。
推送模版：履約訂單中心將交易資料推送到下游系統。
3、設計實現
3.1 整體架構
整體架構主要分成四個部分（如下圖的藍色部分），依據高內聚、低耦合的設計原則，每個分層只專注處理自己的業務邏輯，分層之間透過 MQ 訊息驅動資料流轉。
接收層：負責接收上游產品層的交易資料，目前支援 MQ 訊息和傑夫介面兩種協議。
資料處理層：負責對資料進行解析、冪等判斷、交易時序判斷、補充資料完整性、對映訂單模型等。
資料推送層：負責對資料按照指定的規則格式化、推送到下游系統，目前支援 MQ 和傑夫兩種協議。
查詢服務：負責資料的查詢和匯出。
3.2 業務接入配置化
經過對整體架構的設計和抽象以後，我們發現各個業務線的資料處理流程具有高度的一致性：資料接收、資料處理、資料推送，而在不同的業務線產品的交易場景下會存在一些特定的差異，比如，只接收滿足某些條件的交易資料、金條借款的訂單與基金購買的訂單模型不同、只有滿足某些條件的資料才推送給結算系統等。為了提高業務的接入效率、降低接入成本，我們抽象了一套通用的資料處理流程，流程中的分支透過條件表示式來識別，同時提供一套完整的配置化頁面供產品和運營同學使用，最終實現了業務接入配置化、自助化，如下圖：
3.2.1 配置資料來源和訂單模版
資料接收層透過配置的資料來源協議編碼路由到訂單模版，不同的業務產品交易場景會配置不同的訂單模版。
3.2.2 配置模版內容
在資料的處理環節，我們要解決不同資料來源的資料解析、模型對映、冪等判斷、時序判斷等問題，不同來源的差異化我們透過配置化來支援，如下圖所示的配置內容，將要解析的資料配置成 JsonPath，資料處理程式透過讀取欄位型別是“交易單號”的配置，來解析交易單號並完成冪等判斷；透過讀取“交易時間”的配置，來解析並完成資料時序的判斷。
Fastjson1.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 年的建設與推廣使用，已經完成了系統的基本能力建設，透過配置化能滿足多數交易場景的資料接入需求。但是對於運營效率提升、資料核對與告警等需求支援的還不完善，為了更好的發揮系統價值，進一步提升運營效率，交易履約訂單中心有以下幾個方面的規劃：
完善配置化功能：最佳化配置頁面互動方式，降低使用門檻、提高運營效率。
提升穩定性：建立熔斷機制、應急響應機制等。
提升數字化能力：建設支援更多維度的資料看板、建立資料核對與告警機制。