分布式技术在银行应用中的思考

潘舟

分布式的产生背景

一直以来，金融IT采用传统的集中式系统，比如银行核心系统往往使用较高配置的大型机，通过软硬件的不断优化，在应对传统业务时一般还是游刃有余的。但是随着业务发展特别是电子商务浪潮的袭来，集中式系统的性能遇到真正的考验，如天弘基金跟阿里合作刚开始只是把系统跟余额宝的渠道对接，交易量得到明显的提升，但随之而来的就是原有的系统无法支撑这么大的业务量，后续只能应用分布式技术进行重构。互联网竞争激烈并且发展迅速，与传统银行不同的业务差异、成本控制等因素要求其积极实施分布式IT架构转型；当前银行竞争也在不断加剧，传统银行的业务和技术已经不局限在金融领域，我们银行IT人员也要向互联网企业进行深入学习。

为什么要学习分布式呢？通过技术角度来说明，以数据库为例，如果一张Oracle数据库中的表，数据量超过5000万甚至上亿，一个SQL的执行时间就有可能花费几分钟，如果并发量再大的话，系统基本就瘫痪；另外，这种量级的流水要日终处理，如果是一台机器的话，即使其满负荷运行，到第二天开门也可能处理不完。这种数据量在我们传统的业务模式下基本上是不会遇到的，但在互联网的模式下却是必须要面对的。Oracle数据库应对数据量在2000万以下的表还是没有问题的，如果超过这个量就会面对比较大的挑战，即使升级硬件资源也很难根本解决。

银行为什么要用分布式

1. 业务场景的需要

当前大家常用的互联网产品有个显著的特点：大并发、大数据量。这种现象早期也是很大的问题，要解决这个问题能想出最好的方案就是将大的拆成小的，然后再并行处理。其实就像这样一个例子：一个大型的任务要在规定的时间内完成，是找一个很牛的人来干，还是找一堆普通的人一起来干的道理是一样的。这个机制其实就是分布式的理念，所以说分布式给互联网业务场景提供了一个非常好的技术手段。

2. 性能及高可用的需要

在分布式的机制下，如果任务量大了，只需要增加执行节点就可以解决问题，执行节点多了，整体的处理能力和性能都会提升；还有一点很关键，分布式是多个节点一起工作的，如果其中的一个节点出现问题，其只影响很小的一部分（况且容错机制还会把这个节点的工作分解到其他节点上执行），但如果是集中式系统，其如果出问题将是全局性的，这其实体现的是系统的整体可用性上的差别。

3. 成本的需要

集中式系统对单体资源的要求比较高，就好比要找一个牛人，如果任务很重，就必须换成更牛的人，但高端资源的成本将是成指数型上升，况且在一定情况下，即使付出很高的成本也未必可以找的到。如果用分布式的机制来处理，其需要的是普通的资源，只是数量的多少问题，一般情况下一个高端资源的成本要远远大于多个普通资源的成本之和。所以，在互联网模式下采用分布式的成本投入是要小于集中式的。

4. 安全自主可控的需要

银监会对银行信息化建设提出了“安全自主可控”的要求，由于集中式架构对硬件及数据库的依赖非常高，并且有一定的安全隐患，所以要达到银监会的要求，就必须对系统进行架构层面的调整。分布式通过用多个普通的硬件一起工作来替代一个集中式的高端资源，是解决这个问题的一个非常好的手段。

银行分布式的应用领域

1. 服务层的分布式

应用的逻辑处理节点能力不足，比如银行的业务受理节点、账务处理节点等，因为多渠道多系统需要调用该服务，瓶颈有压力时就可以考虑对服务层的能力进行拓展，增加对外系统的支撑能力。

具体做法上，保证应用可以按需增加实例节点，应对应用层的高并发压力；同时支持微服务的运行机制。

2. 数据层的分布式

大业务量是如今系统的必然趋势，大业务量对于银行系统来说代表着大数据量，如何高效地保存和读取数据也是分布式的一个重要课题。文章最开始的例子已经做了简单介绍，应对亿级数据的挑战，银行需要采用分库的机制，不仅降低了每个库中的数据量，而且增加了数据存入与读取的使用效率。

3. 缓存层的分布式

我们一方面考虑并使用分库来持久保存数据，另一方面也要针对临时数据进行缓存机制的优化。针对应用处理中需要使用到更多的非落地数据，引入分布式缓存的机制，将公共数据临时数据缓存化，可以大大缩短交易的单笔响应时间。

4. 日终计算层面的分布式

传統银行在日终需要进行核心跑批，往往都要几个小时，在关键日期如年终结算时由于计算数据量更大耗时更久，对银行系统压力较大。采用分布式的机制进行日终的计算密集型处理（结息、计提等），多台机器、多台数据库全部参与运行，保证日终的执行时间控制在一个合理的范围内。

以上4层的分布式，都可以根据实际情况通过扩展物理节点来提升其对应的处理能力。当然，初期可以将物理节点控制在一个相对较小的范围，到时机成熟的时候再进行扩展。也就是在这个体系下，即保证了系统的先进性，又可以合理的控制风险，还可以保证系统的长期可持续发展。

总结与展望

当前背景下的主要挑战是高并发、大数据量，也就是主要矛盾。我们用分布式解决这个主要矛盾的时候，由于系统在设计、开发和运维层面比以前复杂，可能带来一些其他问题。但是，不能因为这些影响就放弃使用分布式，否则主要矛盾就解决不了。针对不完善的地方，我们将更加积极的投入分布的研究，哪里需要提供横向伸缩的机制，哪里就可以考虑使用分布式。