资讯 金融科技
此为临时链接,仅用于文章预览,将在时失效

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

作者:木子
2022/01/18 16:36

核心系统转型,相当于给正在跳动的心脏,做一场不停摆的换心手术。

不少核心系统采用的传统集中式架构,已经不止是一种技术架构模式,而成为一种根深蒂固的思维习惯和设计理念。当它成为潜规则而影响了创新时,我们往往身在此山中而不为所知。

在阿里巴巴集团副总裁、阿里云新金融&互联网事业部总经理刘伟光看来,不少机构在做核心系统转型时,极易陷入窘境:

这次,刘伟光将全面探讨金融行业,尤其是银行业,在进行核心系统转型、升级过程中遇到的方方面面的问题与挑战。本文从酝酿到成文历经四年,期间他与团队拜访过近千家金融机构,沉淀出3.5万字长文。

当中包括:目前核心领域分布式架构转型、金融级云原生分布式转型的21个困惑与解答,新业态对旧核心的挑战,双核心并行与在线迁移的大致方案,以及第三代核心的标准与定义等。

此前《AI金融评论》也曾发布《阿里云刘伟光:2万字解剖「保险科技」,管理者怎样做「正确的事」?》,点击链接即可查看全文。


作者 | 刘伟光

阿里巴巴集团副总裁

阿里云新金融&互联网事业部总经理

目 录


“核”聚变 1

序言 4

引言 6

1.金融核心分布式转型的行业变革 7

1.1金融核心从业者的困惑 7

1.2核心转型成功的标志 8

1.3面对误区的破局思维 10

1.4新思路新出路 12

2. 金融业务新方向呼唤技术的“供给侧改革” 14

2.1开放金融体系需要可标准化的构件式核心 14

2.1.1不能变成新“竖井”的场景金融 14

2.1.2必须实现生态化的产业金融 15

2.2普惠金融体系需要可灵活组装的核心系统 16

2.3绿色金融体系需要可泛化设计的核心系统 17

3. 金融核心转型的能力要求与建设体系 17

3.1 何为“金融级云原生” 18

3.2银行核心系统转型能力需求 19

3.3 支撑核心转型的五层十二大能力体系 22

3.3.1业务领域建模 22

3.3.2应用架构集成 24

3.3.3应用系统建设 26

3.3.4基础软件设施 29

3.3.5基础资源设施 36

3.4基于能力体系打造的金融级云原生工场 38

4. 实施路径与建设模式 394.1四阶段五层模式 40

4.2多种实施路径 40

4.2.1重构模式 40

4.2.1.1业务重构 41

4.2.1.2技术重构 43

4.2.2平行迁移模式 45

4.2.3 SaaS化批量模式 46

4.3 在线迁移与双核心并行 46

4.3.1 面临的并行挑战 46

4.3.2 云原生分布式核心推荐迁移策略 47

4.3.3迁移平台能力建设 47

5.核心云原生分布式转型的价值与经验教训总结 48

5.1 第三代云原生分布式核心的价值体现 48

5.2 第三代云原生分布式核心的关键标准 50

5.3 核心相关系统建设的经验教训总结 51

序 言

创作这篇文章的想法已经酝酿了有四年多时间,时光如白驹过隙,我们仍初心不改,在这期间我和我的团队跨越大江南北,拜访了近千家金融机构,见证了数字金融这几年在中国的高速跃迁,在拥抱移动互联网和金融科技新技术的大潮中,中国金融的服务能力有了大幅度提升和客户体验的飞跃,开启了技术驱动数字金融的新时代。

回顾技术在金融行业的发展,金融科技的变革与时代共舞,国外的基础技术平台和最佳实践支撑了过去几十年的金融行业的发展,直到今天我们也必须承认,这些国外的基础技术平台在很多单项技术能力方面仍然是具备非常强的竞争力。但是今天我们面临的时代,是一个高速发展,具备一定的业务发展不确定性和互联网特征,并且需要与移动互联网和音视频能力的高度结合,同时让数据变成以资产方式无处不在的数智时代。不是过去的技术不先进,而是它们限制了我们对未来全面数字化金融的想象力,我们需要的是一套新的技术体系以实现金融机构真正的业务和技术的转型。

以银行为例,核心系统就是IT建设中皇冠上的明珠,是一家银行的心脏,在我们与诸多银行沟通交流的过程中,从那些无数次碰撞的火花中,脑海中关于未来核心系统建设的影子已经从一个模糊的亮光逐渐清晰。它不再是银行科技部门按部就班按照周期建设的系统,它不再是一个固化的标准存贷汇功能堆积的能力集合,它不应该是不断修修补补加外挂的平台,它不再是和数据平台和数据服务能力割裂的系统,它不再是一个牵一发动全身的架构体系。首先它必须是银行数字化转型中最重要的一把手工程,是一个能够让内部员工和外部客户都能感受到数字化能力无处不在的平台;它是一个能够快速生成新流程,快速创建和发布新业务新产品,能力单元高度复用的平台;它是一个能够具备移动化数据化智能化特征的平台;它是一个分布式基础架构技术支撑的平台,能够以弹性能力应对互联网类业务的峰值;它是一个融合云计算中的先进技术能力去应对开放银行和生态银行时代所有业务的一栈式平台,这就是我们脑海中那个未来的样子。今天我们已经看到有些银行已经在这个路上去积极的探索,这些探索的背后我相信就是未来引领行业,全新的最佳实践。

我们在内部和外部不断的探索与实践中,逐渐提炼和总结了一些系统性的思考,也就是如何构造具备核心竞争力的核心系统,打造真正“硬核的内核”,逐渐优化和改变目前建设的工程化体系,同时在基础技术平台和应用系统的耦合度上深入的进行研究探索,对于系统物理和逻辑部署形态上做了创新的实践,同时融合了云计算体系当中最先进的云原生技术理念。

希望此文能够给从业者带来一些新的思考,从更大的视角去构建智能化内核能力无处不在的新平台,重塑数字金融时代的商业价值。

此刻我和团队就在某银行数据中心现场参与主机应用迁移到分布式云原生架构平台的过程,能亲身见证这些推动金融行业发展变革的历程,是我们这一代从业者的荣耀,也是我们的责任!

刘伟光

阿里巴巴集团副总裁

阿里云新金融&互联网事业部总经理

中国金融四十人论坛(CF40)理事

