转转业务数据校验平台介绍

温景芝

1背景介绍2系统目标3系统设计详解3.1系统执行时序图3.2消息订阅模块3.3规则执行模块3.4告警模块3.5数据自动修复模块3.6监控指标3.7后台配置1背景介绍随着转转业务规模快速增长，系统拓扑结构越来越复杂，加上二手交易玩法也非常多（如C2C、C2B、B2B、B2C、C2B2C等），在这种复杂系统架构和业务场景下，无法避免会出现RPC调用失败，消息漏发，线上Bug，业务新老规则冲突等因素引发数据异常，导致用户客诉，以及公司产生损失。当时公司没有一个统一的数据校验治理方案，行业也无相关开源系统，导致业务数据治理这块一直都是一个没有深入治理的领域。基于以上背景，转转业务规则校验平台(简称ZZBCP:ZZBusinessCheckPlatform)孕育而生，此系统帮助业务系统实时校验线上的每一笔单据数据，填补了业务数据质量治理领域的空白。2系统目标实时发现线上业异常数据，及时间通知相关人员介入排查，以降低数据异常对用户和业务的影响。低成本接入各种场景数据校对。通过后台配置方式，录入校验规则信息。实时搜集监控数据，并生成统计监控报表，实时掌握系统数据质量。3系统设计详解下图是系统执行规则流程图，触发事件源(triggermsg)驱动规则执行(实时或者延时执行)，目标事件数据源(Targetmsg-可以不配置目标数据源，则通过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后台配置后台配置提供了事件注册注册，报警相关配置和灰度以及手动执行规则等功能。方便业务快速的配置和测试自己的规则校验逻辑。