银行核心系统的现代化改造,华为的答案是重塑敏捷和重塑韧性

简介: 自2014年起,国内银行纷纷向分布式架构转型,将系统分为核心系统与外围服务系统。然而,核心系统面临架构老化、处理能力不足等问题,亟需转型。华为在2024全联接大会全球智慧金融峰会上发布了《现代化金融核心系统白皮书:实践篇》及金融分布式新核心解决方案5.0,提出“1+3+N”架构,涵盖工程工艺、多活架构、数据库架构、智能研发和一体化运维五大升级,助力银行核心系统向分布式转型。通过与众多合作伙伴联合创新,华为为银行提供了系统化的转型方案,推动金融行业的持续发展。

自2014年开始,国内的银行机构纷纷向分布式架构转型,并像同心圆一样把系统分成了两个部分:

内层的小圆是核心系统,承载了银行存款、贷款、银行卡、清算核算等业务,被比作是“银行跳动的心脏”;外层的大圆是外围服务系统,包括营销、风控、用户体验等业务,也是最早用新技术改造的对象。

过去十年时间里,随着科技的发展,陆续衍生出了手机银行、互联网金融、大数据风控等创新应用,但核心系统却出现了架构老化、处理能力不足、硬件故障多发等问题,以及伴随国家宏观政策的指引,核心系统转型迫在眉睫,不少银行在核心系统外投入了大量的精力。

核心系统作为银行数智化转型的“一把手工程”,重要性不言而喻,同时也存在易用性、迁移难度、投入产出比等一连串“疑虑”。能否为摆在眼前的问题找到最优解,直接影响着现代化金融核心系统的改造进程。

华为全联接大会2024的全球智慧金融峰会上,联合伙伴正式发布了《现代化金融核心系统白皮书:实践篇》(下称白皮书2.0),以及全新升级金融分布式新核心解决方案5.0,为现代化金融核心系统的演进提供了新范式。

01 转型进入深水区,需要一份“全局地图”
有人曾这样形容银行核心系统的改造,“相当于给正在跳动的心脏,做一场不停摆的换心手术”。

在快速响应、敏捷弹性的需求下,如何构建高可扩展性、高成本效益、高敏捷性的金融核心系统,已然成为当前金融机构普遍关注的问题。阻力恰恰出现在实践过程中,且不难梳理出四大常见痛点:

一是工程实施难,新核心系统的建设普遍需要12个月以上,典型的投入资金大、时间周期长,不仅无法满足“敏捷”的诉求,投入产出比也是一道必答题,需要采取合理的实施方法、路径和步骤。

二是传统核心跨数据中心容灾能力弱,传统集中式核心系统在同城双中心的容灾架构上一般能做到应用双活,但核心数据库架构还是采用单中心+同城容灾的模式,因此遇到IDC级别或者主中心核心数据库故障时,在数据层的爆炸半径较大,跨中心切换RTO较长,部分数据库还做不到RPO为0。

三是开发效率的低下,由于核心系统涉及的项目数量多、规模大,优秀的软件开发工程师招聘难,而人才供给上的不足,慢慢形成了两个“高成本”:人力成本高、复杂的技术难题定位成本高。

四是运维的复杂性,银行核心系统的数据庞大、业务繁杂且关联性强,云化分层部署后,故障界定复杂且耗时长。再加上99.999%的可靠性要求,运维团队要么在诊断故障,要么在响应和处理已经发生的故障。

正是因为这些痛点的长期存在,载银行加速数字化转型进程中,在全面提升数字化经营与服务能力的要求和大趋势下,不少银行的核心系统演进并不算顺利,甚至可以用缝缝补补来形容。

个中原因并不难解释。

如果只盯着某个或某几个痛点做方案,大概率会陷入“身在此山中”的误区:单个痛点很容易解决,可核心系统的转型越深入,遇到的问题和痛点就越多,问题之间往往互相关联,最终陷入被问题牵着鼻子走的困局,背离敏捷和韧性的初衷。