2022.01.08 上海

引 言

本书分为五个章节,比较完整的涵盖了金融行业,尤其是银行行业的核心领域在进行转型、升级过程中遇到的方方面面的问题与挑战。可以说,在数字化成为现代企业转型发展的标配下,金融行业、尤其是银行行业,其问题、思考与实践具有相当的代表意义。作为这个过程的亲身观察者,参与者,直到推动者的过程当中,我们如实的记录下来了从业者的艰难实践,以及结合我们内部的和外部的实践总结,希望能够为这一伟大的历程做出自己的一些贡献,为从业者提供一些中肯的建议,少走一些弯路,多一些从容与信心。

第一章综合的介绍了目前核心领域分布式架构转型,云原生分布式转型的21个问题与困惑,这是历经两年多的实地走访与调研的100%真实的问题。同时不光有问题,也有我们总结归纳并交叉验证过的核心转型成功的三大标志,这是本文一切努力服务的三大目标。同时根据一些有代表性的实践,我们列举了核心从业者的实际的窘境,并引出了六大断言。综合这些问题,窘境与断言,我们总结归纳出六个新的思路方向来解决这个世纪的难题。

第二章从不确定性时代的金融业务挑战出发,主要从业务方向的角度分析了当下相对较新的金融业务形态对于传统金融核心的挑战与要求,主要是开放金融体系对于标准构件的要求,普惠金融体系对于灵活组装核心的需求,绿色金融体系对于核心可泛化性的要求。当下的核心阻碍业务敏捷的障碍,这些新业务对于敏捷的要求,一一为您呈现

第三章从银行核心系统的转型能力需求的方面,主要从技术方向的角度分析了转型的能力要求,回答了不少第一章行业和核心从业者的困惑。提炼了五层十二大能力体系,这些是新一代云原生分布式核心建设的最佳参考模型。涵盖业务建模领域,应用架构集成领域,应用系统开发建设领域,基础软件设施领域,以及基础资源设施领域。

第四章在第二章业务角度和第三章技术角度的基础之上,分析了不同细分银行行业的大致模式,经过提炼总结成为实施与建设的四阶段五层的实施路径。同时介绍了三种不同的建设模式,重构模式,平行迁移模式以及SaaS化批量模式。供不同规模的银行机构参考。并且按照相关的国家指引,给银行提供了双核心并行与在线迁移的大致方案。

第五章最后进行了全篇的总结,从实际的数据出发,给出了核心云原生分布式转型的价值,给出了第三代核心,也就是云原生分布式核心的一些建议标准与定义,同时再次总结了一些建设过程中的经验教训,帮助金融企业,银行机构早日实现核心转型的重要价值。

1

金融核心分布式转型的行业变革

曾几何时,银行业务系统、特别是银行核心系统都与“云技术”没有任何联系,云原生的种种技术和架构优势(微服务解耦、敏捷开发、自动化测试与发布、不可变基础设施、去中心化的服务治理、声明式API、Serverless无服务器化等)对银行核心而言都是“别人家的孩子”。

但随着银行以消费互联网、产业互联网、开放银行生态为核心的数字化业务快速增长,银行核心对敏捷交付、高并发、弹性伸缩等不确定性问题的应对,成为新一代银行核心建设必须面对的“底线要求”。从云计算技术发展中铸就的云原生和分布式技术在这样的“时代要求”下必然成为银行的主流技术,银行核心也成为“云原生分布式架构”攻克的“最后的堡垒”。

在银行信息系统中,核心系统承载了银行存款、贷款、银行卡、清算核算等核心业务,被称为“银行业跳动的心脏”、“银行IT皇冠上的明珠”,其重要性不言而喻。回顾银行信息化30多年历程,核心系统经历了从“胖核心”到“瘦核心”的演变过程。“胖核心”以IBM大型机为代表,而“瘦核心”则以典型的IOE技术架构为代表。然而,全方位数字化金融时代的到来使得集中式架构的问题日益凸显,比如:系统部署无法及时响应业务需求;系统弹性能力差,导致资源过度规划和冗余浪费;使用成本高等。虽然集中式架构仍然具备很强的竞争力和高度的稳定性,但是在拥抱中国数字金融高速迭代的浪潮中,业务驱动架构变革已成为今天的主题。

随着集中式架构的六边形能力(高并发、线性扩展、敏捷开发、按需弹性、精细化治理、多活可靠)已经达到极限,我们认为银行核心系统的云原生重塑也来到了“时代拐点”。

1.1金融核心从业者的困惑

旧的答案分崩离析,新的答案还没有着落。

当金融服务进入到“连接一切”、“微粒式服务”、“永远在线”、“毛细血管”的数字金融时代,业务对金融核心提出了全新的挑战。虽然我们都知道,延续了几十年的集中式架构已经越来越难以满足现在和未来的业务要求。但是,支撑我们的不只是诗和远方,更有身边的日常。我们仍然需要面对当下具体的挑战和问题。

金融核心到底该如何转型?云原生分布式是否是金融核心的未来?金融核心云原生分布式转型究竟带来哪些价值?云原生在解决原有问题的同时带来了什么新问题、如何应对?带着这些灵魂拷问,我们调研了数十家金融机构,收集到了这么一份沉甸甸的问题清单,这充分代表了行业在面临挑战中普遍感到困惑的地方。

问题:价值呈现[为什么要转型]

1.为什么核心要转型、要下移,云原生分布式架构转型带来哪些价值?

2.核心云原生分布式转型与银行数字化转型的关系?

3.核心分布式转型,与云及中台有什么关系?

4.不同类型/规模的银行核心云原生分布式转型的价值差异在什么地方?

5.现在懂C,RPG这些的人越来越少,开发生态已经没了,领导让我招会骑马的骑士,现在都是驾校学车的人了,我招不到人怎么办?

问题:价值落地[如何转型]

1.核心下移云原生分布式转型工程庞大环节众多,没有一家公司能够全方位覆盖,如果还采取传统项目的多家供应商集成工作模式,如何保证真正实现云原生分布式核心而不是新瓶装旧酒?

2.传统厂商懂业务应用但是不懂云原生和分布式,懂云原生分布式的不懂银行业务,如何推进?

3.核心云原生分布式转型需要管理上组织上如何配套?

4.要启动核心云原生分布式转型的工作该如何准备,如何着手,需要考虑哪些方面的内容?

