微服务架构下的结算系统设计

原创

会跳舞的机器人

修改于 2020-06-12 10:17:39

1.3K0

一、背景

公司业务系统的账户资金对接了第三方存管业务，第三方存管指的是银行与证券公司根据相关的法律法规，为投资者提供的客户交易结算资金管理服务。根据银行要求，在每个交易日闭市后业务系统都要将客户的资金变动情况生成清算文件发送给银行进行资金的清结算。

在微服务架构下，系统存在多个业务子系统（同一套账户体系），那么每个业务子系统发生的资金变动都要进行结算，我们独立了一个结算子系统，结算子系统要做的事情就是按照银行给的资金数据统计规则统计各个业务子系统客户发生的资金变化情况并生成清算文件，然后与银行进行清结算。

二、问题与挑战

2.1 数据同步并保证数据的准确性

由于各个业务子系统和结算子系统不在同一个数据库，那么我们面临的第一个问题就是要将各个业务子系统的资金变化数据同步至结算子系统中，由于是每日结算一次，所以对数据的实时性要求并不高，只要在结算之前能同步完变动数据即可。数据的准确性指的是结算子系统的数据必须要与业务子系统实际的数据一致，不能多一条也不能少一条，否则会清算失败。

2.2 满足灵活应对多变的业务场景

业务的发展是多变的，如果系统后续多增加了几个业务子系统或者砍掉了几个业务子系统，结算子系统最好是不用任何改动即可满足新业务的接入或剔除。

2.3 业务子系统能快速接入

对于业务子系统来说，想要接入结算子系统肯定是越简单越好，最好是几行代码就能搞定。

三、解决方案

3.1 数据同步方案

常见的数据同步方案包括数据库同步、数据文件同步、远程接口获取、MQ数据同步、手工同步。下面就针对这五种同步方式做简单的优缺点分析。

1）数据库同步

数据库同步指的是通过某种工具将A库的数据同步到B库中，比如ETL工具，MySQL的话，可以考虑canal，canal是阿里巴巴开源的MySQL binlog 增量订阅&消费组件。

优点：数据准确性较高
缺点：实施起来较为复杂；扩展性差

2）数据文件同步

文件同步指的是业务子系统将资金数据生成文件放在某个位置上，比如FTP，而后结算子系统上FTP取文件解析入库。

优点：数据准确性高
缺点：灵活性不足

3）远程接口获取

各业务子系统提供资金数据查询的接口，结算子系统通过接口调用的方式来获取数据

优点：比较适合数据量较小情况下的数据传输同步
缺点：效率低；灵活性和扩展性较差

4）MQ数据同步

业务子系统在资金数据发生变化时，通过MQ准实时地将变化数据发送至结算子系统，结算子系统消费消息并入库。

优点：灵活可扩展，且满足业务子系统快速接入的要求，只需要发送一条消息即可，结算子系统只需要关注消费消息并入库即可，就算后续有新增的业务子系统接入，结算子系统也无需改动或少量的改动
缺点：强依赖于MQ中间件，当MQ出现消息阻塞或者宕掉时，数据准确性无法保证

5）手工同步

依赖于人工的导出&&导入数据，其实在定义好相关脚本后，工作量不算太大

优点：数据准确性高，可以核对数据
缺点：不自动化，增加了人工工作量

四、实施方案

数据同步方案

数据同步方案可以采用：MQ数据同步+手工同步的方式。主要依赖于MQ做数据同步，在MQ同步发生问题的情况下，再用手工同步做灾备方案，一般情况下MQ是没有问题的。当然这种方案主要是考虑到它的灵活性与扩展性，再加上实现起来比较简单。考虑到数据的准确性，其实数据文件同步也是一个很好的方式。

整体思路

实现的整体思路为：结算子系统定义好统一的消息字段，比如用户编号、变动金额、变动时间、变动类型（盈利/亏损/冻结/解冻）、业务来源等相关字段。各业务子系统按照统一的消息格式发送消息，结算子系统统一消费入库。在发起结算前，系统先生成结算数据供运营核对，核对无误后，再与银行发起结算。

可能存在的问题以及解决方案

因为可能存在消息消费阻塞的情况，所以在生成结算文件前，为保证数据的准确性，各业务子系统要提供一个查询数据总条数与总金额的接口作为数据核查的依据，结算子系统根据业务来源调用对应的业务子系统的接口获取核查数据，再与结算子系统中的数据做对比，如果一致则说明业务子系统的数据全部同步过来了，如果不一致，那么则告警需要手工同步。