怎么才能以全局思维推进银行核心系统的转型呢?

有着丰富金融行业实战经验的华为,在白皮书2.0中给出了答案:银行核心系统的改造是一项系统工程,首先要解决的就是“顶层设计”,对准业务战略描绘出现代化金融核心系统转型的目标和蓝图,在银行内部形成共识;然后剖析核心系统转型存在的挑战,给出具体的举措、路标、项目和实施方案。

打一个比方的话:白皮书2.0就像是一份全局地图,打开了现代化金融核心系统改造的“上帝视角”,哪里是需要重点改造的核心痛点,哪里是转型中的常见误区,哪些环节需要满足监管合规要求……有了系统性的转型和实践经验,根据业务需求进行体系化推进部署,最终找到解决问题的最佳方案。

02 “作战方案”再进化,韧性和敏捷被重塑
与白皮书2.0同时发布的,还有针对现代化金融核心系统的“作战方案”。

2023年的华为全联接大会上,华为在金融分布式新核心解决方案3.0中提出了1+3+N的架构,即1个全栈自主创新、敏捷韧性的云原生金融级底座;高性能GaussDB数据库、分布式技术平台和应用开发平台组成的3大平台;以及联合广大伙伴共同构建的N维能力,包括核心咨询规划、数据迁移工具、应用改造规范、性能调优服务等等。

刚刚发布的金融分布式新核心解决方案5.0,延续了“1+3+N”的架构,并且带来了5大关键能力的升级。

1、工程工艺升级。

2022年发布的《现代化金融核心系统白皮书》中提出了“4阶22步”的方法论,被再次提炼总结成“4阶10步”的工程实施路径,明确了规划设计、平台搭建、应用上云、运行维护四个阶段的十步关键动作,进一步缩短转型周期。

2、多活架构升级。

通过软硬协同、存算协同、云网协同、存光协同等产品组合,基于MAS打造了高可用、高性能、高弹性的系统架构,能够在多个地理位置分散的数据中心站点同时并行处理,实现99.999%的可靠性、毫秒级ART、万级TPS等指标。

3、数据库架构升级。

GaussDB数据库采用存算分离模式,打造了高可用、大容量的数据存管架构,带来了硬件高可用(年均停机时长31秒)、架构高可靠(同城RPO=0)、按需扩容(单库容量64TB+)、极速备份(10T全库备份小于2小时)等能力。

4、智能研发升级。

引入了基于盘古大模型的智能开发助手,拥有代码生成、研发知识问答、单元测试、代码解释、代码注释、代码调试、代码翻译和代码检查等能力,端到端研发效率提升了30%以上,将开发人员从传统的繁重的工作中解放了出来。

5、一体化运维升级。

从应用、中间件、数据库、容器、云资源到物理设备,实现了自上而下穿透式的可观测、根因定位和快速恢复能力,通过对数据链、交易链、部署链实现实时监控与链路追踪,实现对故障的1分钟发现,5分钟定界,10分钟业务恢复。

可以看到,有别于扩充资源为主要手段的粗放模式,华为提出的“作战方案”采用了平稳改造的路线:先通过“1+3+N”的架构,帮助银行从集中式核心系统向分布式转变;接下来围绕工程实施、开发效率、容灾、运维等进行能力升级,既满足了银行核心系统的架构韧性,又实现了业务开发的敏捷,持续为银行核心系统的现代化改造保驾护航。

03 和伙伴联合创新,协力构筑“新质体系”
“全局地图”回答了“改什么”,“作战方案”指明了“怎么改”,另一个必须要回答的问题是:谁来改?

金融是离数智化最近的行业,而银行又是体量最大、系统最为复杂的金融场景。也就意味着,在千行万业的数智化转型中,金融行业势必要担纲探路者的角色,没有现成的作业可以抄,必须要去啃最难啃的骨头。同时每家银行的禀赋不同,需求各异,不可能用一套方案解决所有问题。