5.不同类型/规模银行在核心云原生分布式转型的策略上存在什么差异?

6.目前同业在核心云原生分布式转型实践上有那些成功经验可借鉴?

7.核心云原生分布式转型的实施路径有那些, 采用什么样的步骤会比较好?

8.我现在已经有云,分布式数据库等基础设施了,我该怎么开展核心云原生分布式转型?

问题:关键挑战[用什么来转型]

1.核心云原生分布式转型的技术难点或者挑战主要有哪些?

2.如何确保核心安全可靠的下移及云原生分布式转型?

3.核心下移及云原生分布式转型目前的生态是什么样子,有足够的服务和支持能力吗?

4.核心云原生分布式转型对于分布式数据库的考虑有哪些,尤其是对分布式事务处理?

5.核心云原生分布式转型,传统主机或虚机与云之间的关系,二种模式的混合运维给生产中心带来哪些挑战?

6.核心云原生分布式转型一定是一个过程,在这个过程中如何快速集成由不同技术体系构建的应用系统?

7.金融级云原生分布式核心系统是什么?包含哪些内容?有哪些特点?

8.分布式架构框架,微服务框架,应用开发框架这些我都有,别的厂商也都说能做,你们有什么独特的价值?

9.从上面代表性问题反映出核心系统的重塑是一场浩大且复杂的工程,这些问题涉及范围非常广,目前也没有统一的标准答案。

初心之外,还要用心。我们经过上百次的面对面交流和讨论后,决定用心地完成这篇万字文章,目的是一起来探索,希望各位读者能够或多或少地找到部分答案。

1.2核心转型成功的标志

桥梁越大,内部结构就越重要。

在实践和探索的过程中,我们通过不断分析归纳总结,得到了下列这张大图,这是志同道合的客户和我们共同的认知与成果,在这个领域,我们必须要心怀敬畏。因为在传统银行核心下移分布式云原生改造的领域,这是一条无人之路,大家都在不断探索和学习。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

这张图展现的就是核心转型的初心,以及金融机构对合作伙伴的要求。也是考虑迎接核心转型这个挑战“以终为始”的出发点。整体而言,分为两个部分。

1.成功的标志

核心转型最后必须是金融客户要能够成功,并且要能够实在的给客户带来巨大的价值,而不仅仅是买来一堆高科技产品堆在开发和数据中心。从这一点出发,行业认为核心转型的成功标志是

1)安全自研可控

自研可控有多重维度,第一种维度是技术架构的安全可控,可以对系统架构和关键技术进行整体把握。主要涉及自产自研、关键技术产品代码的拥有、知识产权的可控性等。

第二种维度是业务层的解耦,对于核心系统的功能能够自主的按照业务发展进行研发迭代,而不是高度耦合、牵一发动全身。

2)财务成本,单交易/账户成本下降

上一代集中式架构,尤其是主机体系,综合的TCO成本相对较高,不仅仅是购置成本,包括长达10多年的运营维护成本,扩容成本,这些都还只是显性成本,反而更容易忽略的是人员成本,拥有相关主机技能的人才越来越少,越来越难培养相关技术人才。

3)业务稳定性连续性不降低前提下支撑业务敏捷

天下武功,唯快不破,业务敏捷是面对不确定性的制胜法宝。这也是核心转型的最大动因之一。例如对于新业务的快速功能性支撑,对于老业务的快速升级迭代等等。但是核心光敏捷是不行的,前提是保证可靠性和稳定性,没有稳定,就没有金融安全,没有金融安全一切都是空中楼阁。

2.对于合作伙伴的诉求

金融机构和行业认识到,要完成这个壮举,必须是整个产业链条和整个生态的大协作才有可能,这不是一两家技术公司的事情。从这个角度出发,我们识别出来以下4个大的方向,是保证客户,整个行业成功的要素。它们环环相扣,缺一不可。

1.咨询与设计中关于云原生分布式的架构设计,迁移方案,并行方案,实施路径等

2. 项目实施和组织阵型的提前规划设计,基础平台和应用开发的组织阵型规划

3. 运维保障中快速解决核心故障问题和机制保障;白盒化,更自动的监控和运维工具的支撑

4. 产品与方案层面,产品与方案是整个核心迁移和云原生分布式转型的基础支撑,因此产品的长期规划和产品的延续性,基础产品的发布更新和生命周期这些都是尤为重要。

但无论怎样艰难,业界已经形成一种共识,新的时代已经到来,从集中式到分布式,从分布式到云原生分布式架构的转型,是一条必经之路。

1.3面对误区的破局思维

核心转型需要“站在整体看局部、站在结果来看过程”。

2021年诺贝尔物理学奖颁给了“复杂性系统”的研究,金融核心转型就是金融业的“复杂性系统”,其中涉及了业务、技术、产品、组织、人员能力、流程、生态、协同和管理等诸多方面的问题和挑战。如何解决这些问题本身是个开放命题。

同时我们也看到很多机构在核心转型实践中存在的一些误区。面对这些误区,需要具有破局思维、打破“简单型系统”的思维禁锢,同时需要“站在整体看局部、站在结果来看过程”,这样才能明确地站在“终局”来看,什么肯定是不对、不合适的,才能一步步逼近成功。

下面我们从核心转型成功的3个角度出发分析一些核心转型领域的常见误区和我们思考断言,希望能够给大家带来一些启发和帮助。

误区1:先从简单系统着手进行架构转型,再推导到核心转型。

某银行由于自研可控要求,只考虑了OA相关系统,核心系统不考虑。但是核心领域被卡脖子的问题依然存在,并且OA系统的自研可控成果对于核心领域而言,是无法借鉴的,这是完全两个不同领域的应用,架构完全不一样。导致未来核心应用转型仍然需要大量的探索和工作要做,总体支出会更大。

断言1:“从俭入奢易、从奢入俭难”。非核心领域的转型实践对于核心领域参考和借鉴意义有限,需要在核心领域架构体系上及早纳入自研可控等架构级别考量,避免2次迁移成本和时间成本。

误区2:追求技术架构完成解耦,碎片化供应商,不被绑定。某银行B在核心云原生分布式转型的过程中,对于核心技术平台要求能够完全的分层分模块解耦,例如在IaaS/PaaS/SaaS/核心数据库这些关键领域,在任何一层出现问题的时候都能够随时的切换到可替代的平台,不绑定任何一家技术平台供应商。但是实际上项目实施过程中IaaS/PaaS层适配虽然功能大体能够适配,但是在不同厂家的磨合方面,稳定性和性能等非功能性领域出现莫名其妙的问题,并且协调两家厂商的产品研发对接需要大量的沟通与适配成本。

