银行分布式系统转型实践.docx

银行分布式系统转型实践.docx

《银行分布式系统转型实践.docx》由会员分享，可在线阅读，更多相关《银行分布式系统转型实践.docx（7页珍藏版）》请在冰豆网上搜索。

银行分布式系统转型实践

银行分布式系统转型实践

针对开源技术自主掌控的难题，建议建立中国银行业的开源软件同盟，利用产业链的力量，确保开源软件使用的安全性、功能的健壮性和维护的可持续性，为银行定制，为银行所用;银行与供应商共同建设和维护为银行科技服务的开源社区生态环境，主导开源社区的发展方向，维护独立的版本分支，让开源软件为银行服务，而不是银行削足适履去适应开源软件。

在安全可控的国家战略、海量高并发的访问需求、节约化经营模式的转变等内外部因素共同作用下，商业银行正面临着IT架构转型的任务。

随着开源开放的分布式技术逐渐成熟，并在互联网企业中得到充分验证，为商业银行开展IT架构转型提供了技术保障，商业银行开展分布式架构转型势在必行。

传统的商业银行信息系统有两大类型：

交易型系统和管理分析型系统，从集中式向分布式转型，是一个复杂的过程，尤其是银行账务处理相关的交易型系统。

交易型系统平台从操作系统来看有几种：

IBMOS390、IBMAS400、UNIX、LINUX。

第一种和第二种为IBM封闭的集中式系统，第一种虽然有Sysplex并行耦合体架构，但是数据持久化层仍然是集中式的;第三种和第四种为开放平台，普遍采用三层架构，即接入层、应用层和数据持久化层，接入层和应用层在技术上已经具备了“无状态”特性，广泛使用分布式集群模式，而数据持久化层却依然保持传统集中式架构。

因为数据是“有状态的”，数据的分布式会带来数据一致性等许多复杂问题，所以商业银行开展分布式架构转型的难点在于核心交易系统的数据持久化层的分布式转型。

一、实现数据持久化层的分布式处理

商业银行的核心交易系统要做成分布式系统，需要一个适合银行应用特点的分布式数据库，以支持核心交易系统沉淀了多年的成熟稳定的业务处理逻辑保持不变。

根据银行应用特点，我们认为适合银行交易系统的分布式数据库，在关系型数据库基础上，必须具备分布式事务实时一致性、高并发的交易处理、在线数据重分布以及全局一致性的备份和恢复功能。

除此之外，由于CAP理论无法突破，我们还要与应用深度结合找寻C与A的最佳平衡点。

1.实时一致的分布式事务控制功能

分布式数据库必须具备实时一致性事务控制能力，满足银行业务对数据实时一致性的要求。

首先，分布式数据库的原理是依靠多个独立数据库节点通过网络连接协同工作，任何一个节点和网络都有可能出现故障，这是分布式数据库区别于传统集中式数据库的最大特点，这就造成了“局部故障”概率大大增加;

其次，客户在银行办理业务时，不会接受每次查询看到自己的账户数据不准确，这会影响用户体验，这就是银行业务必须实时一致的原因;

最后，现有的银行应用系统均基于集中式数据库实现，应用程序不需要过多考虑事务处理，如果分布式数据库不提供分布式事务能力，迁移成本和开发成本均会大大增加，实施难度也增大。

因此，实时一致性的分布式事务控制能力是分布式数据库必须具备的功能。

2.高并发交易处理功能

分布式数据库必须具备高并发交易处理能力，满足海量客户交易需求。

随着物联网、互联网金融、双十一秒杀等技术和消费场景的出现，银行业务并发交易量有了极大的增加，对银行应用系统的并发交易处理能力提出了更高的要求。

分布式数据库作为应用系统新的数据持久化层解决方案，在处理好分布式事务实时一致的同时，必须增加并发处理能力，缩短平均响应时间，满足海量高并发处理需求。

3.在线数据重分布功能

分布式数据库必须提供在线数据重分布能力，满足扩容的需要。

分布式数据库区别于集中式数据库的最大优势是可以通过增加数据节点数量获得处理能力的线性增长。

但增加数据节点数量就涉及到数据的搬迁移动，即数据重分布，数据重分布期间对相应数据的访问一定会受到影响。

对于7×24小时的应用来说，在线的数据重分布是分布式数据库必须具备的功能。

4.全局一致的备份和恢复功能

分布式数据库必须提供全局一致的备份和恢复功能，以确保数据随时可恢复。

线上运行的数据库虽然具有回滚等功能，但对于已经提交的误删除操作，数据库是没有办法阻止和回退的，这种情况下只能通过前期数据库备份镜像和前滚日志按时点进行恢复。

