江苏金融小贷系统设计方案[江苏省小贷协会]

　　点击标题下「蓝色微信名」可快速关注

　　上篇详见：一站式资金解决方案（上）

　　1. 系统设计与实现

　　1.1.架构设计

　　1.1.1.

　　资金处理平台架构设计

资金处理平台是一个五层结构的平台，分别为业务需求方、接入层、账务服务层、基础服务层和数据存储层。

依据业务来源的不同，将业务需求方划分为5大类，分别为运营、对账平台、支付交易、金融平台和非支付中心系统。其中非支付中心的系统通过接入系统接入，其他系统通过 dubbo 或消息接入。

接入层负责系统接入、协议转发、加签验签等逻辑，仅对非支付中心系统。

账务服务层为资金处理平台提供产品服务，主要包含有：账务、会计、日终、计费、清结算、备付金管理、数据中心、数据输出和监控等。

基础服务层为自己处理平台的基础服务，提供基础服务供账务服务层使用，主要包含：基础数据查询服务、内部查询系统、外部查询系统、字典服务、配置服务和ES代理服务等。

数据存储层负责存储数据，因数据量巨大，因此划分了不同的存储，后续会介绍数据存储的演变过程。

架构如下：

　　1.1.2.

　　对账平台架构设计

　　对账平台主要有四部分构成，分别为数据采集系统、宽表系统、对账系统和差异处理平台。

数据采集系统负责采集对账文件，并统一存储原始文件，文件最终写入到公司统一的 HDFS 中。数据采集系统支持被动推送和主动采集两种模式，主动采集支持从本地的 ftp、外部 ftp、银行前置机和邮箱中采集。

宽表系统负责数据解析，完成从异构数据到统一标准数据的转换过程，针对数据的解析和转换通过一个内置的 JS 解析引擎完成。

对账系统完成对账，并驱动后续的逻辑，例如计费、清结算、备付金结转等。

差异处理平台针对对账结果进行差错处理，比如补单等。

架构如下：

　　1.2.快速业务支持

互联网公司的最大特点就是快，产品的生命周期非常快，迭代频繁，经常变更，资金处理平台是一个处于最底层的系统，如何应对上游系统的变化是一个巨大的挑战。

业务场景多，变化频繁，如何快速的支撑业务？

1. 在支付时收取用户技术服务费、在担保确认时收费代理商技术服务费

2. 外币业务，本币业务

3. 消费贷资金场景复杂，预存款、清算、非代收等模式

用户余额账户，多种资金来源，性质不同，如果控制？

1. 借记卡可以提现，贷记卡只能原路退回

2. 只有提现额度可以购买理财产品

3. 消费金额度不可以提现，也不可以原路退回，只能消费

　　1.2.1.

　　解决方案

　　1、引入清分规则，参数化，配置化，灵活支持业务变化；新增业务场景通过配置即可上线。

　　2、引入支付策略配置，通过修改配置项实现不同的场景使用不同性质资金。

　　1.3.热点数据解决方案

系统流量是每个开发者都重点关注的事情，对于账务系统尤其是如此。账务系统需要应对热点账户的问题，QUNAR 账务系统中最热点的账户每天会有 300W 笔账务的记录，还有一种压力来自于瞬间爆发的流量，比如如下场景：

上图中是红包发放的场景，日常流量为200笔/分钟，峰值为3000笔/分钟，但是会有大流量的爆发，比如图中持续的10K以上的流量。

　　1.3.1.

　　系统架构调整：异步化

我们最初的系统是会计系统、账务系统是一个系统，由会计系统驱动账务系统，完成整个业务的处理。但是这样有个问题就是系统需要处理完成所有的账户业务，针对热点账户就会有很多锁等待。

账务系统的业务模型可以抽象为转账，就是一笔账户入账，一笔账户出账。为保证业务的资金安全，这个业务需要在事务中完成。但其实有些账户并入账的实时性并不敏感，比如过渡账户、应收款等账户。因此我们做了异步化的改造，将账务系统拆分为账务系统、会计系统和日终系统，改造后的系统流程简图如下：

改造完成后，我们将某些非实时账户，降级处理，汇总入账，将多条 update 合并为1条。

　　1.3.2.

　　实时热点账户

异步化可以处理掉非实时账户的热点问题，但对于实时账务是无能为力的。我们采用 Sharding 策略，将一个大账户 Hash 为多个子账户（余额平衡策略），外部表现为1个账户，内部实现为多个分账户。

上面这个方案我们正在计划中。

　　1.3.3.

　　数据库锁的选择

不使用悲观锁和乐观锁，使用一次查询来对账户进行校验。