断言2:“基础不牢、地动山摇”,底层架构的高效稳定是第一目标。底层架构在起步阶段从“统一架构”更加容易走稳,再逐步进行局部优化和解耦。

误区3:核心系统按照功能模块切分,再众包给不同的开发商来完成,避免被一家绑定。某银行C整个核心进行分布式改造的项目群极其庞大,平台技术部与各家核心应用开发商进行了充分的交流,然后选定各家较为擅长的领域来实施建设。这种众包方式的确没有绑定任何一家供应商,但带来的问题在日后实际核心下移开发中日渐突出。众包给众多核心应用开发商之后,由于开发商都只熟悉自己那一部分业务和技术框架,无法做到全局的架构管控和统一技术标准打通。例如:全链路跟踪与压测、业务染色、单元化、异地多活等。

断言3:核心架构中“非功能性需求”考虑要大于“功能性需求”。非功功能性需求”应由技术架构来承载。业务模块可以解耦设计和分包,技术架构要统一规划和统一标准,实现核心领域的“统、分结合”。

误区4:业务应用是业务应用开发商的事情,技术平台是技术平台供应商的事情,两者没有关系。传统集中式环境下技术平台经过了经年累月的标准化以及适配,对于应用的普适性相对更强,所以应用开发不需要太多考虑底层架构的差异性,只需要当黑盒子来使用即可。但是在云原生架构时代,需要考虑分布式CAP原则的调整,适配与折中的设计。考虑分布式事务,分布式数据一致性,异地多活等难题对于业务模式,业务流程,业务底层数据模型的特殊影响与特殊设计,如热点账户,业务服务跟踪治理,全局业务序列号等专题。而这部分的专题设计,是传统上层应用与传统底层技术平台之间的灰色地带与结合带,它往往决定了整体系统的整体表现,尤其在极端情况下的非功能性表现。

断言4:传统集中式架构下的核心建设模式在云原生架构下大多数情况下并不适用,需要引入额外的框架、机制与设计来保障核心系统的整体表现。

误区5:选择应用平迁、不做架构大变化,更最简单和快捷。某银行D由于核心相关系统规模太大,应用数量众多,原来大量应用是在集中架构的封闭系统中,采用rpg,cobol等语言编写,行方为了想尽快将系统从封闭系统下移至开放平台,为了快速和简单起见,使用了一种并不成熟的代码翻译工具,将整个rpg语言翻译至java语言并部署在开放平台,底层使用分布式数据库承载数据。整体应用架构没有做太多的调整,基本上还是属于集中式架构的范畴。在后期的运行过程中发现较多的性能问题与可用性问题,以及集中式应用与分布式数据库的配合适配问题,只能让庞大的开发团队进行每个程序的代码的手工性能优化,导致开发力量80%以上的时间是在做代码的性能优化,根本无法承接新的功能或者业务的开发,拖累业务应用建设的整体进度。

断言5:核心转型最佳路径是追求“P/PC平衡”-- 产出和产能平衡。不仅仅是完成 “产出”任务(应用迁移),更为重要的是升级“产能”(技术架构能力)。“产能”(技术架构)升级后会推动更大的“产出”(业务价值),成为全行数字化转型的助推引擎。

误区6:选择各个领域的最佳“供应商”,完成各自擅长的工作任务(咨询建模、架构、设计、应用、基础软硬件)。某银行E找了专业咨询团队进行业务梳理与业务建模,然后这些资产大部分停留在纸面,并没有相关后继的指导和形成标准规范。导致核心研发团队依旧不太清楚如何开展后继的大规模开发。后继根据各个业务板块进行应用开发商的招采,选择各个领域最佳供应商。在实际过程中,还是仰赖于应用开发商的经验,没有办法参考前期业务咨询和建模的资产,例如某应用开发商A负责客户模块,某应用开发商B负责产品模块,大家都只熟悉自己这部分“最佳实践”。如何遵照前期的业务建模的成果,如何在整个核心项目群内形成端到端的业务流程落地是没有参考和总控的,导致没有达到最初的规划和设计目标。

断言6:核心转型相比选择“供应商”而言,更为重要的是选择具备“端到端落地实践”的。从理念、方法论、设计规划、平台架构、标准规范都能够战略性长期投入和总体把控的“合作伙伴”才能真正落地实现业务敏捷和推动数字化转型,而不是为一堆冠名“数字化转型”的文档买单。

这些结合客户常见现状、误区和思考断言,也是未来在核心转型中可以借鉴和参考的要素。流水可能会绕路,但绝不会回头。

1.4新思路新出路

面对复杂性,需要的不仅仅是一套“方案”,而是一套应对的“原则”。

针对以上常见的困惑,窘境和挑战,要达成核心云原生分布式转型的成功,我们需要的不仅仅是一套技术方案,更需要一套能够指引行动的“原则”。正如雷-达里奥在《原则》一书中提到:原则犹如指引行动的“灯塔”,它连接着我们的目标与行动。解决不确定性靠敏捷、解决复杂性靠原则,越是复杂的系统越需要一套原则来保证。

我们将金融核心转型所需要的原则总结为一个全新“六边形”原则。

1)业务技术闭环原则:整个体系需要支持“业务-技术”闭环敏捷模式,让业务敏捷从一句口号到真正能够快速开发落地上线(从有业务想法,到建模,到领域设计,到服务设计,到数据模型,到应用开发,到应用部署,到应用治理,到应用运维的)

2)自动化生产线原则:云原生分布式转型提供端到端的工具链,必要的基础构件以及先进的实施工艺,形成完备的、端到端的、自动化的、高效的、简便的且可落地、可运营、可治理的完整体系。比如可以将业务流程数字化为可呈现可复用的资产,并能自动化转换成为应用系统编排流程。比如可以将业务的服务模型定义自动化转换成为应用和微服务模块的代码框架,并且可以选择装配对于云原生分布式环境下事务与数据一致性的支持,选择装配从业务角度端到端监控的能力,类似的能力数不胜数。

