yinxin
作者yinxin2019-04-01 11:28
项目经理, 某金融机构

浅谈银行核心系统架构升级

字数 3621阅读 3367评论 1赞 2

核心CORE是Centralized Online Real-time Exchange “集中式在线实时交互的缩写,并不是字面意思的“核心”这么简单。核心CORE是一套银行业务系统的解决方案,每家银行因业务战略不同解决方案也不一样。众所周知在银行业内,伴随着信息技术的发展历程,核心系统的变迁也代表着银行业整体信息技术体系的发展。

本文从系统运维着眼,管中窥豹,分享某行核心系统架构升级相关知识。

核心系统是该行交易和账户处理的中心,承担业务交易处理的职责,是该行信息系统架构的关键的环节,是其他应用系统的业务基础,与其他应用系统有着密切的关系,要求账务数据强一致性,完备的安全机制,7×24小时不间断运行,综合的、完备的、自动化的业务功能,统一的会计核算功能等等。

该行核心系统架构基于开放平台的集中式部署,应用逻辑架构基本遵循着总线架构模式,业务处理层面既承担了后台联机业务处理又承担了银行账务处理功能,实现各类数据标准化和规范化,并按照统一的、唯一的逻辑模型,实现渠道和业务流程整合,建立统一的数据存储和管理中心,实现数据的共享和唯一。如下图示:

q3wu7onb8a1b

q3wu7onb8a1b

渠道接入层:传统的柜面、ATM;手机、网银等电子渠道、以及新兴的自助柜员机等;

交换层:中间业务平台、综合大前置等标准总线统一接入;

后台核心系统业务层:业务层由交易组合组成,负责处理核心业务逻辑。可以根绝功能分成若干模块、组件、服务等;

后台核心系统数据层:数据层是后台数据的存储层,它存放所有核心系统后台数据,并提供标准和非标准的数据封装构件对这些数据进行访问,这些构件由业务层交易进行调用;

后台核心数据交换层:基于核心批量生成的报表数据,以及和外围系统交互的数据;

上述后台这三层是该行核心系统的基础组成部分,涵盖了核心业务交易逻辑处理、交易数据存储,批量数据交换等等主要功能,伴随该行业务快速发展,和互联网金融冲击,如今面临如下问题:

应用耦合性限制:

从应用服务角度来考虑,核心系统本身承载的几个模块服务:存贷产品、公共服务、客户信息、账务核算等,在如今渠道创新、互联网金融、节假日促销的冲击下,它们各自在日常的运行当中提供服务的频率和负载是存在差异的,在这种业务的膨胀式发展场景下,如果继续保持仅一个物理节点资源独立运行,那么必然带来的是应用上和业务上的僵硬。另外一个突出耦合性现象是账务和联机交易耦合性太强,尤其是热点账户账务问题对联机交易影响太过于严重。

系统存在单点风险和容量风险:

从系统基础架构来讲,该行核心系统运行在一台高性能的小型机上,一方面使得系统不具备横向扩展能力,纵向扩容受单台服务器最大处理能力限制,难以持续支撑未来小额高并发业务的持续开展;另一方面在生产服务器发生故障时,切换到备机将会中断全行业务5-10分钟,这对该行生产系统运行是一个极大的风险隐患。

数据安全局限性限制:

该行核心系统的数据保护基于存储复制技术和离线零级备份实现。存储复制技术能有效应对物理故障,但是在发生数据逻辑故障时,就显得无能为力了,而离线零级备份虽然能应对逻辑故障,但是数据恢复时间过长,严重影响该行持续对外服务能力。

基于以上,该行核心系统此次升级,从“业务规模、经营范围、各项成本、安全运营”等多角多维度度考量,制定了总体设计目标。

8eqri2ua8cid

8eqri2ua8cid

在对同业核心系统充分调研和主流架构技术充分POC测试后,制定了该行核心系统升级总体设计方案,要求核心系统的联机交易、联机批量、日终批量等各项服务处理性能需大幅提升,需实现秒级容灾切换,年终决算不停机等高可用目标。方案制定的逻辑架构图如下,下文会一一介绍到。

fyimz3rq68h9

fyimz3rq68h9

负载均衡为基础的总体架构设计

本次架构改造的关键词就是“分拆”。首先将系统分拆成数据库和应用服务器两大部分。然后将数据库分为写库和读库,并且写库集群部署,具备纵向和横向扩展能力,读库采用多套部署方式,也具备双向扩展到能力。最后将应用服务器改造为读写AP和只读AP,并实现多机负载均衡,同时系统还设置开关可以实现只读AP和读写AP交易的动态切换功能。

充分考量容灾的AP和DB的系统架构设计

基于上述系统存在单点风险和容量风险的隐患,从服务角色维度出发,AP和DB物理拆分为只读AP、读写AP、读库DB、写库DB,使各角色AP、DB各司其职,各角色AP采用支持横向扩展的负载均衡架构,各角色DB采用高可用的集群部署模式。AP和DB发生单点宕机故障时,集群中其他AP和DB可以实时接管全部业务,业务交易几乎无感知;同时在整体数据中心发生故障支持一键式快速整体切换设计,从而实现核心系统的高可用、高并发、高性能。