正如前面所提到的,“1+3+N”架构中的N来自联合广大伙伴共同构建的能力,相关联的还有面向5类业务场景的联合创新集成机制:华为Openlab金融实验室面向伙伴和客户提供解决方案联合创新与集成验证平台,提供集成设计、一体化集成平台等两大关键能力。

目前已经完成10+伙伴方案的创新与集成。

譬如长亮科技基于华为云stack、容器引擎、分布式数据库、PaaS服务等研发的APStack平台,目前已经完成存款、贷款、账户和公共管理等核心业务的实验室预集成和深度优化,涉及1000+业务用例。

同样的还有神州信息的SmartGalaxy平台,基于云原生金融级底座和3大平台,完成了银行核心业务的实验室预集成和深度优化,包括联机交易、批量、会计核算、总账系统等,全面支撑亿级账户十亿流水、万级TPS交易。

一个个被行业认可的荣誉,为联合创新的正确性画上了注脚。

2024年中国国际金融展上,光大银行的“重要业务系统云化建设”项目荣获金融展“金鼎奖”——优秀金融科技赋能业务创新案例奖。

因为在华为和伙伴的助力下,光大银行在两年间陆续实现了180余套业务系统的上云改造,实现了集中式架构到全栈云平台的平滑迁移,让系统稳定性、资源利用率、运维效率大幅提升。

江苏银行在2023年与华为合作启动了关键业务系统的分布式改造,改造后的会计核算平台显著提升了数据处理能力,增强了系统的安全性和稳定性,为全国城商行交易类系统的自主创新改造提供了借鉴价值,并因此荣获了《亚洲银行家》颁发的“中国区域最佳数据整合与数据架构实施奖”。

可以找到的联合创新案例还有很多。

这些案例的价值,绝不仅仅是一个个奖项那么简单,还是现代化金融核心系统的创新“风向标”。

直接的例子就是白皮书2.0中重点提到的现代化核心6大新质体系,即敏捷智能体系、全栈韧性体系、持续可信体系、开放集成体系、工程工艺体系和稳健迁移体系,结合新质生产力要求和现代化金融核心系统改造升级的实践经验,归纳总结出了一套现代化金融核心新质体系,驱动金融行业不断向上生长。

04 写在最后
银行核心系统作为“最后一道堡垒”,向分布式架构转型、走向云原生已经是毋庸置疑的行业趋势。

至少华为和伙伴们的一次次“翻山越岭”,正不断塑造着现代化金融核心系统升级改造的信心:只要找到了合适的“全局地图”、拟定了正确的“作战方案”、找到了有能力的合作伙伴,高可靠、高性能、高可用的现代化金融核心系统,将是一件水到渠成的事。

把眼光再放长远一些,全球范围内的现代化金融核心系统演进方兴未艾,华为和伙伴们接下来还将“把中国速度带往全球”。

