实战丨招商银行分布式交易平台建设
时间:2023-08-16 16:48:02 | 来源:网站运营
时间:2023-08-16 16:48:02 来源:网站运营
实战丨招商银行分布式交易平台建设:
招商银行信息技术部基础设施研发中心副总经理 尤堂成
项目背景随着招商银行全面贯彻“金融科技银行”的战略方针,基于移动互联网的高频访问场景将成常态,客户交易量以平均30%的比例高速增长。这些新增的交易主要来自于主流互联网企业,如蚂蚁金服、腾讯、滴滴、摩拜等,具有如下特征:
一是高并发,特定时间段峰值极大、金额小、频度高,存在抢购等业务场景(如“双11”),系统需要支持短时间高并发交易量的冲击。
二是实时要求高,业务处理的响应时间要短,过长则影响客户体验。
三是事务的强一致要求,特别涉及到资金业务,系统的数据必须要做到准确一致。
四是可用性要求极高,为了更好地支持客户服务质量,系统需支持7×24小时无间断服务。且受到监管部门的要求,对于意外宕机等时间都有着极其苛刻的要求。
传统的银行联机交易平台在支持这类交易的时候,一般使用垂直扩展,即升级主机型号的方案。该方案的缺点在于以下几个方面。
一是成本高昂。每年投入巨额资金和大量人力进行相关主机的升级工作,以满足日益增长的交易需求。
二是性能上限。近年来,招商银行采用的服务器已经逐步升级到了顶级机型,但在峰值来临之时仍不免捉襟见肘。
三是资源浪费。在非峰值期间,又会造成主机资源的浪费,不能充分利用计算资源。
四是系统封闭。大中型主机目前全部由IBM、HP等厂商垄断,缺乏竞争,一方面导致银行方议价能力不足;另一方面主机封闭的技术体系也不利于技术人员的培养和补充。
针对以上传统银行交易平台的一些限制,招商银行亟需开发一套新的分布式交易平台。
项目介绍2015年,招商银行启动了分布式交易平台项目建设,该平台采用了分布式微服务部署架构,包含了四个基础部分:高性能的运行框架、平台化管理的服务中心、覆盖全生命周期的设计开发管理中心、可视化的监控中心。
1.高性能的运行框架。分布式交易平台提供了自主研发的高性能的运行框架,通过优化通讯接入、内存管理、数据库调用等技术,极大地提升单数据库服务器和单应用服务器的处理能力。采用分布式微服务的部署架构,可以横向扩展数据库服务器和应用服务器,使用集群的方式线性提高整体处理能力(见图1)。
图1 高性能的运行框架运行框架实现统一的通讯接入层。通过对通讯参数和内存的优化处理,为应用提供一个高性能的通讯接入,实现单机2000TPS(每秒交易数)以上的交易处理量;通讯接入层还统一提供各种报文格式的转换,涵盖了招商银行绝大部分报文格式,如网联、银联、手机银行等报文格式,使开发人员无需面对多系统对接带来的困扰,能够更加专注于业务功能的开发。
运行框架统一实现运行调度层。提供统一的内存管理,为每笔请求分配独立的内存空间,并在请求处理后进行有效回收,提高应用的处理性能;提供统一的事务管理,包括单库的事务处理及TCC分布式事务处理,保障数据的一致性;统一收集应用的性能数据,如业务量、响应时间、成功率等非功能性指标,对系统进行有效监控。
平台提供大量的基础服务,如加密处理服务、系统参数服务、短信通知服务、Kafka消息队列服务、并行计算服务等,开发人员可以通过服务的形式直接使用,无需自行再次开发,简化开发的难度。
分布式交易平台充分考虑招行运行中心的实际情况,支持在多种系统平台中部署,支持多种数据库,软硬件资源可以灵活搭配,不同的应用场景可以提供不同的套餐,提升性价比,降低开发运维成本。
应用系统可以根据可用性要求选择不同类型的数据库,如对可用性要求高的系统可以使用Orcale,可用性要求低的可以使用MySQL,实现最佳的性价比。
应用系统还可以根据个性化需求选择Nosql型数据库。如对于需要存储海量数据的系统可以选择HBase,对于响应时间要求极高的系统可以选择Redis内存数据库来提高性能。
分布式交易平台支持多种数据库高可用部署架构,不仅包括常规的数据库同城热备异地灾备的方案,同时开创性地实现了数据库异地双活的部署架构。
2.平台化管理的服务中心。分布式交易平台的应用部署采用了微服务的体系架构,将业务功能组件化和服务化,并利用统一的服务中心管理所有服务(见图2)。提供了统一的资源管理、服务注册、服务发现、数据路由功能。
图2 分布式交易平台服务中心统筹管理平台的所有应用服务器资源,根据每个服务的业务量需求分配相应数量的服务器资源,并可根据业务量的变化动态进行资源的调整。如面对“双11”场景时可临时增加服务器资源,“双11”过后释放过剩的服务器资源,实现资源的共享利用。
服务中心为服务之间调用提供服务注册、服务发现及数据路由功能。服务提供者应用在启动时,向服务中心注册自己提供的服务,并标识自己的活动状态。消费者在启动时,向服务中心订阅自己所需要的服务,服务中心返回服务提供者的地址列表及数据路由信息给消费者。当服务提供者出现变更时,比如增减了服务实例等,服务中心将实时推送变更信息至消费者。消费者根据得到的服务提供者地址列表及数据路由信息,基于负载均衡算法选择其中一台服务提供者为自己提供服务。实现了透明化路由,解耦了消费者与服务提供者;增强了服务伸缩能力,动态扩展服务后服务中心会自动将新增的服务器主动推送给客户端。
3.覆盖全生命周期的设计开发管理中心。分布式交易平台配套开发了覆盖软件过程全生命周期的设计开发管理中心。涵盖了设计管理、开发管理、编译构建、发布管理等功能。
在设计管理上,根据开发团队多年以来摸索出来的理念和经验,将设计流程与设计文档固化在平台中,一方面将设计工作标准化,同时又解决了文档难以持续更新的问题。大幅降低设计人员与开发人员之间的沟通成本,提高开发效率。
相较传统的设计文档孤立存放于文档服务器,设计开发管理中心将设计工作内嵌之后,后续的开发、编译、发布环节均基于设计内容,因此设计人员必须实时更新设计结果;同时,设计人员必须将设计内容细化到平台要求的粒度,消除原有设计文档空心化的现象。
在开发管理上,通过版本规划及任务分配,方便项目经理实时掌控项目进度,提升项目管理水平。传统的开发过程中,项目经理通过WBS了解开发进度,但实际存在WBS更新不及时导致项目经理无法了解当前进度。设计开发管理中心允许项目经理实时查询开发人员分配情况及程序开发完成进度,便于版本控制;另外,相对于原有的开发模式,目前平台自动化生成的标准代码占比有所提高。
在编译构建和发布管理上,管理中心与行内的Artifactory制品库、版本管理工具RTC、软件过程管理工具VP、Devops流水线等进行无缝对接,实现软件产品安装发布的自动化,提高发布效率,为大规模应用集群的部署提供了便利。
4.可视化的监控中心。微服务的设计思想使得一个业务功能被拆分成一组服务来实现,每个服务只完成一个简单的功能,一笔完整业务请求被拆分成多次服务调用,这给业务运行及系统运维带来了一定的复杂度。
分布式交易平台为每一笔业务请求分配全局统一的请求标识号,并在服务调用时进行传递,有效地将多次独立的服务调用串联成一笔完整的业务请求。通过对请求标识号的采集,可以实现交易链路跟踪,方便业务人员了解业务数据在系统间的流转,同时方便开发人员分析定位系统异常,大幅提高了系统管理水平。
分布式交易平台为业务应用统一提供了系统异常告警功能。监控中心利用大数据智能化的算法分析,及时发现系统的异常行为,如交易量的异常波动,错误率的突然提高,错误码的动态变化等,并通过短信和招乎向应用负责人员发送告警消息,方便运维人员及时发现系统异常,防患于未然。
分布式交易平台建立统一的监控中心。监控中心采集平台的性能数据及运行状态数据,实时通过图表等可视化的形式直观展示系统的运行情况。
监控中心的分析结果支持多种终端展示,包括电视、电脑、手机、PAD等,其中手机和PAD的监控展示集成在移事通办公平台中。方便运维人员及时查看系统运行情况,特别是运维人员不在行内时,可以通过手机快速了解系统运行情况。
监控中心实现了告警消息推送机制。监控中心通过分析系统的交易量、成功率及响应时间等数据,识别异常波动,自动通过短信、招乎等方式发送告警消息至相关产品负责人,及时发现系统异常,保障系统稳定运行。
图3 可视化的监控中心
结语招商银行分布式交易平台,是招商银行立足当前,着眼长远,从彻底解决主机性能问题,适应移动互联网时代高并发、高可用、可扩展的业务场景需求出发,自主研发,搭建起的一套全新交易平台。
该平台通过提供标准化的开发框架和组件,支持应用系统对数据库分库定义和路由规则设置,实现了数据分库分表、数据冗余和交易负载均衡;数据库采用“集群+分库+双活”架构,实现了站点内故障自动切换,两地秒级切换,日常维护不停机;通过热点消除、“写冲突”避免等一系列软硬件优化,实现了系统每秒处理15000笔交易时,平均响应时间低于10毫秒;通过对业务数据进行分片,降低了数据库分库间的耦合,让线性提升性能更快实现。
该平台的成功实施,为招商银行未来进一步稳步发展打下了坚实的基础。