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

、、

点击关注“有赞coder”

获取更多技术干货哦～

一、前言

对账，从狭义上来说，就是核对账目，是保证会计账簿记录质量的重要程序。从广义上来说，对账可以解释为数据比对，用于解决所有分布式系统之间交互(远程调用、消息触发等)出现的数据不一致问题。有赞作为一家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. 业务数据类型：区分不同业务数据，比如retailspues表示零售商品库商品es对账数据。

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

数据规则化

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

{
    "dataAttributes":{
        "deductFee":"0.0",
        "orderNo":"YZ202011122334455",
        "deliveryFee":"10.0",
        "tipFee":"0.0",
    },
    "uniqueKey":"YZ202011122334455"
}

数据准备详细流程设计：

4.3.2 逻辑比对

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

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

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

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

if (order == null) {
    return ;
}

def orderStatus = order.orderStatus;
def errorMsg;

if (orderStatus != "WAIT_SHIPPED" && orderStatus != "SHIPPED") {
    errorMsg = "订单号:" + order.orderNo + ",订单状态未流转至待发货，当前状态为:" + orderStatus;
}

return errorMsg;

灵活性：逻辑核对逻辑使用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。

扩展阅读

1. 有赞零售App离线切换技术方案

2. 有赞零售移动收银商品实践

3. 有赞零售小票打印跨平台解决方案

4. 响应式架构与 RxJava 在有赞零售的实践

5. 有赞零售小票打印图片二值化方案

6. 有赞零售移动端收银商品实践

7. 聊聊UI标准化

8. 有赞零售 App 离线切换技术方案

9. 有赞 Android 编译进阶之路——全量编译提效方案

10. 有赞零售财务中台架构设计与实践

11. 有赞零售中台建设方法的探索与实践

12. 有赞iOS-基于二进制的编译提效策略