相关文章
|
运维 监控
浅析SPI与CAN通信
SPI是一种常用的MCU与外设的通信方式,英文全称Serial Peripheral Interface。与之前介绍过的UART不同,SPI是串行,全双工,同步通信方式。SPI通常有4根物理连接线,分别是CS片选,SCK时钟,MOSI主机输出从机输入和MISO主机输入从机输出。CS片选是从机选择信号线,低电平有效。当CS为低电平时认为主机目前选中的本从机。SCK是串行时钟线,同步通信需要主从机时钟同步,主机利用SCK线与从机实现时钟同步。时钟由主机产生,决定了通讯的速率。
595 0
|
设计模式 缓存 Kubernetes
分布式系统架构与云原生—阿里云《云原生架构白皮书》导读
有幸作为阿里云MVP提前获得了阿里云云原生团队编写的《云原生架构白皮书》,希望通过自己对于云原生的理解为开发者提供一篇观后感或者是能够参考的博文
13191 0
分布式系统架构与云原生—阿里云《云原生架构白皮书》导读
|
Prometheus 监控 API
深入理解微服务架构:设计与实施
【10月更文挑战第7天】深入理解微服务架构:设计与实施
180 0
|
机器学习/深度学习 人工智能 自然语言处理
企业内训|LLM大模型技术在金融领域的应用及实践-某商业银行分行IT团队
本企业培训是TsingtaoAI技术团队专们为某商业银行分行IT团队开发的LLM大模型技术课程。课程深入分析大模型在金融行业中的发展趋势、底层技术及应用场景,重点提升学员在大模型应用中的实际操作能力与业务场景适应力。通过对全球商用 LLM 产品及国内外技术生态的深度对比,学员将了解大模型在不同企业中的发展路径,掌握如 GPT 系列、Claude 系列、文心一言等大模型的前沿技术。针对金融行业的业务需求,学员将学会如何结合多模态技术改进用户体验、数据分析等服务流程,并掌握大模型训练与工具链的实操技术,尤其是模型的微调、迁移学习与压缩技术。
423 2
|
11月前
|
机器学习/深度学习 搜索推荐 人机交互
智能语音识别技术的现状与未来发展趋势####
【10月更文挑战第29天】 本文深入探讨了智能语音识别技术的发展历程、当前主要技术特点、面临的挑战及未来发展趋势。通过综述国内外最新研究成果,分析了深度学习在语音识别领域的应用现状,并展望了多模态融合、端到端建模等前沿技术的潜在影响。文章还讨论了隐私保护、数据安全等问题对技术发展的影响,以及跨语言、跨文化适应性的研究方向。 ####
|
关系型数据库 MySQL Java
DDD面试题:DDD聚合和表的对应关系是什么 ?(来自蚂蚁面试)
尼恩,一位40岁的资深架构师,分享了其读者群中关于DDD(领域驱动设计)的面试题及解答,涵盖DDD架构落地、微服务拆分、聚合与MySQL表的对应关系等内容。尼恩通过系统化的梳理,帮助读者在面试中展现强大的技术实力,让面试官印象深刻。此外,他还提供了《尼恩Java面试宝典》等多本技术圣经PDF,助力读者提升架构、设计和开发水平。关注【技术自由圈】公众号,获取更多资源。
DDD面试题:DDD聚合和表的对应关系是什么 ?(来自蚂蚁面试)
|
存储 数据可视化 大数据
从零到一建设数据中台 - 应用场景及实施路径
从零到一建设数据中台 - 应用场景及实施路径
565 0
|
Kubernetes API 微服务
「架构风格」SOA(面向服务)和微服务
**SOA与微服务对比摘要**: - **SOA**:企业级,服务粒度大,重用性强,常通过ESB通信,服务部署集中,技术栈统一。 - **微服务**:服务粒度小,单一职责,轻量级协议如REST,独立部署,技术多样性,去中心化治理。 - **区别**:服务大小、独立性、通信协议、部署方式和技术栈不同,微服务更强调敏捷和独立性。 - **示例**:Python Flask简单示例展示了服务创建,SOA服务间通过HTTP请求通信,微服务每个服务独立运行。 - **权衡**:涉及服务发现、负载均衡、容错和安全,常用技术如Docker、Kubernetes和API网关。
1062 0
|
运维 监控 安全
云时代下的运维转型之路:从反应式到主动智能
【8月更文挑战第23天】在数字化转型的浪潮中,传统的运维模式正面临前所未有的挑战。本文将探讨如何从被动应对故障的反应式运维,转变为通过数据驱动和智能化工具实现的主动智能运维。我们将深入分析现代运维的核心要素,包括自动化、监控、数据分析和团队文化的转变,以及这些变化如何帮助企业提升运维效率,降低风险,并最终实现业务价值的最大化。文章旨在为运维专业人士提供一条清晰的转型路径,帮助他们在云时代保持竞争力。
|
移动开发 前端开发
基于若依的ruoyi-nbcio流程管理系统一种简单的动态表单模拟测试实现(五)
基于若依的ruoyi-nbcio流程管理系统一种简单的动态表单模拟测试实现(五)
272 0