业务稳定性守门员：有赞业务对账平台的探索与实践

作者：赵彬辉

团队：零售技术

一、前言

对账，从狭义上来说，就是核对账目，是保证会计账簿记录质量的重要程序。从广义上来说，对账可以解释为数据比对，用于解决所有分布式系统之间交互(远程调用、消息触发等)出现的数据不一致问题。有赞作为一家Saas公司，随着业务的发展，商家数达到上百万，每天产生上千万的业务数据，系统稳定性更加要求达到 99.99% 。数据对账作为业务稳定性必要的一环，下文将介绍配置化数据对账平台在有赞的解决方案，如何在复杂的系统之间，保证不一致的快速发现、展示以及解决。

二、背景

目前有赞的业务不断发展，业务复杂度不断提高，出现不一致的情况也逐渐增多。下面简述几个出现不一致数据的场景：

• 场景一：有赞商家呼叫达达同城配送，随后取消配送订单，但达达系统未取消，导致第三方达达系统同城送计费多算。

• 场景二：买家在有赞商家店铺购买商品参与了满减送，但是赠送的优惠券迟迟没有送达。

• 场景三：买家在有赞商家店铺下的订单支付成功了，但是订单状态还是"待付款"。

从上述列举的场景分析，数据不一致问题，容易出现在交易、物流、营销等分布式系统之间信息流交互的边界上。

根据背景以及公司内部现状，总结 痛点 ：

1. 业务场景复杂，不能够及时发现问题，给商家以及买家造成困扰。

2. 功能快速迭代，出现业务问题，客服反馈量容易出现快速上升，公司对外处理问题比较 被动 。

3. 部分业务有零散的对账实现，但是硬编码在业务中，每经历业务变更，对账逻辑可能会跟着变化，导致 开发成本增大 。

4. 业务方在处理不一致问题时， 沉淀文档费劲 ，没有归档为后面排查问题提供经验支持。

三、设计目标

业务对账平台设计目标主要从以下几点出发：

1. 方便业务对账场景接入，实现业务用例场景覆盖。

2. 实时处理海量业务数据比对，及时发现数据不一致问题并产生反馈，尽可能减少对客户的影响。

3. 离线业务数据比对，实现业务数据海量回归，全方位核对，降低不一致数据的出现概率。

4. 针对业务快速迭代开发，实现灵活调整对账业务逻辑以及对账相关的配置。

5. 提供丰富的可视化业务比对图表，供业务方监控当前数据的比对情况。

6. 为不一致比对结果提供对账链路的数据快照，方便定位问题。

7. 整合数据订正工具，实现简单业务逻辑，自动修复，减少人力成本。

8. 为业务线提供业务数据稳定性报告。

四、整体设计

4.1 整体架构

业务对账平台采用DDD设计，分为4层：接入层、应用层、领域层、基础层。

接入层：支持对账平台后台操作与统一调度服务调度的接入。

应用层：支持多个领域层细力度操作的整合，面向业务提供服务。

领域层：对账逻辑执行核心，其中包含支撑域、核心域与领域模型。从源数据加载，数据组装，任务调度，到任务执行，结果存储进行报警，完整实现了对账的核心链路。

基础层：提供基础设施服务，其中包含数据持久化存储、消息传递、任务开关配置、黑白名单设置等。

4.2 核心用例图

从整体上观察，面向使用者，支持哪些操作。面向开发者，拆分对账平台管理端用例。面向调度系统，拆分具体执行用例。

4.3 对账核心思路

基于一系列的对账场景梳理，进行业务抽象，得到对账的核心构建思路，主要分为数据准备、逻辑比对、差错处理。

4.3.1 数据准备

数据准备模块作为对账核心构建思路的第一步，支持业务方多种形式数据的接入，为对账提供所需的数据，即基准数据和待比对数据。

数据接入

数据准备模块为满足公司内部不同业务方的数据接入需求，提供了多种数据接入方式：

• 数据上传：支持excel文件上传，业务按照自定义字段转化规则进行源数据转换，写入到源数据池。

• 数据拉取：支持dubbo或者http接口调用轮询全量或者增量拉取数据，进行数据迭代。