分布式环境下，由于各个数据节点备份开始和结束的时间点不可能完全一致，导致恢复后的数据库全局很难保持一致状态。

因此，分布式数据库必须提供全局一致的备份和恢复功能，满足业务恢复的需要。

5.与应用深度结合找寻C与A最佳平衡点

之所以说分布式架构中最大的技术难点在于“数据持久化层”的分布式改造，原因在于数据分布之后在满足高性能前提下实现全局ACID特性是不现实的，著名的CAP理论阐述的就是这个限制，即数据一致性C、数据可用性A和分区容错性P三者不能同时满足。

在这三者之中，分区容错性P是必须满足的，因此只能在C和A之间进行选择。

但银行业务特点又要求必须保证数据的实时一致性以及高并发场景下的数据可用性，这与CAP理论是矛盾的，所以我们必须将分布式数据库与应用深度结合，如多级分片的策略制定、分布式Join、数据分页等，有些数据库无法解决的问题，由应用去解决，找到C和A的最佳平衡点，发挥分布式技术优势，达到系统最佳的扩展性。

二、打造分布式系统上下游生态环境

要实现分布式架构转型这个任务，只有分布式数据库是不够的，应用系统还需要支持分库的设计，才能实现数据库的横向扩展能力。

另外，我们还需要适合分布式架构的开发工具和智能运维，形成分布式数据库的生态环境。

1.应用数据采用分库技术

分布式数据库实现分布式架构下的数据持久化功能，业务系统还需要采用分库的设计，才能支撑大型系统在分布式架构下的横向扩展能力。

主机集中式架构和开放集中式架构的银行核心系统有个共同的特点是单一数据库系统，规模庞大、功能繁杂，经过多年的业务逻辑沉淀形成了相对稳定成熟的业务处理功能，我们在进行分布式系统改造时，尽可能使这些成熟稳定的业务功能保持不变，把系统改造的工作量降到最低。

需要采用分库的设计，把同一个数据表分布到各个节点的库中，逻辑上是一个数据库，物理上是多个数据库，使数据能够横向扩展，才能支撑大型系统在分布式架构下的横向扩展能力。

大型互联网企业使用SBF数据分布模型（S分区键，B数据桶，Family表族）对业务数据库进行分库分表，其核心思想是应用数据逻辑态与物理态的隔离，从而实现高可用和故障隔离。

我们针对银行应用的特点，采用数据库分库的技术，即把同一个数据表的记录拆分到多个数据库中，设计分片键和算法，使传统的一个数据库变成多个数据库的集群，实现数据库的扩展能力。

针对银行业务的复杂性，采用多级分片的技术进行数据库分库设计。

汲取互联网行业经验，同时要支持分布式事务，针对银行业务数据表的特点，以客户号作为主分片键，与某一客户相关的所有业务数据都分布在同一个数据库中，尽可能减少分布式事务的产生。

根据银行交易系统的特性，采用以下三种分库策略：

（1）参数类表的数据量小，将其放在同一个数据库分区中，不仅性能完全可以满足要求，而且还归避了分布式事务的发生。

对于读多写少的参数表，使用分布式缓存提高访问性能。

（2）流水类大表的数据量会不断地增长，将其按照主键进行hash分布到多个数据库分区中。

这类表还有一个特点是插入数据场景远远多于更新，基本没有分布式事务。

（3）业务主表存在分布式事务，例如账户之间转账的场景，统一采取客户号为主分片键的策略。

2.面向分布式系统的开发平台

为了降低分布式应用项目的开发成本，需要一个面向分布式架构的开发平台，结合分布式数据库、分布式缓存、微服务框架、服务管理和发布流程等方面做统一的集成和接口封装，支持分布式应用的开发和管理。

（1）分布式数据库和分布式缓存接口封装

首先，分布式数据库要支持JAVA语言定义的标准数据库编程接口，结合底层数据节点（比如Mysql）的驱动程序，使用驱动程序的负载均衡功能，实现一个应用可连接多个数据库，从而增强数据库访问的高可用。

其次，将用户登陆等状态数据存储在分布式缓存，应用服务实现无状态。

针对分布式缓存实现标准接口，屏蔽本机缓存、单机和集群差别，简化应用调用，支持直接将内存对象序列化后存储在缓存中。

（2）使用微服务开发框架实现服务拆分

从应用层面进行微服务改造，将传统的粗粒度的业务单元拆分为可独立交付的细粒度业务单元，借助微服务开发框架，解耦应用模块，简化配置操作。

改造后的小业务模块可以快速独立地开发、测试、部署和运行，降低变更影响范围和测试验证工作量，适应敏捷的开发方式，提高交付速度。

（3）基于开源软件搭建分布式服务架构基础设施

