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

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

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

• 最难解决的是“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。