• 数据推送：支持数仓规则化数据写入到源数据池。

数据存储与隔离

多种业务数据导入到源数据池，源数据池中混杂各种数据。为了区分各类业务数据，采取这样的规则用来区分：

1. 业务数据类型：区分不同业务数据，比如retail spu es表示零售商品库商品es对账数据。

2. 执行周期版本号：业务周期版本号，比如20200101表示当前业务数据迭代器加载哪个版本批次数据。

数据规则化

业务数据比较复杂，按照每个业务定义的class解析，维护成本高，数据规则化为了克服数据的多样性，对账数据平台提供源数据格式标准化接入，按照JSON数据格式序列化存储，使用时按照Map.class进行反序列化使用。

数据准备详细流程设计：

4.3.2 逻辑比对

业务逻辑比对，是数据对账平台最核心的一步。业务逻辑核对结果决定了后续差错处理、任务结果趋势统计、业务健康度等环节。所以，业务逻辑核对需要做到结果准确，脚本灵活调整。

如何保证逻辑比对结果准确？

业务逻辑脚本质量由接入业务方进行保证，业务对账平台提供Mock测试工具，支持业务方构造参数来测试对账流程准确性。

如何保证比对脚本灵活调整？

灵活性 ：逻辑核对逻辑使用Grovvy实现，通过加载上下文数据，业务方自由实现业务比对逻辑，按照规则进行返回错误。每个任务对账逻辑保存在DB中，每当有对账执行通过加载到内存，执行逻辑核对。当然，当业务方业务逻辑有更改，需要检查脚本的准确性，重新进行Mock测试。

对账方式

加载业务源数据，进行Grovvy脚本逻辑比对，必然会出现左右方业务数据进行核对，对账方式也会出现两种：

• 单向对账：以左方数据作为基准数据，另一方数据作为待比对数据，进行业务逻辑核对，得出不一致结果。

• 双向对账：两方数据互为基准数据和待比对数据，进行业务逻辑核对，核对出双方没有对方数据的差异。

业务对账平台通过建立两个对账任务，左右方数据分别作为基准数据进行源数据加载核对。

对账粒度

对账粒度主要划分为明细对账和总数对账两块。

• 明细对账：单条源数据，根据业务唯一标识进行关联，实现业务逻辑比对。

• 总数对账：用户自定义业务逻辑比对维度，系统按照该维度进行统计，与另外一个统计的总数进行一般。

从两种对账力度来看，明细对账通过复杂的业务逻辑判断，更加细腻，可以发现漏掉、重复、错误的数据等，总数对账只能在某个维度来对账，不能够定位到单条记录上。所以，在一般的对账场景中，明细对账为主，总数对账为辅，两者结合使用。

逻辑比对详细流程设计：

4.3.3 差错处理

差错处理是关键性的第三步，反馈结果给技术人员与业务系统。差错处理含有对不一致结果进行展示，重试，报警，订正，下载等操作。

二次核对

二次核对有两种方式组成，自动重试与手工重试。

• 自动重试：解决因为网络抖动、外部数据加载异常，导致对账逻辑错误的问题。

• 手工重试：业务订正不一致数据后，校验业务数据。

结果报表下载

对账结果按照开发者自定义转换规则，直接加工形成报表，生成第三方需要的格式文件。

报表生成流程：

报表案例：

案例备注

业务方支持在业务对账平台进行案例沉淀，方便案例在业务组内共享，减少业务排查时间，节省人力成本。

不一致报警

对账平台接入有赞统一报警平台，可实现准时电话，短信，有人，企业微信推送报警，按照不同的业务级别进行配置关联。

报警案例：

业务数据订正

对账平台通过比对结果，按照指定的异常，进行发送 RPC泛化调用 和 异步消息 两种方式进行通知业务方，业务方可以配置对应的订正方式。

差错处理详细流程设计：

五、功能介绍

对账平台倡导流程标准化，在几个关键点进行配置，支持开发者花更多精力在对账相关信息、逻辑对账细节，后续处理比对不一致结果上。