我们选择这样的锁策略，主要基于以下的原因：

1. 并发场景下，乐观锁会导致重试逻辑，造成业务复杂，影响性能

2. 存在热点账户数据，悲观锁会导致频繁等待，影响性能

　　1.3.4.

　　限流

现阶段我们的限流比较暴力，是基于 dubbo 的服务治理限流，控制线程池中执行某个服务的线程数。如下图：

　　后续我们会优化为基于服务参数的限流。

　　1.4.存储优化

账务系统上线后，数据存储面临以下问题：

1. 数据量大，每天写入3000w条数据

2. 数据访问周期长，需支持最近18个月数据高可用

3. 数据库单实例存储空间不够，单实例最高到2.8T

4. 备份恢复均超过5H

其中数据备份和恢复是一个最大的问题，一旦发生数据库故障，我们面临是长时间无法恢复的问题。

　　1.4.1

　　分库

应对单数据库实例巨大的问题，最简单的方案就是分库。针对账务核心系统的特点，我们将系统拆分为账务、会计、日终系统，同理我们将数据库拆分为账务、会计和日终三个库。

在拆分数据库的发布时，针对不同业务场景我们采用不同的策略：

1. 拆分会计库时，因其为异步业务，因此采用的为 Mock 服务，后续定时补的模式

2. 拆分日终库时，因其是日切业务，只有固定时间执行，因为我们选择停机发布

二级库的建设

按照业务场景对数据库进行拆分后，数据库容量确实变小了，但是随时时间的增长，数据实例又越来越大，需要对数据做归档，但是我们需要提供长达18个月的数据高可用的支持，因此将一部分只读的数据归档到二级库中。采用这种策略好处是支持动态拆分，易于扩展。如下图：

　　1.4.2.

　　分表

分库是按照业务维度将数据分隔开，但是我们还面临一个问题是单表的数据容量问题，比如会计分录我们大约每天产生1000w条数据。因此分表就是必须要做进行的工作。账务系统采用的是基于时间的分表策略：

订单采用月分表，分表策略为外部订单时间，单表1亿条

明细账等账务数据采用账务日期分表，单表1亿条

这样的好处是如果数据继续激增，可以缩小分表的时间因子。分表策略如下图：

　　1.5.查询优化

随着数据的增加，对数据库进行了分库和分表，但是访问问题接踪而至。主要问题是：

1. 分库分表以后，变更影响范围大，所有访问系统需要支持

2. 有些系统使用索引不合理，对数据库性能造成严重影响

3. 有些字段无索引，检索慢

数据库访问模型如下：

　　1.5.1.

　　存储结构优化

搭建 ES 集群，屏蔽分库、分表、表结构差异带来的问题，解决无索引字段检索慢的问题。优化后的数据存储结构如下：

其中 ES 集群同步方案采用 Canal，Kafka 的方案，Canal消费离线库的 binlog，只所以消费离线库的 binlog 是因为在线上运行时，发现如果消费 slave 的 binlog，系统性能开销比较大，会导致 slave 与 master 同步有问题。因此采用离线库的方案，这个方案会存在一定的延时，但是我们 ES 集群主要内部运营使用，有一定延时也是可以接受的。

　　1.5.2.

　　搭建统一的查询服务

新搭建了统一查询服务，提供统一的账务数据对外查询服务。统一查询服务结构如下：

动态数据源

针对数据归档问题造成的数据从 A 存储移动到 B 存储的问题，通过动态数据源来解决问题。支持手动和自动变更数据源，针对在一次查询中发生的数据源变更情况，支持自动重试。数据源的动态选择通过 AOP 实现，对原有查询逻辑无侵入。动态数据源的示意图如下：

ES 伪装成数据库

对 ES 的检索我们想实现动态 sql 和对象的自动封装，另外我们之前对数据库的查询都是基于 Mybatis 实现，因此我们对 ES 检索做了一次封装，将 ES 伪装成数据库。通过此方案可以无缝从 Mybatis 切换到 ES 中。代码结构如下：

　　2. 后记

上述内容就是针对一站式资金处理平台的一个简单介绍，其中涉及到一些财务、会计的内容，比如分户账、会计、分录、头寸等具体的概念大家可以百度一下。

整体来说一站式资金处理平台完成多机构、多币种的一站式的资金处理流程，完成虚拟资金与真实银行比备付金的闭环业务。资金处理是一个相对来说比较晦涩的业务，因此花了一些章节来介绍了一个典型业务，一个支付的业务。其中的业务细节都没有讲到，比如逾期利息的处理等，除此以外还有很多业务没有介绍到，比如预付款、欠款业务等。

　　公告通知