谈谈通用对账平台的业务架构设计
Posted 萌大统领
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了谈谈通用对账平台的业务架构设计相关的知识，希望对你有一定的参考价值。
前言
前面的《》一文主要阐述了对账的一些共性，本文主要聊一聊通用对账平台的业务架构设计。
个人理解的业务架构设计，主要是基于实际的需求，准确地识别出要解决的问题域，即识别出问题是什么及问题跟谁有关，从而确定问题域的边界，再基于要解决的问题域，梳理业务流程、划分功能模块、明确模块间的信息流、抽象核心业务实体等。
关于业务架构，业内其实也没有统一标准的权威定义，因此见仁见智，每个人的理解都可能会不同，但有一点则是大部分人所认可的，那就是：业务架构不需要考虑诸如我用什么语言开发、我的并发吞吐大怎么办、我选择什么样的中间件等，它更多的是对业务领域的不变性的一种抽象，比如概念的不变部分，关系的不变部分，逻辑的不变部分等。我们需要识别出这些不变的点，并将之与变化的点进行隔离。
— 1 —
业务边界
可能会有朋友会问，现有的各个业务系统其实各自或多或少已经内建了一定的对账功能，此时再去新建一个对账平台的意义是什么呢？是否有必要？其与现有的这些系统的内部对账模块的区别又是什么呢？
简单说，有如下2点区别：
定位的不同：对账平台是面向所有业务系统的，定位为通用的数据核对平台，是服务外部所有业务的。而现有的业务系统的内部对账模块一般只给自己用，只满足自身业务的对账需要，尤其是有的对账逻辑与业务逻辑耦合较强。
覆盖面不同：对于新建系统或没有对账能力的业务系统，对账平台可以帮助它们快速支撑起自己的业务对账能力，而对于已具备对账能力的业务系统，则对账平台可扩展其对账能力的深度与广度，补充其缺失或不足的方面。
主要解决如下2个问题：
通过核对数据之间的勾稽关系、识别异常差异（如长短款），促进业务交易数据的准确性和一致性的提升。
提供的通用核对能力能快速支撑起各个业务的对账能力，能有效减少各个业务在对账方面的重复建设，节省资源。
以上2点其实也正是建设通用对账平台的价值所在，那么这个价值又是针对谁而言的呢，也即通用对账平台跟谁有关呢？
主要跟如下两方人员有关：
相关业务系统的owner/leader
即接入对账平台的各个业务方，体现为这些业务系统的owner或leader。
财务同事
出于财务稽核的需要，财务同事往往也属于对账平台的一个重要业务方。
上面2个问题如果要合成一个问题，那就是为谁提供了什么价值，那么该如何有效衡量这个价值呢？即该以哪些 KPI 指标来衡量通用对账平台的业务价值？
至少可以有如下几方面来衡量对账平台的业务价值：
对账时效性：越高越好
错核的次数：越低越好
漏核的次数：越低越好
数据的量级：越大越好
接入业务数：越多越好
综上，如果要用一句话来描述，什么是通用对账平台的话，该如何描述呢？它是一个以促进数据准确性和一致性的提升为目标，面向各个业务方，基于具备勾稽关系的多个数据源，提供通用核对能力的中后台系统。
至此，已确定了对账平台是什么、跟谁有关、有什么价值，则也意味着确定了对账平台的业务边界，或者说问题域边界，后续的设计和实现都必须在这个边界之内进行才有意义。
— 2 —
核对什么
对账的实质是针对指定的关键数据项进行核对，那到底有哪些关键数据项呢？
个人认为，至少有以下几个：
核对金额：必选，金融业务里的对账往往跟钱是强相关的，其实不光是金融业务，很多业务的对账也都基本会涉及到金额的核对。
核对笔数 ：可选，因为更多地是适用于数量关系确定的业务场景，比如一对一或固定的一对N（N要为确定不变的某个固定值）。如果是不固定的一对多的场景，则不太适用，因为会引入不小的复杂度。
核对状态：可选，因为仅适用于参与核对的两方在数据状态上存在一个确定的对应关系，这其实在一定程度上会让对账本身与具体业务产生耦合，需要感知和同步参与核对的两方的数据状态定义。
核对关系：可选，关系核对属于比较复杂的一种核对，数据源必须要能提供体现关系映射的属性，否则是无法进行关系核对的。金融业务中典型的关系核对场景有比如是否存在错扣（扣A用户的钱扣成B）
— 3 —
对账流程
一个接入业务可以包含多个对账场景，而一个对账场景 = 数据准备 + 数据比对 + 结果处理 。
事实上，大部分的对账场景的处理流程其实都可以大致分为这三大环节。
第一个环节 数据准备：即准备好要比对的数据，该环节可抽象为如下几步：
1）数据获取
即如何获取数据源的数据，一般是按照指定的数据源规则来获取：
获取方式：可分为DB、文件、RPC接口、消息几种
获取频率：取决于数据源的提供频率，可分为天、小时、分钟3种
细节配置：不同的获取方式下的配置不同，比如DB方式，则要配置DB的用户名密码、目标表名等，文件方式则要配置约定的文件名、分隔符等。
2）解析转换
即在获取到源数据后作一些预处理，比如支付的外部对账场景，就需要先将多个不同的外部支付渠道的源数据按照统一格式进行解析转换再入库，又比如部分一对多的对账场景中，会对“多”的那一方的源数据先做一定的归并计算再入库。
如果没有什么需要解析转换直接加载源数据入库，则这一步可以配置为跳过。
3）保存入库
即持久化到DB，但也有可能不入库，直接进入下一步的比对环节，因此要看具体的场景需要。
第二个环节 数据比对：比对环节是最核心的环节。
该环节看着似乎很简单，无非就是数据的比较（虽然数据核对的本质就是基于相同的唯一属性，来关联两方数据源进行数据比较），但作为一个通用的对账平台，还是要更多考虑扩展性方面的设计。
如上图所示，比对环节可以抽象为由多个比对任务组成，每个比对任务又由多个处理器组成：
1）比对任务：可以理解为比对环节的细分和拆解，上一个比对任务的输出是下一个比对任务的输入。
2）处理器：可以理解为比对任务的细分和拆解，一个处理器可以理解为一个业务插件，包括：
加工器：负责对数据进行加工，例如金额的合并计算。
比对器：可分为金额比对器、笔数比对器、状态比对器、关系比对器。
其他处理器：可以针对实际的场景设计不同的处理器。
自定义的处理器：为业务方自定义的处理器，比如业务方的一个RPC接口。
而每个比对任务都由这些处理器组成，可以只是其中一个处理器，也可以是多个处理器的组合。每个处理器的输出可作为下个处理器的输入，也支持不采用上个处理器的输出，而是可以按照自定义的逻辑读取相应数据。
虽然大部分的常规核对场景都比较简单，比如可能就是简单地核对两方的金额即可，但也存在部分较为复杂的核对场景：
比如“发生额-余额”的对账场景，需定时累加对应账户的发生额与该账户对应时间点的余额进行比对，则就需配置一个加工器+一个比对器，即加工器去累加该时间段内的所有发生额，并加上上个余额。
又比如前面提到的“一对多”场景，可以配置一个加工器+一个比对器，加工器就是对“多”的那一方数据按照一定维度做合并计算，然后再由比对器负责将合并计算后的结果与另一边进行比对。
通过这种可插拔式、能自由组合的“插件化”的处理器机制，可达到“可胖可瘦、可高可矮”的良好扩展性。即：既可以满足简单通用的常规对账场景（如一对一的金额核对），又可以满足个性化的、较复杂的对账场景（例如账户发生额与余额的核对、一对多的核对多对多的核对等）。
比对环节还要注意如下几个设计要点：
1）比对任务的编排流转
由于比对环节被拆解为了多个比对任务，因此要考虑每个比对任务之间该如何编排、流转。当然了，如果是比较简单的核对场景，则配置为一个比对任务即可。
2）比对任务的前置检查
即每个比对任务都可以有一定的前置依赖，若有，则需检查是否满足依赖条件。
3）正常差异的勾兑冲销
比对发现的数据差异一般可分为“单边、重复、不一致”这3种：
单边：指一边有一边无。
重复：指两边都有对应记录，但至少有一边存在多条相同的记录。
不一致：指非单边且非重复，但两边的关键数据项不同。
以上差异需要区分出正常差异和异常差异，其中正常差异指业务方可接受的差异，比如一笔跨天的转账交易，转出交易在T日，转入交易在T+1日，则在T日就是单边差异，可在T+1日将该单边差异勾兑冲销，因为属于正常差异。
因此这一步主要就是从核对出的数据差异中，识别出哪些属于正常差异，并将之勾兑冲销，剩余的就是异常差异了。
第三个环节 结果处理：即如何处理对账结果，可抽象为如下2步：
1）对账结果的反馈
即对账完成后，该如何通知业务方（上游业务owner、财务同事等）、该通知哪些内容（如成功与否、异常原因等），该以怎样的方式（邮件、文件、RPC接口、消息等）通知到业务方。
2）异常差异的处理
即对账结果中的异常差异记录的处理状态的扭转（处理与否、处理描述等），于对账平台而言，只是一个象征性的动作，表示该异常差异已经得到了处理，背后还是需要依靠业务方介入分析异常差异的原因。
— 4 —
功能划分
如上图所示，大概可以分为7大功能：
1）规则参数管理：主要负责如下三类规则或参数的配置：
对账规则配置：如数据源规则、比对规则、结果处理规则 等
比对处理器配置：如加工器、比对器、自定义处理器等
其他参数配置：如日期参数配置
注：比对规则里主要是配置比对频率、差异阈值以及选择相关的比对处理器。
2）业务接入管理：负责为每个接入业务配置对应的对账场景，每个对账场景里则包含对应的数据源规则、比对任务、结果处理规则 等
3）批量任务管理：对账其实也是一个批处理任务，需要对这些批量任务的启动、停止、查看、重跑等进行管理，一般会由一个通用的批处理框架来支撑。
4）相关数据查询：负责对账数据的查询。
5）数据同步处理：按照配置好的对账场景进行数据获取、解析转换、保存入库等。
6）数据比对处理：按照配置好的对账场景进行负责数据的比对。
7）核对结果处理：负责核对结果的反馈与异常差异的处理。
— 5 —
领域实体
基于前面的对账流程和功能划分，可以抽象出如下几方面的领域实体，要注意的是，这里的领域实体描述的还是比较简略，因为并没有给出每个实体的核心属性有哪些，以及这些领域实体有哪些领域事件及事件约束等等。最终的领域实体还是要结合具体的业务场景、应用架构、技术架构等来确定。
规则参数相关：如下所示，从左至右属于包含关系，后者包含前者。
对账处理相关：如下所示，每个实体数据产生时的所处阶段如下所示：
— 6 —
总体逻辑架构
如上图所示，基于规则中心里的规则（数据源规则+比对规则+结果处理规则）来配置各个接入业务的对账场景（如信息流与信息流核对），按照对账场景来进行相关的对账处理（数据准备、数据比对、结果处理）。
最后的话
本文主要聊了聊通用对账平台的业务架构设计，但业务架构毕竟不是一个具体的技术实现方案，因此一个系统光有业务架构设计是很难落地的，后续将会另外开篇再聊一聊通用对账平台的应用架构和技术架构的设计。
完结 撒花
往期回顾：
以上是关于谈谈通用对账平台的业务架构设计的主要内容，如果未能解决你的问题，请参考以下文章