阿里云陈威:如何让银行的核心系统「拎包上云」?

2022-05-29

很多金融机构在考虑「上云」与否的时候,并不清楚自己能得到什么。

其实他们最在意的,是希望技术保证核心稳定运行,是整体完全自主掌控,是最后达到每单笔交易/每个账户成本下降的目标,是在业务稳定性、连续性不降低的前提下,支撑业务敏捷。

抽丝剥茧数个实践合作案例后,我们可以看到,金融机构的诉求,或许可以分为三环:

  • 最难解决的是“1环”问题,分布式事务怎么实现?各种模式应用在哪些场景?有何利弊?异地多活情况下,数据库怎么保证良好的支撑?

  • 到了“2环”,重点落在领域化建模,机构们要参考最佳实践,思考底层模型框架如何处理,他们也在关心集中化架构——分布式架构——云化架构,有没有一些特殊的差异?

  • 上升到“3环”,诉求就会涵盖整个云化环境下的运维保障体系、devOps体系、整体的部署架构体系……

2020年被认为是云原生核心的元年,更多金融机构逐渐从混沌中醒来,与科技公司联手摸索出核心系统的“病灶”所在,对症下药。

陈威是阿里云新金融事业部金融核心部负责人,曾从事企业级信息技术产业十余年,具备丰富的应用架构与设计,数据智能,云平台,互联网等领域的理论与大型复杂项目实践,尤其在金融行业具有多年的交叉实践经验,服务于近百家大型机构与客户。

在雷锋网《AI金融评论》与阿里云联合主办“银行系统云化升级”实战体验营中,陈威就从阿里云服务金融机构的过往经验中提取精华,详尽深入地讨论了他们在金融核心系统转型方面的探索和实践。

欲获得所有讲者视频,可关注公众号“AI金融评论”(ID: aijinrongpinglun),进群获取回放链接。

以下为陈威演讲内容,雷锋网做了不改变原意的编辑和整理:

今天的主题是《金融核心云原生转型的探索与实践》。

在整个金融业,尤其在银行领域,核心系统是IT整体支出占比最大,最为复杂,对于技术要求最高的一块。这也是我们认为,整个金融行业包括银行,在朝着云化转型的理念里,最后最难的一部分。

今天的内容首先会讲到银行核心系统云化转型的诉求,简单来讲就是客户和我们为什么要做这件事?其次是核心云原生转型的挑战与应对。

银行核心系统云化转型的诉求

可能在座的听众有所了解,金融核心实际上经过了好几代,存在代际的差异。

最早是传统综合业务系统这部分,然后到第一代基于主机的单体式核心系统。比如钱存在国有大行那里,都是在主机系统Mainframe(大型机)上。

大量的农商农信体系是在AS400上;还有一部分在Power小型机系列。

第二代就是我们通常看到银行会走到瘦核心的阶段,从原来的核心系统进行拆分,尤其是面向敏态的部分,通常会建设一个叫互联网核心的系统。

第一代的技术架构的改造或者升级,通常的做法,基于从单体下移到基于ESB的SOA架构。近几年有些开发商会基于开源Spring Cloud把这部分SOA架构升级到微服务的架构。

从技术架构路线来讲,这是从ESB向微服务框架的体系改进,这就是我们经常听到的分布式核心的实际的现状。

从应用架构路线来看,技术层面虽然有一些升级,但是它底层模型和应用架构,其实没有太大变化。

第二代核心的典型特征就是以ESB为核心和微服务架构,但有个问题没有解决:底层对业务敏捷的支撑是心有余而力不足。支撑一些新的产品,服务或者功能上线需要大量的人力定制化开发,业务并不够敏捷。

随着云计算技术的不断发展和成熟,云化的潮流势不可挡,不论是传统企业还是金融系统,有意愿和动力升级到云上核心,这就是所谓的第三代,也叫云原生核心,基于容器云原生或者基于PaaS等技术

它跟我们通常理解的分布式核心,实际上有较大差异。第三代是完全走向IaaS/PaaS化,但在底层应用架构方面,其实也有相应的变更,类似于大家听到的中台化、领域设计,这些关键字都会在第三代核心中有所体现。

  • 第三代金融核心关键性标准

我们试图总结一下第三代核心的一些关键词,经过长时间的调研与归纳,形成了这么一些标签,云原生,异地多活,中台化,数字化。

云原生和异地多活,偏向技术架构和基础设施;中台化和数字化,偏向于业务和应用。

云原生:金融核心实际上也是应用系统,本质上和其他业务系统没有特别大的差异,但是它比较复杂,对业务连续性和一致性的保障会比较高。

