【提升團隊運營效率】交易履約之訂單中心實踐

語言: CN / TW / HK

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

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

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

完善配置化功能:優化配置頁面互動方式,降低使用門檻、提高運營效率。

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

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