5.1 对账任务配置化

• 基本信息：描述清楚对账任务的目的，比如任务标题，任务权限等。

• 触发时机：触发对账任务执行的时间点，准实时对账按照领域事件触发，离线对账按照Tsp(有赞统一调度平台)触发。

• 外部数据加载：实时加载业务对账中的所需数据，基于Dubbo泛化调用实现。

• 不一致结果报警：关联配置统一报警平台(支持电话、内部管理软件、邮件、企业微信等渠道报警)配置，出现比对不一致结果进行报警推送。

5.2 任务Mock测试工具

配置完任务，不确定对账任务的准确性。对账平台提供了Mock测试工具，便于检验对账整个流程。Mock测试 工具 支持参数Mock，以及执行流程快照可视化，模拟实现对账链路。

如何构造测试参数?

• 实时对账：测试参数为业务对应的消息体，直接贴入消息体即可，对账平台Mock执行环境流程进行对账。

• 离线对账：测试参数为标准化结构，业务方按照对应的结构传入参数，对账平台进行解析，透传到Mock执行流程，进行对账。

实时对账Mock测试案例：

对账数据展示 ：记录对账过程中，外部加载器实时加载的数据快照，用于下文业务逻辑核对。

5.3 对账结果趋势统计

对账结果主要统计对账执行过程中产生的数据，给开发者提供可视化监控，观察当时以及以往汇总数据，可以通过指标同比、环比，得出业务波动性。

趋势统计指标主要分为两个大维度，包括： 时间维度 和 业务维度 。

时间维度：时间维度按照5分钟、1小时、1天三个维度在业务维度上进行聚合，形成一个槽，进行数据记录。

业务维度：业务维度主要指的是业务指标，有校验数量、不一致数量、解决数量、自动订正数量等。业务指标反应出对账任务的执行情况，业务的健康程度、修复情况等。

六、技术挑战

6.1 已遇到的技术挑战

业务接口限流

问题：业务对账平台支持业务接口实时反查，遇到大流量实时消息或者大批量离线对账时，对业务系统会形务调用洪峰，触发业务接口限流。

• 解决方案：按照接口维度让业务方给定QPS，对账系统接入限流器，按照限流调用对应的接口进行对账，如单个对账任务存在多个接口，按照全局最小QPS执行限流操作。

• 限流方案：限流目前采用的是com.google.common.util.concurrent.RateLimiter，每台机器 RateLimiter = 实例接口支持安全的QPS / 对账应用实例数

• 重试方案：存在RPC调用失败的情况，对账系统这边支持5s、30s、60s进行对账重试，如果重试3次之后继续失败，进行业务报警。

6.2 后续技术挑战

6.2.1 多流实时数据join

目前对账系统这边实时对账驱动对账执行是单流实时数据，为了减少业务接口反查，减少对业务系统的影响，对账系统这边已在考虑多流实时消息join，通过业务唯一标识串联多流数据，达到可执行状态。

业务对账线程池定时拉取可执行对账源数据，进行基于数据级别业务对账。

6.2.2 智能化推荐对账规则

当前业务的比对规则是业务专家给定的，但是业务专家给定的维度不一定完全，容易出现遗漏的地方。智能化，可以从对账规则维度，基于规则数据的学习来找出规律，从而推荐对账规则。业务专家在编写对账规则的时候，通过引入推荐的对账规则，加强对业务数据的校验，从而发现资损点和异常数据。

七、未来

业务数据对账，面向业务场景建立，与业务紧紧相关。有赞业务对账平台平台自从上线以来，已承接公司各团队的信息流对账，每天处理上千万数据。分布式系统交互之间，数据不一致问题不能完全避免。未来数据比对平台，在做好高实时、高吞吐量的时候，还会往配置化与可视化方向发展，从业务数据生产到订正业务数据，各维度统计拦截结果价值，反馈给业务方系统稳定性，形成业务数据对账闭环。对于业务数据，我们保持谨慎，充满敬畏，做好稳定性的守门员。对数据对账有兴趣的小伙伴，欢迎联系zhaobinhui@youzan.com。

扩展阅读