作者：赵彬辉
团队：零售技术
一、前言
对账，从狭义上来说，就是核对账目，是保证会计账簿记录质量的重要程序。从广义上来说，对账可以解释为数据比对，用于解决所有分布式系统之间交互(远程调用、消息触发等)出现的数据不一致问题。有赞作为一家Saas公司，随着业务的发展，商家数达到上百万，每天产生上千万的业务数据，系统稳定性更加要求达到99.99%。数据对账作为业务稳定性必要的一环，下文将介绍配置化数据对账平台在有赞的解决方案，如何在复杂的系统之间，保证不一致的快速发现、展示以及解决。
二、背景
目前有赞的业务不断发展，业务复杂度不断提高，出现不一致的情况也逐渐增多。下面简述几个出现不一致数据的场景：
- 场景一：有赞商家呼叫达达同城配送，随后取消配送订单，但达达系统未取消，导致第三方达达系统同城送计费多算。
- 场景二：买家在有赞商家店铺购买商品参与了满减送，但是赠送的优惠券迟迟没有送达。
- 场景三：买家在有赞商家店铺下的订单支付成功了，但是订单状态还是"待付款"。
从上述列举的场景分析，数据不一致问题，容易出现在交易、物流、营销等分布式系统之间信息流交互的边界上。
根据背景以及公司内部现状，总结痛点：
- 业务场景复杂，不能够及时发现问题，给商家以及买家造成困扰。
- 功能快速迭代，出现业务问题，客服反馈量容易出现快速上升，公司对外处理问题比较被动。
- 部分业务有零散的对账实现，但是硬编码在业务中，每经历业务变更，对账逻辑可能会跟着变化，导致开发成本增大。
- 业务方在处理不一致问题时，沉淀文档费劲，没有归档为后面排查问题提供经验支持。
三、设计目标
业务对账平台设计目标主要从以下几点出发：
- 方便业务对账场景接入，实现业务用例场景覆盖。
- 实时处理海量业务数据比对，及时发现数据不一致问题并产生反馈，尽可能减少对客户的影响。
- 离线业务数据比对，实现业务数据海量回归，全方位核对，降低不一致数据的出现概率。
- 针对业务快速迭代开发，实现灵活调整对账业务逻辑以及对账相关的配置。
- 提供丰富的可视化业务比对图表，供业务方监控当前数据的比对情况。
- 为不一致比对结果提供对账链路的数据快照，方便定位问题。
- 整合数据订正工具，实现简单业务逻辑，自动修复，减少人力成本。
- 为业务线提供业务数据稳定性报告。
四、整体设计
4.1 整体架构
业务对账平台采用DDD设计，分为4层：接入层、应用层、领域层、基础层。
接入层：支持对账平台后台操作与统一调度服务调度的接入。
应用层：支持多个领域层细力度操作的整合，面向业务提供服务。
领域层：对账逻辑执行核心，其中包含支撑域、核心域与领域模型。从源数据加载，数据组装，任务调度，到任务执行，结果存储进行报警，完整实现了对账的核心链路。
基础层：提供基础设施服务，其中包含数据持久化存储、消息传递、任务开关配置、黑白名单设置等。
4.2 核心用例图
从整体上观察，面向使用者，支持哪些操作。面向开发者，拆分对账平台管理端用例。面向调度系统，拆分具体执行用例。
4.3 对账核心思路
基于一系列的对账场景梳理，进行业务抽象，得到对账的核心构建思路，主要分为数据准备、逻辑比对、差错处理。
4.3.1 数据准备
数据准备模块作为对账核心构建思路的第一步，支持业务方多种形式数据的接入，为对账提供所需的数据，即基准数据和待比对数据。
数据接入
数据准备模块为满足公司内部不同业务方的数据接入需求，提供了多种数据接入方式：
- 数据上传：支持excel文件上传，业务按照自定义字段转化规则进行源数据转换，写入到源数据池。
- 数据拉取：支持dubbo或者http接口调用轮询全量或者增量拉取数据，进行数据迭代。
- 数据推送：支持数仓规则化数据写入到源数据池。
数据存储与隔离
多种业务数据导入到源数据池，源数据池中混杂各种数据。为了区分各类业务数据，采取这样的规则用来区分：
- 业务数据类型：区分不同业务数据，比如retailspues表示零售商品库商品es对账数据。
- 执行周期版本号：业务周期版本号，比如20200101表示当前业务数据迭代器加载哪个版本批次数据。
数据规则化
业务数据比较复杂，按照每个业务定义的class解析，维护成本高，数据规则化为了克服数据的多样性，对账数据平台提供源数据格式标准化接入，按照JSON数据格式序列化存储，使用时按照Map.class进行反序列化使用。
代码语言：javascript复制{
"dataAttributes":{
"deductFee":"0.0",
"orderNo":"YZ202011122334455",
"deliveryFee":"10.0",
"tipFee":"0.0",
},
"uniqueKey":"YZ202011122334455"
}数据准备详细流程设计：
4.3.2 逻辑比对
业务逻辑比对，是数据对账平台最核心的一步。业务逻辑核对结果决定了后续差错处理、任务结果趋势统计、业务健康度等环节。所以，业务逻辑核对需要做到结果准确，脚本灵活调整。
如何保证逻辑比对结果准确？
业务逻辑脚本质量由接入业务方进行保证，业务对账平台提供Mock测试工具，支持业务方构造参数来测试对账流程准确性。
如何保证比对脚本灵活调整？
代码语言：javascript复制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。
