1、背景介绍
随着转转业务规模快速增长，系统拓扑结构越来越复杂，加上二手交易玩法也非常多（如C2C、C2B、B2B、B2C、C2B2C等），在这种复杂系统架构和业务场景下，无法避免会出现RPC调用失败，消息漏发，线上Bug，业务新老规则冲突等因素引发数据异常，导致用户客诉，以及公司产生损失。当时公司没有一个统一的数据校验治理方案，行业也无相关开源系统，导致业务数据治理这块一直都是一个没有深入治理的领域。基于以上背景，转转业务规则校验平台(简称ZZBCP:ZZ Business Check Platform)孕育而生，此系统帮助业务系统实时校验线上的每一笔单据数据，填补了业务数据质量治理领域的空白。
2 系统目标
- 实时发现线上业异常数据，及时间通知相关人员介入排查，以降低数据异常对用户和业务的影响。
- 低成本接入各种场景数据校对。通过后台配置方式，录入校验规则信息。
- 实时搜集监控数据，并生成统计监控报表，实时掌握系统数据质量。
3 系统设计详解
下图是系统执行规则流程图，触发事件源(trigger msg)驱动规则执行(实时或者延时执行)，目标事件数据源(Target msg-可以不配置目标数据源，则通过RPC方式获取需要校验的目标数据源)是被校验的数据内容。
3.1 系统执行时序图
T1时刻，系统收到触发消息后，命中规则且延时到T3时刻进行数据校验动作。T2时刻，收到目标消息，则将目标消息处理后，暂存到Codis中，等到T3时刻对目标消息进行校验，然后根据校验结果执行后续流程。
3.2 消息订阅模块
当前支持订阅MQ和Binlog消息(Redis/ES暂时不支持)。该模块将触发事件和目标事件的数据，统一转化成ZZBCP系统标准的数据格式，方便后续规则执行引擎统一进行处理。当前对binlog消费使用的Kafaka，将MySql, TiDB的binlog通过CDC中间件(Canal, Maxwell)推送到Kafka消息中间件。
3.3 规则执行模块
延时队列中的规则到期后，会执行数据组装操作，从redis中查询数据(目标数据源)，将数据按系统定义的格式组装好，交给规则执行引擎执行。
当前我们支持两种规则执行引擎:
- 一种是Aviator规则引擎，这种规则引擎适用校验规则较为简单的场景，编写效率高， 但是一旦校验逻辑复杂，使用此方式，则编写的表达式晦涩难懂，而且后期维护成本高。另外， 除了支持Aviator通用函数，我们还内置一下内置函数，如支持redis访问的函数，公司通用的中间件的操作函数。
- 另外一种是Java规则引擎，业务接入按系统规定实现接口方法，并支持泛化调用，不需要依赖业务接口协议接口定义，大大提示了接入效率，并由配置后台实时动态编译并生效，这个方式主要是为了解决校验逻辑较为复杂，校验的目标数据需要依赖RPC从第三方获取的场景。对于动态编译这块，我们使用Java提供的原生编译工具类进行动态编译并加载到JVM中。这个过程中需要注意加载和执行时候ClassLoader不一致的问题。
3.4 告警模块
该模块主要是根据规则执行引擎返回的结果，判断是否需要进行后续的告警操作,异常数据的收集，以及否需要进行重试执行校验动作。
- 告警短信通知信息，透出的业务数据源按需配置，需要透出哪些信息，方便后续定位。
- 异常数据收集列表
3.5 数据自动修复模块
对于以下特殊场景的数据异常，如果可以自动化触发数据修复，则可以使用此功能进行一个数据修复。当前我们的内部财务对账系统，就使用了此功能对异常数据进行自动修复。鉴于时刻对线上数据的敬畏之心，此功能具体修复逻辑，建议控制在业务所属领域內，ZZBCP平台只是一个触发修复的入口。
3.6 监控指标
系统会将所有的规则信息上报到转转的监控系统(Prometheus- 转转进行了二次开发)，对一些经常关注的指标进行统计上报。如规则命中统计，执行规则校验通过，执行校验未通过次数等。
3.7 后台配置
后台配置提供了事件注册注册，报警相关配置和灰度以及手动执行规则等功能。方便业务快速的配置和测试自己的规则校验逻辑。
参考资料
https://www.infoq.cn/article/j*6vp2pbuggcrzbhcaog
https://tool.lu/en_US/deck/sw/detail?slide=8
