订单模版：交易履约订单中心采用泛化的格式存储交易数据，针对每个交易场景配置一个订单模版，模版上配置映射规则来解析数据。

跟单：履约订单中心接收满足某些条件的交易数据。

补单：当数据源的数据不完整或不满足业务场景需求，履约订单中心请求外部接口来补充交易数据。

     整体架构主要分成四个部分（如下图的蓝色部分），依据高内聚、低耦合的设计原则，每个分层只专注处理自己的业务逻辑，分层之间通过 MQ 消息驱动数据流转。

接收层：负责接收上游产品层的交易数据，目前支持 MQ 消息和杰夫接口两种协议。

数据处理层：负责对数据进行解析、幂等判断、交易时序判断、补充数据完整性、映射订单模型等。

数据推送层：负责对数据按照指定的规则格式化、推送到下游系统，目前支持 MQ 和杰夫两种协议。

查询服务：负责数据的查询和导出。

图2 整体架构

      经过对整体架构的设计和抽象以后，可以发现各个业务线的数据处理流程具有高度的一致性：数据接收、数据处理、数据推送，而在不同的业务线产品的交易场景下会存在一些特定的差异，比如，只接收满足某些条件的交易数据、金条借款的订单与基金购买的订单模型不同、只有满足某些条件的数据才推送给结算系统等。为了提高业务的接入效率、降低接入成本，可以抽象一套通用的数据处理流程，流程中的分支通过条件表达式来识别，同时提供一套完整的配置化页面供产品和运营同学使用，最终实现了业务接入配置化、自助化，如下图：

图3 实现业务接入的配置化

3.2.1 配置数据来源和订单模版

     数据接收层通过配置的数据来源协议编码路由到订单模版，不同的业务产品交易场景会配置不同的订单模版。

图4 关联订单模板

3.2.2 配置模版内容

图5 配置模板内容

// 解析贷款单号Object loanId = JSONPath.extract(jsonStr, "$.jt_df_success.loanId");// 解析还款单号Object loanNo = JSONPath.extract(jsonStr, "$.jt_repayment.taskData.loanNo");

3.2.3 配置表达式

     图6 模板表达式的配置

MVEL 类库在订单中心主要的应用场景是对预配置的表达式进行逻辑运算。

 Object result = MVEL.executeExpression("$actExt3$=='SECOBT_JD'&&$accountType$==21", context);

     通过提供通用的数据查询接口和通用的查询页面，来满足数据检索的诉求。针对不同业务产品的交易场景，下游系统都有个性化的查询诉求，比如那些字段需要作为查询条件、哪些字段要在列表页展示、哪些字段需要导出等，类似这样的个性化诉求均是通过配置化来支持的，如下图的配置示例所示：

图7 看板配置化

通用的查询页面通过切换业务线来联动更新查询条件和列表字段：

图8 看板效果

图9 数据推送配置化

     下游接口的字段可以灵活配置，推送程序运行时解析推送配置，以交易数据为上下文组装推送参数，泛化调用下游接口。

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

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

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

      本文从交易履约订单中心的建设背景、设计细节、已支撑案例及适用业务场景多个层面，进行了详细介绍。通过本文读者可以学习通过配置化快速支撑业务的系统架构设计经验、表达式引擎的应用场景。读者可以关注本文展示的以配置化的形式，快速支持多方业务数据接入的架构设计经验。

推荐阅读

zookeeper的Leader选举源码解析

订单逆向履约系统的建模与PaaS化落地实践

UData-解决数据使用的最后一公里

重构指标之如何监控代码圈复杂度

求分享

求点赞

求在看