业务模块充分解耦的应用架构设计

应用业务模块的剖分解耦,业界没有统一定义,也没有统一标准,需要根据各自业务发展模式特点来进行。该行核心应用通过连接综合大前置实现处理,此次该行核心系统升级,连接接入方式不变,但对业务模块进行了精细化设计拆分后,对拆分出的各个业务模块选择合适的负载均衡架构部署,实现了分布式处理,使得整个核心系统更模块化、灵活化,同时又完善了校验机制从而保障了整体业务逻辑的完整性和一致性。

分散热点、提升并发的数据库架构设计

在数据库设计方面,部署数据据库多套集群承载不同业务;对热点数据集中的库表进行了分库分表;登记交易报文使用异步提交;分区字段索引调整调优等等一系列优化设计方案。在进行了充分的功能验证测试、非功能性能测试后,对核心系统整体TPS,批量处理效率提升效果明显。

兼顾负载分摊和数据安全的读写分离设计

该行核心系统的查询交易量占比接近50%,但该部分读交易对资源占用占比也接近50%,存在读交易、写交易在压力大情况下的互相影响情况,可以从核心系统减压分流考虑,分散交易的集中度。

1.从交易码、渠道信息等业务特性进行服务名的映射,将交易路由转发至承载不同的读、写功能AP物理主机上,实现交易级别的读写交易分流。当只读AP在突发物理故障时,由于只读AP也采用多机负载均衡架构,其他只读AP能够自动均衡接管该故障服务器负载;当读库DB和写库DB的数据同步延时因为网络和其他原因超过阈值或者异常中断时,应用能够自动快速隔离受影响的只读AP,并实时将交易重新路由到读写AP之上。

2.基于上述容灾设计的读库DB和写库DB,使用了当下最成熟稳定且同步延迟最小的的数据库级日志复制技术,可以实现写库DB“一拖多”同时复制到多套读库DB,多套读库DB可位于同城中心和异地中心。写库DB上更改生成重做日志, TCP传输至多套读库DB,多套读库DB实时应用更新这些重做日志,从而完成数据一致性。在实现了读库DB集群化的多活的同时,又稳定提升了系统整体处理能力。

3.写库DB和读库DB数据这种分离部署,还解决了数据安全的2个痛点:存储复制不能有效应对数据逻辑故障,离线零级恢复时间过长的问题。当写库DB遇到数据逻辑故障导致不可用的极端场景下,可以立刻把一套读库DB的数据库状态转换为支持读、写状态的“新写库DB”,由该“新写库DB”继续承载核心系统所有交易,并且读库具备快速闪回到过去24小时任何一个时间点的能力。

多级分层和特殊需求识别的IO优化设计

核心系统的业务特点7×24小时不间断运行,白天工作日时段并发压力大,晚上跑批处理,IO性能要求高。在IO性能优化层面主要进行以下重点设计:

1.在操作系统层面和存储进行了相互匹配的多级条带化设计,确保无论是存储上的物理磁盘,还是操作系统和存储层面的逻辑磁盘均不会产生热点;

2.识别系统中特殊的IO行为,然后进行区分对待,如要求响应时间特别高的日志写IO与其他IO进行隔离,可以采用单独的IO通道和单独的逻辑磁盘进行处理;

3.通过持续的性能压力测试,持续优化操作系统和存储层面的IO设置参数。通过上述的优化设置,有效提升整个系统IO的响应时间和吞吐量,批量高峰期IOPS达到30万,而响应时间基本在2ms左右。

此次核心改造虽完成了该行既定的目标,但面对互联网等新兴金融模式的高并发业务冲击,仍需居安思危、坚持不懈的对核心系统持续优化。未来核心系统趋势应逐渐转向“瘦核心”架构;交易核算彻底剥离,解决账务和联机交易耦合问题,提高交易高并发处理能力;以产品工厂模式设计思路彻底解耦,通过模块化的松散组合,实现产品灵活性定制、应用的灰度发布和快速交付效率;应用设计出支持完整的原子的正反交易,实现交易补偿机制来保证数据强一致性;用成熟的开源主流技术新建互联网核心系统,来承载互联网等新兴业务也无外乎一种思路。但这些优化设想都需要从银行自身运营情况综合考量,涉及到组织架构、基础架构,业务、开发、运维等,需要诸多部门协作,共同解决,需要更细心的分析和摸索,看大做小、分步实施,不能一蹴而就。

以上就是本次分享内容,希望大家阅读后对核心系统升级有所了解。

文章来自“匠心独运维妙维效”微信公众号。作者:张明

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

2

添加新评论1 条评论

michael1983michael1983技术总监, 某证券
2019-04-01 17:06
认真学习,瘦核心是大趋势。
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广