京东到家运费业务校验系统设计与实践

原创王多友达达集团技术

前言
到家运费系统简介
BCS设计与实践
总结与展望

前言

任何系统在需求迭代过程中都会产生一定BUG，几乎所有BUG都会在功能上线前发现修复，但是难免会有漏网之鱼。写出BUG并不可怕，可怕的是写出的BUG都没有及时被发现，等BUG引爆出来的时候已造成巨大资金亏损。如何在系统出现问题前或问题出现后及时发现解决，这个问题是运费团队一直思考的问题。虽然所在团队制定一系列制度来避免此类的发生，但是仍然无法完全避免此类问题的出现。

到家运费团队结合目前运费业务场景和系统痛点设计出一套运费BCS系统(业务校验系统)来保障系统稳定。目前线上出现问题后可快速被发现，如数据异构改造引发的数据不一致、计算逻辑错误造成的资金亏损、运营误操作造成的资金亏损等一系列问题。

到家运费业务简介

【运费基础业务】

到家运费系统主要分为B端和C端两种业务。

B端业务分为商家端和平台运营端，商家端由商家运营去配置门店运费基础信息和运费促销活动。运营端由到家运营设置运费规则信息。

C端业务是基于运费规则对订单进行实时运费计算。

【运费共建业务】

到家运费系统除了提供支撑到家内部业务能力外同样对京东主站融合共建类业务提供支持。其中主要代表业务为小时购共建业务，用户可在京东商城小时购模块区域通过门店结算下单，到家运费系统为业务共建提供运费规则计算所需要的数据。小时购数据由到家B端入口管理配置，修改后通过数据同步方式传递到京东主站运费系统。

BCS设计与实践

运费BCS系统基于现有业务总结出多种校验模式，不同校验模式有着相应的适用场景。

【同源异构数据的一致性问题校验】

主要适用校验场景：

多端垂直接入，漏测率高。
回溯计算逻辑上下文场景。

【业务逻辑的正确性校验】

主要适用校验场景：

运营误操作。
业务漏洞或技术漏洞。

同源异构数据的一致性问题校验

主要实现原理：

采取校验的方式为最终一致校验，规避入口和中间流程的繁琐复杂，通过结果反向验证整个流程是否存在问题。

同源异构数据的一致性问题校验主要体现在到家运费系统中小时购业务处理。小时购业务每次需求迭代都需要特别考虑几个点，一旦这几个点出问题不但会产生数据不一致并且不好被快速发现。问题点如下：

业务数据变更主要来源于B端业务，但是B端修改数据的入口较多（如开放平台、商家中心等），而且每个入口数据变更方式也同样多样化（如单条新增、批量修改、删除等），有时候一个功能迭代可能涉及到多个模块的修改，如果测试和开发有所遗漏就会出现一定问题，这种情况对于跟钱打交道的核心系统来说是不会被允许的，目前这种需求处理的方式无外乎就是靠着文档梳理、产品研发测试对业务熟悉程度进行规避，但是杯水车薪。这种流程依旧存在巨大隐患，无论是在对接初期还是后期的功能迭代中总容易遗漏功能改造点。
部分业务流程节点多且逻辑复杂，并且流转到最后节点涉及数据量很难预知。小时购运费数据可以针对不同方式对运费数据变更，因为运费配置模版生效是有优先级的，会根据命中的运费模版实时计算出不同的运费信息。如果调整某个城市下的运费，那么涉及到的门店和其命中运费模版数据很难被提前预知出来，并且期间会经过多次数据拆分转换，先查询出城市下所有门店，然后调用多个服务批量补全同步所需要的数据（数据过多需要多次补全），最终同步到京东主站运费系统。其中一个步骤出现问题都会造成部分数据丢失未同步。

具体实现方式：

模式核心是通过反向校验（最终一致性校验）方式对数据进行校验，从而规避需要考虑正向流程中繁多的业务入口、复杂的同步流程等场景，只需要比较到家存储数据与京东主站运费数据是否一致即可。什么时候去触发校验是一个需要考虑的重要点，总结出两套方案如下：

