【提升團隊運營效率】交易履約之訂單中心實踐
本文作者:京東科技-市場與平臺運營中心-平臺研發部,晏銀喜、張學君、袁寶龍、高傳江、楊迎心、遊斌平、付達。
特別感謝:楊廣興、張然、姬英澤、趙寧、張彤,在系統建設過程中的貢獻。
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 年的建設與推廣使用,已經完成了系統的基本能力建設,通過配置化能滿足多數交易場景的資料接入需求。但是對於運營效率提升、資料核對與告警等需求支援的還不完善,為了更好的發揮系統價值,進一步提升運營效率,交易履約訂單中心有以下幾個方面的規劃:
完善配置化功能:優化配置頁面互動方式,降低使用門檻、提高運營效率。
提升穩定性:建立熔斷機制、應急響應機制等。
提升數字化能力:建設支援更多維度的資料看板、建立資料核對與告警機制。
- 交易履約之產品中心實踐
- 如何實現雲資料治理中的資料安全?
- 作為移動開發你不能不瞭解的編譯流程
- 基於Kafka和Elasticsearch構建實時站內搜尋功能的實踐
- 在京東如何做好前端系統的可觀測性
- 【微電平臺】-高併發實戰經驗-奇葩問題解決之旅
- 測試的底層邏輯
- 震驚,一行MD5居然讓小夥伴都回不了家!!!
- 聯邦學習開源框架FATE架構
- @Transaction註解的失效場景
- @Transaction註解的失效場景
- 文盤Rust -- 安全連線 TiDB/Mysql
- JRC Flink流作業調優指南
- 震驚,一行MD5居然讓小夥伴都回不了家!!!
- 【NLP系列】Bert詞向量的空間分佈
- 交易系統之資料庫弱依賴解決方案
- 可插拔元件設計機制—SPI
- ElasticSearch必知必會-Reindex重建索引
- 京東小程式CI工具實踐
- 如何規避MyBatis使用過程中帶來的全表更新風險