共计 2354 个字符，预计需要花费 6 分钟才能阅读完成。
本文作者：京东科技 - 市场与平台经营核心 - 平台研发部，晏银喜、张学君、袁宝龙、高传江、杨迎心、游斌平、付达。
特别感谢：杨广兴、张然、姬英泽、赵宁、张彤，在零碎建设过程中的奉献。
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 年的建设与推广应用，曾经实现了零碎的根本能力建设，通过配置化能满足少数交易场景的数据接入需要。然而对于经营效率晋升、数据核查与告警等需要反对的还不欠缺，为了更好的施展零碎价值，进一步晋升经营效率，交易履约订单核心有以下几个方面的布局：
欠缺配置化性能： 优化配置页面交互方式，升高应用门槛、进步经营效率。
晋升稳定性： 建设熔断机制、应急响应机制等。
晋升数字化能力： 建设反对更多维度的数据看板、建设数据核查与告警机制。