同时,它本质上是一个应用,所以云原生应用该具备的特征,它实际上也具备。比如容器化部署模式,PaaS的资源供给应用需要的能力,这都属于云原生范畴。

异地多活:大部分新建的银行要做的核心,基本上会有异地多活。它不光是同城容灾或者异地容灾,是能够做到多地多活的模式,可以做到城市级的容灾。对于传统金融机构而言,异地多活也是比较大的挑战。

中台化:原来的集中式架构,就是传统一个大的单体化应用,牵一发而动全身。

当需要定制化或创新金融产品服务,尤其是疫情常态化之后,未来有很多不见面的流程服务,包括基于互联网或者视频的新渠道形态,原来的架构不能复用。

这时希望打造一个坚实的业务中台能力,能够支撑未来多变的挑战。中台化最终是为了提高面向创新的效率,这也是建中台的初心,这是支撑业务敏捷非常重要的手段。

数字化:能够以数字化模式,展现里面所有运营相关内容,有了数字化运营的基础和能力,智能自动化运维才有空间,这是核心未来发展的重要方向。

其次,因为核心系统的生命周期非常长,可能会要支撑全行的业务支撑十年八年的的时间。如果遇上比如数字货币这种国家大力推行的方向,它对于核心有怎样的挑战?所以架构上的设计,一定要把这个(时间跨度)也考量进去,具备很强的扩展能力。

  • 第三代金融核心的重要意义

自主创新:首先它是自主创新的一个标杆。但从我们的观察来看,2020年是云原生核心的元年,诸多传统金融机构在逐步的进行尝试。

行业标准:在第三代核心,或者全分布式、云原生、多活核心架构领域,还没有公认的标准。金融机构非常想去打造行业的先锋标杆,沉淀的卓越实践参考。

实施工艺:核心是一个庞大的项目群,周期很长,可能有不同的开发商,涉及的人员非常多,不可能按照原来的小应用开发模式,必须要有一套统一规范的框架和实施工艺,支撑长生命周期的大型系统开发,能够在上面开发整个核心系统上百个应用。

能把这三点做好,是我们认为第三代核心在金融机构落地的标志。

  • 第三代金融核心的业务价值

首先是全栈式的自主可控,满足相关的要求。

多活架构,可以做到RPO=0,甚至是城市级的容灾,RPO=0,有问题的话恢复时间<1分钟。如果大家对于基础设施比较了解,就会了解要达到这样一个指标会有多么巨大的挑战,只有达到城市级别的RPO=0,RTO分钟级,才能够真正的保证业务的连续性。

弹性扩展,基于分布式架构的扩展性,一定比集中式架构要好,所以它完全能够满足业务的特殊要求或者线性增长,支撑传统金融机构做类似于双十一这样的大促销,金融爆款产品的秒杀,或者是一些高并发的场景金融。

业务敏捷,产品团队能很快在该框架的核心上,实现新的金融产品和服务。在传统的集中式架构下,上线新的大一些的功能就可能需要大量改动核心内部、关联系统,造成业务上架用时较长。基于微服务或分布式架构的,可以通过devops模式缩短业务交付时间。

运维成本,云原生架构基于相对低廉的x86服务器构建,同等处理能力下,分布式架构的单位运行成本大幅降低,分布式架构的年均运行维护成本是大型机的17%。

  • 金融机构们的诉求是什么?

在一个分布式的云化环境中,要保证核心稳定运行,其实有三个非常关键的标志。

  1. 整体完全自主掌控。

  2. 从财务的角度看,最后达到每单笔交易/每个账户成本的下降。

  3. 业务稳定性、连续性不降低的前提下,支撑业务敏捷。

这三点衍生出金融机构对供应商/合作伙伴的诉求,大体分为4个方向。

咨询与设计:架构咨询指导,技术,开发规范等,配套的组织体系架构等。

服务交付:服务的长期交付过程,一般来讲建设周期在2~3年,所以整体的人员投入,开发实施交付规范等。

运维保障:后续的长期运维保障,出问题怎么监控、解决,怎么更自动化;

产品与方案:最底层的是产品方案的支撑,包括整体规划路线图,产品的延续性、一致性、无缝升级维护,还有产品计划的发布策略、相应的生态丰富度。

客户的诉求可以分为三环,最难解决的是“1环”问题

业务一致性,怎么实现分布式事务?各种各样的模式,到底用在哪些场景?各种模式的利弊是什么?

数据一致性,尤其是异地多活这种情况下,数据库怎么保证良好的支撑,尤其在异地之后的数据容灾等问题,都是基础架构部门非常关心的“1环”内容,通常很难靠金融机构自己解决,一般需要外部供应商来做。