基于开源软件搭建分布式架构基础设施是互联网行业的通用做法，极大地简化了服务的开发、部署和运行效率。

首先，利用服务治理中心可以实现服务的注册发现和故障转移;其次，通过API网关的能力，整合所有服务，形成统一出口;最后，通过服务检测机制，实现服务自动负载均衡路由能力以及异常情况下服务的熔断。

3.实施Devops体系

分布式架构的实施需要新的Devops体系的支持，增强团队之间协作性和高效性，消除开发与运维团队之间的鸿沟;分布式架构的技术特征适应微服务框架和敏捷式开发方法，也要求应用系统具备快速迭代的持续部署能力，缩小每次投产的影响范围，降低系统运行风险，这是传统的“开发和运行分离的体系“无法支持的。

新的Devops体系实现开发团队和运行团队的协作，依靠简明、自动化的流程和工具，提升组织的效率，让研发人员有运维意识，让运维人员掌握设计思路，提高交付产品的可维护性。

基于DevOps理念，借助容器云的系统规划、场景设计、产品选型和测试，将银行的实际需求和容器最佳实践相结合，在微服务、应用容器化改造、弹性扩展、灰度发布、提供标准化、敏捷化的开发交付能力。

借助IaaS平台实现强健稳定、按需分配、弹性扩展、快速部署、开源开放的基础架构平台，为PaaS平台建设提供坚实的技术支撑，并进行SDN对接，存储自动化管理等工作，继续推进计算、存储、网络等资源池化，并优化云管理调度平台，实现全生命周期管理。

4.分布式应用系统运维

为了实现分布式数据库大规模集群环境的运维管理，必须具备一套运维工具，实现自动化部署、统一指标和日志监控、运维管理工作台、数据库版本滚动升级等管理和维护功能，使运维自动化、工具化，降低运维难度，提高运维工作效率。

（1）自动化部署

分布式数据库集群动辄有几十甚至上百台节点，上线部署工作复杂，需要配置自动化部署工具，在各个集群节点之间同步程序包和配置项，在降低部署工作量的同时，可以大大减少人工操作出错的几率。

（2）统一指标和日志监控

分布式数据库集群动辄有几十甚至上百台节点，各种日志信息繁多，需要集中管理和监控功能对各种运行指标和日志信息进行采集、监控和预警，根据日志快速定位问题，统一展示分布式数据库各节点工作状态。

（3）运维管理工作台

分布式数据库集群动辄有几十甚至上百台节点，日常运维操作需要同时在所有节点执行，需要统一模块进行配置、规划和执行，如集中备份的执行、在线重分布的启停、日志归档、DDL语句的修改等。

（4）滚动升级和灰度发布的支持

分布式数据库集群动辄有几十甚至上百台节点，一次性全部升级难度增大，且降低业务连续性，需要滚动升级的支持，确保不同版本之间的兼容性;分布式数据库也需要支持灰度发布功能，抽取部分客户在部分节点使用新投产功能，根据实际效果逐步扩大范围，最终在风险可控的情况下完成灰度发布功能。

三、分布式系统生态的可持续发展

1.内外部力量结合掌控开源技术

分布式系统用到很多开源技术，开源软件以其源码免费开放、获得成本低、易定制化开发等优势在互联网领域广泛使用。

但是开源软件种类繁多，质量稳定性差异大，是否是主流方向有诸多不确定性，野蛮生长态势明显，缺少固定厂商对产品质量负责，银行要想使用新技术，必须要达到完全掌控的程度。

但短期内银行靠自身力量全部掌控分布式技术不现实，需要与国内具有相应实力的科技企业联合，发挥各自的技术优势，最终达到联合掌控的目的。

2.联合建立银行业的开源社区

开源软件背后的团体是有其商业诉求的，以“技术服务”代替“软件许可”的商业模式也可能改变，存在开源转闭源的可能，对使用者带来了很大的风险。

另外，开源不等于免费，开源软件也有著作权和协议，使用过程中即使是无意识的操作不当也会面临法律风险。

针对开源技术自主掌控的难题，建议建立中国银行业的开源软件同盟，利用产业链的力量，确保开源软件使用的安全性、功能的健壮性和维护的可持续性，为银行定制，为银行所用;银行与供应商共同建设和维护为银行科技服务的开源社区生态环境，主导开源社区的发展方向，维护独立的版本分支，让开源软件为银行服务，而不是银行削足适履去适应开源软件。

在新兴信息技术和新型架构应用中，以确保技术先进性和可用性为原则，选择主流的开源社区，认清其发展方向，积极跟踪研究，加强对开源软件代码的掌控，逐步应用开源，提高银行科技的核心竞争力。