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

1、背景

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

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

2、问题与挑战

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

因为各个业务子系统和结算子系统不在同一个数据库，那么咱们面临的第一个问题就是要将各个业务子系统的资金变化数据同步至结算子系统中，因为是每日结算一次，因此对数据的实时性要求并不高，只要在结算以前能同步完变更数据便可。数据的准确性指的是结算子系统的数据必需要与业务子系统实际的数据一致，不能多一条也不能少一条，不然会清算失败。

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

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

2.3 业务子系统能快速接入

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

3、解决方案

3.1 数据同步方案

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

1）数据库同步

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

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

2）数据文件同步

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

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

3）远程接口获取

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

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

4）MQ数据同步

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

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

5）手工同步

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

• 优势：数据准确性高，能够核对数据
• 缺点：不自动化，增长了人工工做量

4、实施方案

数据同步方案

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

总体思路

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

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

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

---

若是文章对你有帮助的话，给文章点个赞吧。

若是有写得不正确的地方，欢迎指出。

文章首发公众号：会跳舞的机器人，欢迎扫码关注。