3)开放可插拔原则:这个体系是开放,可集成的生态体系,能够以相对标准化,规模化的方式构建出云原生应用。

4)可组装构造原则:依赖这种体系,可高效支持新的金融业务形态,如绿色金融,普惠金融,数字金融,碳金融,开放金融等等。因为这些纷繁复杂模式的标准化构件通过生产线能够快速制造并复制出来,只需要叠加和装配差异性的部分。

5)普适性兼容性原则:这种体系彻底的改变了目前核心领域手工作坊的人力堆积模式。如果最复杂且对于技术要求最高的核心领域都可以采用这种模式来实现,那么该体系更可以使用在面向未来云原生模式的更广泛的业务应用开发领域。

6)易用透明化原则:金融机构和合作伙伴可以利用该体系进行自研可控的业务应用的高效开发而不用关注云原生应用的特殊细节与技巧,因为这些复杂的分布式与云原生装配与衔接工艺流程已经通过自动化流水线自包含实现了。

我们将这套原则沉淀为一套全新的方法论,工具平台体系和工作模式,它涵盖了业务模型与流程建设的最前端,以及系统与业务在云原生环境下的运维和运营,同时这个体系定义了比较明确的工序和生产阶段,具备高度的自动化能力,能从一个工序自动化的衔接到下一个工序,只有这样规模化、自动化、高效率的工厂化生产模式,才能实现真正的落地业务敏捷,实现应用与云原生分布式技术的可靠融合。这种新的核心系统云原生分布式转型的建设模式以及配套的自动化生产线工具体系,我们称之为“金融级云原生工场”模式。

2

金融业务新方向呼唤技术的“供给侧改革”

迪士尼有一句话反复被提及:“艺术挑战技术,技术启发艺术 ”。

新时代是一个数字时代,数字时代的金融是以数据为关键生产要素、以场景和用户价值为中心的服务模式,主要服务手段依靠对各类数字化技术的综合运用,其重要载体便是通过网络送达的软件服务,是以线上便捷服务为主、线下人工服务为辅,融合数据智能和人类温情,注重用户体验和风控原则的服务模式,金融服务将是开放、普惠、绿色的,嵌入式且灵活多变。而这样的“泛在化”金融服务必然对账户、交易、结算等核心能力提出了“泛在化”、“全时在线”的要求。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

2.1开放金融体系需要可标准化的构件式核心

规模是问题(业务)的解药,规模也是问题(系统)的根源。

如今,开放银行的理念已经成为银行业的发展共识,最基本要求是银行服务通过API、SDK的方式将银行账户、支付、结算能力提供给合作方,以实现把银行的服务融入到各行各业中。做为开放银行战略的升级,场景金融、产业链金融正在描绘更大的开放格局,形成一个“泛在化”“毛细血管”式的金融服务。这些业务需要规模来解决泛在化的场景和需求,但这样的规模也是核心系统问题根源所在。

2.1.1不能变成新“竖井”的场景金融

场景金融是基于各类金融或者非金融场景顺畅地融入金融服务。从银行的角度看,最初的场景金融主要是与平台类公司接入合作,在消费者眼中,场景金融则是便捷的支付、贷款等金融服务的获得。

随着场景金融的演进,其场景正在扩展到人们生活、学习、工作的各个方面,一些银行已经共建、自建了大量的场景金融业务。但基于场景的用户转化需要一套完整的业务系统进行支持,包括大量标准化、模块化的能力,业务能力方面包括用户中心、产品中心、合约中心、账户中心、权益中心等,数据能力方面包括用户画像、推荐模型、联邦计算等数据。

此外,随着数字人民币试点领域的扩大,金融场景正在越来越丰富,仅数字人民币的应用场景就已经超过350万个。场景的价值日益受到重视,银行都在努力构造更多的场景,这也导致了场景的碎片化以及对场景构建的敏捷性要求。我们建议银行需要及早认识到如何让场景不成为新一轮的“竖井式开发”,而业务的中台化、标准化、构件化正是解决这一问题的出路,越来越多的银行正在为其业务设计结构化的业务模型,并探索将其与应用设计紧密连接起来。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

2.1.2必须实现生态化的产业金融

从理论上来讲,供应链金融是金融业务从核心企业向周边企业拓展的最好方式,也是推动产业金融发展的理想模式。但是,供应链金融的发展往往需要依靠核心企业的意愿、平台的服务水平、周边企业的实际收益等诸多关键因素的综合作用,因此,尽管很多研究机构将供应链金融视为十万亿级别以上的大市场,但其总体发展一直不是很顺利。

如果只为供应链金融单独去建设平台,那之前存在的建设成本、相关方收益等问题,恐怕依然难以解决。只有通过超越供应链视角的大型商业平台承载供应链服务,才有可能解决单一用途平台面临的问题。国家倡导建设的行业云,可以承载这样类型的商业平台,现有商业平台也可以进一步扩大互联,使任何一家企业可以加入平台即加入供应链,在平台中也可以自由加入任何供应链,这样的平台模式,才可能突破传统供应链平台高封闭、重成本、低收益的困境,这一模式也符合国家要求大型企业开源、开放的政策基调。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

功能的大型商业互联平台不仅承载供应链,也是各类型企业建立自身应用的“标准化构件库”,企业可以根据自身需要选择云原生的标准化构件组装自己的业务,这是“产业数字化”的一大推手。当然,这需要高度的业务标准化,所幸,国家标准化发展政策正在推动这一趋势的形成,未来银行也会融入到这一宏大的数字化商业生态中,这将催生金融机构新一代面向数字生态的构件化核心系统。

2.2普惠金融体系需要可灵活组装的核心系统

普惠金融是致力于持续提高金融服务金融服务公平性、可获得性的金融服务体系,是通过更有社会责任感的经营理念、更有效率的风控手段、更低的运营成本来使更大范围的客户群体可以获得优质金融服务,在普惠金融的发展过程中,数字化技术将扮演越来越重要的角色。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

普惠金融的发展需要做好以下三个方面的工作:

1.灵活的管理:在额度管理、计价定价、风险计量等体系中需要更灵活的能够支撑不同策略调整,适应不同区域、不同时期、不同行业、不同客户分层的普惠的要求;

2.经济的管理:降低单账户/单交易成本,降低整体的综合财务成本;

3.弹性的管理:业务系统可扩展支撑更大数量的中长尾市场。

