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

特别感谢：杨广兴、张然、姬英泽、赵宁、张彤，在系统建设过程中的贡献。

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 年的建设与推广使用，已经完成了系统的基本能力建设，通过配置化能满足多数交易场景的数据接入需求。但是对于运营效率提升、数据核对与告警等需求支持的还不完善，为了更好的发挥系统价值，进一步提升运营效率，交易履约订单中心有以下几个方面的规划：

完善配置化功能：优化配置页面交互方式，降低使用门槛、提高运营效率。

提升稳定性：建立熔断机制、应急响应机制等。

提升数字化能力：建设支持更多维度的数据看板、建立数据核对与告警机制。

交易履约之订单中心实践相关推荐

交易履约之结算平台实践
导读京东科技业务在快速发展的同时,产生了众多线上化资金结算的需求.传统的线下资金结算模式有着人力成本高.耗时长.多方沟通协调成本高.结算准确率低等固有缺点,且无法满足"风法财审" ...
电商交易之订单中心设计（一）
背景在电商交易中台团队工作了一段时间,越发觉自己需要学习的东西还有很多,因此想要定期整理.反思一下所见.所想,因此先从接触的订单中心开始. 订单是什么,我所理解,订单就是交易行为的记录.是用户某一刻 ...
电商交易之订单中心设计（二）
背景上篇说过订单基础设计,介绍了订单中心应该有哪些能力,大概有哪些字段,还有容量上的处理.上篇有点像在讲订单的数据模型,这篇来看看订单的业务模型. 价格模型订单的价格怎么计算得来?普通电商平台用户 ...
电商订单中心业务梳理
订单中心是一个电商后台系统的枢纽,在这订单这一环节上需要读取多个模块的数据和信息进行加工处理,并流向下一环节:因此订单模块对一电商系统来说,重要性不言而喻. 同时,订单是一个公司生存甚至盈利的核心,而 ...
阿里“三活”数据中心实践经验：没人能做，我们就自己做
阿里"三活"数据中心实践经验:没人能做,我们就自己做发表于2015-10-29 18:11| 4813次阅读| 来源CSDN| 4 条评论| 作者郭雪梅阿里云数据中心运维多活数 ...
Java生鲜电商平台-订单中心服务架构与异常订单逻辑
Java生鲜电商平台-订单中心服务架构与异常订单逻辑订单架构实战中阐述了订单系统的重要性,并从订单系统的信息架构和流程上对订单系统有了总体认知,同时还穿插着一些常见的订单业务规则和逻辑.上文写到订单 ...
TiDB 在北京银行交易场景中的应用实践
作者介绍:陈振东,北京银行软件开发部北京银行是一家城市商业银行,公司价值位列中国区域性发展银行的首位,依托于中国经济的大环境,北京银行的资产总量在全球千家大银行中名列第 61 位,连续六年跻身全球银 ...
12月31日起涉线上支付的微信小程序需设置订单中心页
微信公众平台运营中心发布公告:为进一步规范小程序交易生态.提升用户购物体验.满足用户在有交易的小程序中便捷查看订单信息的诉求,自 2022 年 12 月 31 日起,对于有"选择商品/服务- ...
订单中心探索业务系统数据预置助力快交付之路
01 "一个哈姆雷特式的问题" "业务系统"归根结底是支撑企业达成其某类业务目标所需要的业务过程和管理过程的功能合集,如客户管理系统.产商品管理系统.订单系统等 ...

交易履约之订单中心实践