本文作者:京东科技-商场与渠道运营中心-渠道研发部,晏银喜、张学君、袁宝龙、高传江、杨迎心、游斌平、付达。

特别感谢:杨广兴、张然、姬英泽、赵宁、张彤,在体系建造进程中的奉献。

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 年的建造与推广运用,现已完结了体系的根本能力建造,经过装备化能满意多数买卖场景的数据接入需求。可是对于运营功率进步、数据核对与告警等需求支撑的还不完善,为了更好的发挥体系价值,进一步进步运营功率,买卖履约订单中心有以下几个方面的规划:

完善装备化功能优化装备页面交互方式,下降运用门槛、进步运营功率。

进步稳定性:建立熔断机制、应急呼应机制等。

进步数字化能力:建造支撑更多维度的数据看板、建立数据核对与告警机制。