实现方式

优缺点

正向通知延迟校验+反向通知校验

到家运费修改后延迟1分钟进行校验修改后的门店数据是否与京东主站运费数据一致。
京东主站运费数据变更后进行通知，收到通知后对变更门店数据与到家数据做数据一致比较。

优点：

通过双向校验可以快速校验出双方数据同步后数据不一致问题。

缺点：

需要到家与京东主站运费改造，与业务流程强耦合，一旦业务变更还需要考虑校验流程，功能开发改造几乎是双倍的工作量。

定期轮询数据对比校验

定期拉取小时购全量商家门店数据，并离线存储最新数据。
根据小时购数据进行门店级别校验，校验中需要同时拉取到家和京东主站运费数据进行比较。

优点：

不依赖到家和京东业务只关注最终结果，业务调整或出现问题不会影响校验。

缺点：

每次都进行全量校验比较耗时，并且数据校验有一定延迟。

进行综合考虑最终决定使用第二套方案，校验逻辑可以完全独立原业务外，并且原系统不会产生任何接入成本。功能图如下：

任务发布者：周期性获取小时购全量门店数据并放入到任务池中，待任务执行器校验门店数据是否一致。

任务池：存放待校验京东到家与京东主站运费数据的门店id。

任务执行器：实时拉取到家和京东运费数据，并选择提供的校验规则去校验数据一致情况。

数据一致校验模式还提供一个可视化查询界面方便查看数据一致情况，并且方便定位查询出同步产生问题点。如果到家运费信息调整后因系统问题未同步至京东主站运费系统中，除报警通知外可以在该界面查询出具体什么信息不同步，问题确定后可以手动同步修正数据。

业务逻辑的正确性校验

主要实现原理

采取校验的方式是收集业务数据并根据配置的校验规则进行业务合理校验。

主要实现方式是在运费项目中集成数据采集端，将一套完整业务涉及的相关的业务数据进行串联，将串联后的数据发送到数据采集端。目前数据采集端基于接口业务数据采集，使用注解AOP实现方式。通过收集影响运费计算的源数据，依靠http协议进行实时上报，发送过程使用异步线程池，如果期间待发送任务达到阈值后丢弃新产生的任务，通过这些流程最终完成数据上报流程。

业务数据在运费BCS系统进行收集，收集到的数据进行逻辑聚合，拆解根据配置好的校验规则去做业务校验，相关的数据可用于核心计算流程查询分析，同样也可以为人工排查提供依据。

具体应用方式：

通过BCS数据采集端采集数据后就可以使用这些数据去做校验，针对需要校验不同业务场景功能实现有一定差别，具体如下。

校验业务	实现方式
运营误操作	运营操作后可根据经验值判定当前操作是否存在不合理，一旦出现可能造成损失的操作进行预警。如配送超过限定阈值需要收取某项运费，而通过规则引擎检查到不符合相应运费收费规则，则判定未运营操作失误。
调用链数据查询	在日常工作中一定会需要通过日志辅助排查问题，但是日志线上可能会经常关闭或者流程过长串联查找较为困难。运费BCS系统将收集到的核心业务数据独立存储，方便人工验查业务数据正确性。
运费明细报表统计预警	通过用户触发调用运费对订单运费明细数据存储统计，理论来说新功能上线后通过数据的同比、环比发现数据差异过大，新功能存在一定问题。如运费优惠叠加计算失误，互斥优惠进行叠加使用，通过规则引擎检查到统计报表中订单单均运费实收必然会成下降趋势，检测到后判定新功能逻辑有问题进行预警。

总结与展望

运费BCS系统是基于现有运费业务提炼出来的可扩展校验系统，从上线至今已帮助运费解决不少问题其中不缺乏生产环境的隐藏雷点。运费BCS系统仍处于摸索阶段还有很多计划中的功能待实现，如支持更灵活的规则配置和校验、报警精确化、问题数据自动订正处理等。

继续滑动看下一个