“2环”重点是怎么领域化建模,有没有一些最佳实践?底层模型框架怎么处理?集中化架构到分布式架构,再到云化架构,有没有一些特殊的差异?

“3环”涵盖整个云化环境下的运维保障体系,devOps体系,整体的部署架构体系,比如怎么做单元化架构等。

云原生转型的挑战和应对

从哪些框架/思路,去解决转型诉求带来的挑战?

可能原来大家理解的,主要是在业务和数据建模,以及底层的技术软件支撑。但在大量调研之后,发现其实中间还缺两层,就是架构集成、开发运维部分,这也是要攻克的难点。

之前讲到,第一代、第二代(金融核心)里这块业务流程不会有太大调整,但在第三代,一定要真正让它敏捷,对业务流程清晰梳理,同时要能转化为类似中台的模式。

上半部分属于企业级架构建模的范畴,下半部分是建模之后怎样在云上落地。

  • 我们怎么做敏捷的架构设计?

做敏捷的架构设计,首先要考虑中台化领域设计。

相对传统的服务集成架构是渠道层+整合层+核心系统,但中台化分层就会拆成渠道层、开放层、产品服务层、中台能力层、基础服务层等。

其中,渠道层,包括各个电子化渠道,开放互联网渠道,线下的渠道等。

像产品服务层,其实不是产品真正执行代码的地方,实际是业务能力编排的领域。例如存贷款这些业务,也是经过一个流程编码,调用不同的引擎账户和中台能力,去支撑完成业务链。

其次是思考云原生应用框架的搭建

为什么要考虑框架?我们在客户项目中经常遇到一个客户的问题,感叹懂业务的不懂云原生分布式;懂云原生分布式的,对业务理解可能也没有那么深。

现在更先进的底层技术,比如云原生分布式数据库,学习使用和运维的难度可能比原来要高,这样会极大影响技术的可获得性,就是好不好用的问题。

这需要一套框架整合起来,在业务组件技术层面封装,降低开发难度,最后让普通的应用开发人员,能够像普通单体架构一样开发业务应用,而不用关心这后面到底是在什么样的环境里部署的。

再就是底层基础设施部分。

因为开发周期非常长,难免中间有老的核心系统,怎么统一完成服务调度治理,怎么在尽量不改代码的情况下,更平滑地接入和交互?

其实我们讲的mesh技术,就比较好解决这个问题。我们也发现很多客户不由自主地运用mesh来支撑集成的架构核心。

使用mesh,下一代的微服务技术,结合分布式网关,能够跟ESB对接,支撑传统业务调用——这也是服务网格目标。这部分与现在经常讲到的low code低代码、低侵入,都具备相近似的模式。

如果想用mesh的模式实现异构架构集成等?这就尤为需要关注云化分布式改造方面的新进展。

以往来讲,spring cloud这套体系,如果你要写一个比较健壮的核心应用,一定要在体系里把所有代码和编排都放进去,实际上每个真正的业务代码量占整体比较少,会有大量业务无关的逻辑。

这部分如果通过mesh技术,直接用sidecar处理,对于原来的业务应用不会有大量的侵入。因为走的是网络层所有监控,所以能够把整个架构的链路全部清晰表达出来。这对全方位监控也是很重要的内容。

  • 如何保证质量安全与稳定性?

客户无论是大机下移还是云化转型,都有一个非常重要的前提:保证自身业务连续性;保证整体业务安全情况下,能支撑业务敏捷。

在质量安全与稳定性方面,我们有一整套可回滚可灰度可监控的防控体系,分为三层质量网。

未来一旦微服务化、云化,它会有大量的容器应用,不大可能靠人力定位最终的问题,一定要靠自动化、智能化的方式解决传统的巡检监控问题总的来说,会有配套机制保障终端客户不出问题,设施是不可靠的,要从应用、软件、机制规范、工具体系支撑。

另外就是异地多活架构

这部分实际是支付宝能去支持双十一的底层核心架构,是三地五中心的多活架构。在互联网上,我们一般采用客户ID号尾号分片的方式,最后拆到100个单元,能够在不同机房之间精细调拨流量。

所以任何一个机房或城市出现问题,我们都能把流量瞬间调拨过去,同时业务应用能承担起来,机房级或城市级容灾都能做到RPO=0。这里面非常核心的,就是底层分布数据库,真正能够支持异地容灾的分布式结架构。

比如在异地机房,整个单元从端到端升级到一个新的架构,现在可以做到机房级的逻辑单元架构更新,或者应用版本大规模升级,这些都可以通过单元化方式实现。

无论在哪个级别,RPO都能做到等于0,但由于网络或者物理限制,无法做到RTO=0。

您好!请登录

点击取消回复