普惠的客群对象和业务特点决定了其产品碎片化、上线周期短、业务变化频繁,要求能够像积木块一样解构业务和技术能力,灵活配置、实现业务需要,金融机构的核心系统只有变得像一个可组装的流水化工场才能应对环境的快速变化,而对长尾客户群体的支持,更需要一套易扩展的核心系统架构。

2.3绿色金融体系需要可泛化设计的核心系统

发展绿色金融是不仅是金融行业的商业机会,更是金融行业的社会责任。绿色金融包括两个部分,一是面向客户的“双碳”要求触发的业务变革,一是金融机构自身要完成“双碳”目标。

按照“双碳”要求,金融机构要控制信贷资金流向,逐步减少高排放用户的信贷支持,未来也可能会逐笔核算信贷资金的“碳排放量”,控制信用业务的“碳”风险。这需要社会数据的支持,而不仅仅是来自用户的数据,需要更多的外部数据源、权威数据支持金融机构计算“碳”风险。通过构建绿色金融账户,完善绿色金融产品,提升绿色金融智能化评估,金融机构可以更好地支持绿色生态链上下游体系的开放性融合,打通绿色循环。绿色金融将推动对金融账户应用模式的泛化,从而影响核心系统的设计理念。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

全生态链绿色金融模式设计

3

金融核心转型的能力要求与建设体系

“重大问题的解决方案,永远不可能在产生这个问题的维度上出现。”--爱因斯坦

数字韧性被越来越多的金融机构所提及,什么是数字化韧性?当应对外界环境变化,或者客户需求变更时,软件产品需要有弹性和韧性,要有反应足够快的数字化体系。当集中式架构在面临“数字韧性”而“力不从心”的时候,我们认为很难用“旧时代的方法”去解决新时代的问题。云原生似乎成为一个数字化企业的“标准答案”了。

3.1何为“金融级云原生”

何为云原生呢?为什么现在云原生这么火了?

云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将应用中的非业务代码部分进行最大化的剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。

云原生技术主要以容器、DevOps、微服务、分布式中间件、分布式数据库、Serverless、服务网格、不可变基础设施、声明式API、开放应用模型(OAM)等技术为核心,能够帮助我们实现业务应用与基础设施的解耦,因此被认为新一代云计算的“操作系统”。如下是一些云原生的核心架构思想(而无关于产品):

金融机构采用云原生技术,并不是将应用上公有云,而是将金融对安全合规、交易强一致性、单元化扩展、容灾多活、全链路业务风险管理、运维管理等各方面行业要求与云原生技术进行深度融合,发展为一套既符合金融行业标准和要求、又具备云原生技术优势的“金融级云原生架构”。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

金融级云原生能将过去在应用架构层做的大量工作,尤其是弹性与韧性、可靠性、自动化等,下沉到技术架构去实现,让应用只需要关注业务逻辑本身。所以,我们有理由相信,银行的主流技术架构将从以IOE为核心的集中式架构向金融级云原生架构演进。未来金融机构基于云原生的应用,将天然具备弹性与韧性。

3.2银行核心系统转型能力需求

“总有人问我未来十年,会有什么样的变化,但很少人问我,未来十年,什么事不变的。我认为第二个问题比第一个问题更重要。因为你要把战略建立在不变的事物上。”--- 杰夫-贝索斯

通过前文的分析,不论未来金融的服务形态如何演变,我们看到,对“灵活性、易扩展、高并发、标准化组件、低成本、可靠的在线服务”的追求是金融核心的“不变”所在。所以需要将核心战略聚焦在这个“不变”上面。我们从业务、工程和技术的角度,总结了云原生分布式核心应该具备“不变”的能力需求;针对每一项能力需求,进行详细拆解为十二项支撑能力;对十二项支撑能力进行归纳分层,形成建议的云原生分布式核心建设过程中的五层十二大能力体系,如下图所示:

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

针对核心系统建设过中的困惑、业务转型对核心系统的要求,本节从业务、工程和技术能力三个方面分别进行回答。

3.2.1业务能力

业务敏捷

Q:如何提供满足金融业务新方向的核心系统?

A:可标准化的构件式核心系统、可灵活组装的核心系统和可泛化设计的核心系统,需要核心系统拥有完备的业务组件,可以通过快速配置满足不同类型客户、不同场景的业务需求。

Q:核心下移云原生分布式转型工程庞大环节众多,没有一家公司能够全方面覆盖,还采取传统项目的多家供应商集成工作模式,如何保证真正实现云原生分布式核心而不是新瓶装旧酒,换汤不换药?

A:云原生分布式核心建设不仅仅是通过云原生技术对核心系统进行重写,满足自研可控和容量性能的需求;更重要的是从业务价值的角度对核心系统进行重新规划,形成全行企业级可复用的业务中台能力和快速创新能力,支持业务敏捷。

3.2.2工程能力

质量、工期、风险可控

Q:如何确保核心安全可靠的完成云原生分布式转型?

A:从项目组织管理的角度来看:建议核心系统建设工程是一把手工程,不仅是技术创新突破,还可以通过业务架构和应用架构变革带来组织架构的变化;所以,整个核心系统建设需要业务部门充分参与而非科技部门自嗨。从工程过程的角度来看:研发过程中,各厂商应基于行内统一的技术体系和应用组件、标准的实施工艺,开发核心系统涉及的众多应用;在系统迁移切换时,可采用不停机在线迁移模式,实现新老核心的平稳、有序过渡。

Q:传统厂商懂业务应用但是不懂云原生和分布式,懂云原生分布式的不懂银行业务,如何推进?

A:建议在云原生分布式核心系统建设初期,通过一个轻量级咨询项目,借助一批有云原生分布式核心落地经验的专家,结合金融机构自身业务特点,绘制核心系统蓝图;并基于选定的技术架构和应用架构,选择典型交易场景进行原型验证,确保架构层面满足核心系统需求。

持续治理

Q:核心云原生分布式转型一定是一个过程,在这个过程中如何快速集成不同技术体系构建的应用系统?

A:核心系统云原生分布式转型过程中,会涉及到多种类型系统的集成:云原生分布式核心与老核心、已有其他系统(渠道等)的集成;同时,从我们在多家行的实践来看,与云原生分布式核心集成的系统通常存在多种技术栈(Spring Cloud、Dubbo等)。建议使用服务网格(ServiceMesh)进行系统间集成,在充分发挥其多技术栈集成能力的同时,还能享受服务治理的红利。

3.2.3技术能力

Q:核心云原生分布式转型的技术难点或者挑战主要有那些?

A:核心云原生分布式转型过程中,技术难点通常集中在非功能需求方面,例如分布式架构下大量微服务调用带来的性能问题、分布式事务带来的一致性问题、硬件采用PC机带来的稳定性问题等,以及大规模分布式集群下如何进行系统运维的问题。因此,需要有一套经过磨合验证、满足核心系统研发和运行时需求的IaaS和PaaS平台,结合云原生分布式核心设计、研发过程中的最佳实践,才能从容应对转型过程中的各种挑战。

高性能、无限容量

Q:核心云原生分布式转型对于分布式数据库的考虑有那些,尤其是对分布式事务处理?

A:分布式数据库应具备以下几方面的能力,降低核心系统研发和运维的复杂度:内置分布式事务引擎、透明可扩展、极致的高可用、同城容灾RPO为零。

安全稳定运行

Q:核心云原生分布式转型,传统主机或虚机与云之间的关系,二种模式的混合运维给生产中心带来哪些挑战?

A:建议通过统一管理及自动化运维能力,使用单一平台对多种云资源(包括传统主机、虚拟机)进行灵活的管理、编排与部署。同时,针对云原生分布式核心系统的运维,面临着应用集群规模庞大、交易链路节点变多、PC服务器稳定性等多方面的挑战,可参考互联网企业在高可用运维和容灾等方面的经验,建设面向风险管理的SRE运维体系。

自研可控

Q:将云原生分布式核心纳入自研可控体系,如何做到风险可控?

A:建议采用自研可控单元化架构,在单元化架构下设置一个独立的自研可控单元(采用符合自研可控要求的软硬件);基于单元化流量调拨能力,先小流量验证自研可控单元能力后,再逐步增加流量到自研可控单元,稳步实现自研可控转型,做到风险可控。

3.3支撑核心转型的五层十二大能力体系

上一节回答了云原生分布式核心建设过程中需具备的能力,本节将针对提出的五层十二大能力体系进行详细的阐述。

3.3.1业务领域建模

为了使IT系统完整的承接业务需求,云原生领域建模是运用领域建模思想,充分考虑云原生应用的特点,使用领域建模及管理平台,把建模变得简单、敏捷、易落地,并通过平台实现建模资产的保鲜。具体来说,云原生领域建模通过抓住建模本质,简化建模过程;采用建模平台,管理模型资产;运用低代码技术,落地模型资产。

业务领域建模应关注以下几个方面:

3.3.1.1业务建模与技术建模

业务领域建模包括业务建模和技术建模,整体建模流程图如下:

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

1.业务建模包括业务流程建模和业务对象建模:

2.技术建模是为了对业务模型进行落地实现,把上述业务模型转换为技术模型。通过技术建模,实现三个模型的转换:

3.3.1.2建模平台

建模工具是支持业务领域建模的平台,包括对领域模型、数据模型、中台能力模型等的管理,提升建模设计效率并有效沉淀最佳实践。

在建模平台中,技术模型包含:微服务模型、流程模型、实体模型、数据模型。

通过上述步骤,最终得到技术模型中的微服务模型、流程模型、实体模型和数据模型。

3.3.2应用架构集成

应用架构集成层承接业务领域建模成果,将核心系统按照业务领域建模体系进行整体规划,形成可供全行IT系统复用的业务中台能力,提供生产各业务系统必须的业务组件;通过服务治理与组合的低代码能力,快速支撑业务创新;服务网格为传统应用、迁移到云原生分布式架构下的应用互通提供技术保障。

应用架构层面,云原生分布式核心与传统瘦核心或分布式核心重大区别是:

3.3.2.1应用架构中台化

1.云原生分布式核心中台化应用架构

通过多年自身金融业务实践和实际参与银行客户核心系统转型项目,基于标准化业务建模和技术建模成果,建议将用户、产品、合约、额度、交易、账户、计价等金融服务的核心商业要素数字化、中台化,构建出全行级中台能力地图,从而支持前台业务的快速迭代。

云原生分布式核心中台化应用架构,可参考下图:

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

2.强大、稳定的中台组件

每一个中台组件的设计,都承接自业务领域建模成果,具备丰富的业务功能。为确保中台组件集能支撑业务敏捷创新,中台组件应具备如下能力:

3.3.2.2服务治理与组合

金融行业通常采用了分层、分域的IT架构,每一个层、每个域都提供了大量的服务。

架构转型的过程中,通过服务统一治理和运营,在技术层面支撑研发过程、确保安全生产运行;在业务层面通过金融业务中台提供服务复用能力,高效进行流程组装,支持业务敏捷、快速响应市场需求。

1.服务治理保障生产稳定运行

通过架构分层、能力域、系统、应用、服务等多级领域模型,全面梳理软件资产,建立服务目录,提升服务复用率;提供服务的全生命周期管理,覆盖事前、事中、事后环节,支持服务保鲜,建立服务反馈和优化闭环。

2.服务运营编排,支撑业务敏捷、快速创新

服务组合方面,通过业务中台提供的可复用原子金融服务使用可视化服务编排能力,实现低代码快速开发业务场景,缩减研发周期,提高产研效率,降低投产风险。

服务编排平台内置流程模型驱动业务开发,通过编排、执行两大核心能力取代研发过程中部分枯燥而重复的工作;同时,我们认为平台应该深度集成中间件,提供一个完整的金融级服务编排解决方案。服务编排能力大图如下:

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

3.3.2.3异构应用集成

1.传统微服务、ServiceMesh和传统单体应用集成需求

在向云原生架构转型的过程中,传统单体应用也面临着迁移云原生分布式转型的挑战;同时,两种微服务架构(传统SDK微服务和Sidecar模式)并存已经是一个不可回避的现实问题。如何打通诸多异构应用系统,实现全面云原生分布式转型,需要有一套强大的技术支撑体系。

2. 基于服务网格(ServiceMesh)实现异构系统集成

在云原生架构下,服务网格可以轻松应对异构系统集成的问题。通过服务网格平台,提供与平台无关、语言无关、轻量无侵入的云原生架构集成与治理能力:兼容 Kubernetes和 Istio生态、支持传统SDK模式微服务框架的服务治理;支持物理机、虚拟机场景,兼容过渡阶段的容器化和虚拟化混合部署的场景,满足传统单体应用向Service Mesh转型的需求。

3.3.3应用系统建设

应用系统建设层提供标准化生产线,屏蔽复杂的云原生技术细节,规范云原生应用开发标准。

应用系统建设层面,应重点考虑以下几方面:

3.3.3.1统一开发体系

1.复杂的云原生技术细节和难以管理的ISV(独立软件开发供应商)多技术栈应用

在云原生体系下,应用开发所采用的技术架构,涉及到数量庞大、使用复杂的技术组件,如何让技术服务于应用开发而不是成为障碍和故障点,是一个必须回答的问题;同时,采购了大量独立软件供应商(ISV)的应用,不同ISV使用了不同微服务框架、注册中心、消息中间件、事务中间件等中间件,实际造成行里的开发技术栈不统一,提高了开发人员的学习成本,同时也增大了系统的运维难度。

2.简化、标准化和规范化应用开发

通过云原生应用开发框架,提供从金融级应用、组件到工具类包等多层次的开发支持,从而提升研发效能、保障研发质量。这里面应该主要包括:

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

在应用层面,通过脚手架可以快速创建规范化、标准化、金融级的应用开发工程。工程基于应用模板(灵活可定制)创建,目录结构和应用分层标准化,集成金融级中间件和架构规范(日志、错误码等规范);

在组件层面,可生成符合不同金融场景的组件使用模板代码,确保使用的正确性和规范性。以金融IT开发中备受关注的分布式事务组件为例,可以基于不同业务场景选择合适的事务模型,生成标准化代码模板,开发人员只需要关注业务逻辑实现即可;

在工具类包层面,提供全面的金融级工具类(例如金融日期操作类、金额操作类等),避免安全隐患。

3.3.3.2开发运维一体化

1.云原生分布式核心对研发、运维发布的挑战

从传统核心到云原生分布式核心,不仅仅是系统本身的架构进行了重塑与变化,更是在团队、度量、流程、规范、质量、工具、时效等层面都提出了更高的要求。有以下几方面的挑战需要去应对:

2.开发运维一体化支撑高效研发与运维发布

开发运维一体化平台,覆盖从项目协同、代码管理到持续集成、持续发布等阶段全流程管理,避免多入口和流程割裂,实现规范、标准的快速落地,提供从研发到发布的全链路数字化管理,确保核心系统的研发效能和高效可靠发布。

首发丨阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?

开发运维一体化平台我们认为应该具备以下几方面的能力:

3.3.4基础软件设施

基础软件设施层面,提供在苛刻的金融场景中久经考验的基础软件设施和架构体系,涵盖从运行时和运维时所需要的各项能力,包括异地多活单元化架构能力、分布式服务能力、分布式数据库、高可用运维能力。

基础软件设施层面,应关注以下几点:

3.3.4.1分布式服务能力

作为支撑云原生分布式核心应用分布式、微服务化的基础能力,分布式服务能力应该涵盖:同步调用的双模微服务、异步解耦的消息队列服务、支撑批量作业的任务调度和API网关。

1.高性能的双模微服务体系,满足联机交易场景需求

双模微服务体系,支持传统SDK服务框架和ServiceMesh两种模式的微服务体系。核心系统对双模微服务体系,有以下具体的能力需求:

2.高可靠的消息队列服务,满足异步解耦需求,提升交易响应时间

云原生分布式核心系统中,通过消息队列可以将很多业务功能从联机交易中解耦,在提升联机交易性能的同时,也为业务的扩展性提供了可能。

例如:存款账户余额变动通知,可以通过异步消息发送给不同的系统进行消费,从而实现多种类型的业务功能(短信/微信通知、头寸实时计算等);交易核算分离也可以通过异步消息做到准实时的核算。

云原生分布式核心系统中,消息队列应做到消息不丢、确保能够被消费成功。

同时,事务消息机制是消息队列应该提供的能力;无需核心应用再建立一套消息发送表,来实现消息的可靠发送。

3.高性能、高可用的调度框架,支撑核心系统大量的批处理作业

核心系统有大量的批处理作业,包括基于文件的批处理(如代发工资)和周期性执行的批处理(如存款结息、计提等)。

在分布式架构下,批处理调度框架具备两个层面的能力,提升处理性能:

同时,调度框架的高可用性也非常重要,完善的重试、断点续作等自动化异常处理机制,可以大大降低运维人员的人工介入,在提升效率的同时避免人工干预带来新的风险。

4.多种模式、高性能和保障一致性的分布式事务组件

核心应用服务的分布式化和数据分布式存储,必然会引入分布式事务。分布式事务组件具有以下能力:

5.高性能、多协议且具备灵活路由规则的API网关

在部分银行的实践中,云原生分布式核心在银行整体IT架构中对外还是一个完整的系统。在这种架构下,核心系统可以通过API网关作为对外服务门户,实现服务治理、协议转换等统一的处理;同时,在单元化架构下,基于API网关进行服务路由分发,是单元化必备的能力。

对于API网关,需要具备如下几方面的特点:

3.3.4.2分布式数据能力

分布式数据能力有三种不同的架构模式:分布式数据库、传统关系型数据库+分布式数据中间件体系、分布式数据库+分布式数据访问中间件。

这三种模式中,推荐采用“分布式数据库+分布式数据访问中间件”模式配合单元化架构,在充分发挥分布式数据相关优势(容灾、自研可控、弹性)的同时,又能享受单元化架构带来的红利。

1.分布式数据库

应用于金融核心系统的分布式数据库,必须在核心金融场景中稳定运行、经过严格的验证。分布式数据库应具备以下几方面的能力,降低核心系统研发和运维难度:

2.传统关系型数据库+分布式数据中间件体系

基于传统关系型数据库和分布式数据中间件,也可以实现数据分布式存储与访问能力。该模式下,分布式数据中间件体系需要包含以下组件:

3.分布式数据库+分布式数据访问中间件

在单元化架构下,通常采用这种模式。分布式数据库基于业务数据某个维度切分为多个集群部署,每个集群相互独立;数据访问中间件提供对应用透明的集群选择能力。

3.3.4.3高可用运维能力

1.核心系统转型中带来的运维挑战

核心系统在云原生分布式转型过程中,运维同样也面临了一系列新的挑战,其中最为主要的几个挑战有: