阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?
“既然未来已来,不如直接进入那个未来!”
核心系统转型,相当于给正在跳动的心脏,做一场不停摆的换心手术。
不少核心系统采用的传统集中式架构,已经不止是一种技术架构模式,而成为一种根深蒂固的思维习惯和设计理念。当它成为潜规则而影响了创新时,我们往往身在此山中而不为所知。
在阿里巴巴集团副总裁、阿里云新金融&互联网事业部总经理刘伟光看来,不少机构在做核心系统转型时,极易陷入窘境:
选择应用平迁、不做架构大变化,最简单和快捷。有的银行正因如此,开发力量80%以上的时间是在做代码的性能优化,难以承接新功能、新业务的开发。 先从简单系统着手进行架构转型,再推导到核心转型。结果非核心领域的转型实践对于核心领域的参考借鉴意义有限。 核心系统按照功能模块切分,再众包给不同的开发商来完成,避免被一家绑定。 选择各个领域的最佳“供应商”,完成各自擅长的工作任务(咨询建模、架构、设计、应用、基础软硬件),大家只熟悉自己这部分的“最佳实践”。 追求技术架构完成解耦,碎片化供应商。实际上项目实施过程中IaaS/PaaS层适配虽然功能大体能够适配,但在非功能性领域的磨合总出现莫名其妙的问题,产生大量沟通与适配成本。 业务应用是业务应用开发商的事情,技术平台是技术平台供应商的事情,两者没有关系。 ……
这次,刘伟光将全面探讨金融行业,尤其是银行业,在进行核心系统转型、升级过程中遇到的方方面面的问题与挑战。本文从酝酿到成文历经四年,期间他与团队拜访过近千家金融机构,沉淀出3.5万字长文。
当中包括:目前核心领域分布式架构转型、金融级云原生分布式转型的21个困惑与解答,新业态对旧核心的挑战,双核心并行与在线迁移的大致方案,以及第三代核心的标准与定义等。
“核”聚变 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. 实施路径与建设模式 39
4.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建设中皇冠上的明珠,是一家银行的心脏,在我们与诸多银行沟通交流的过程中,从那些无数次碰撞的火花中,脑海中关于未来核心系统建设的影子已经从一个模糊的亮光逐渐清晰。它不再是银行科技部门按部就班按照周期建设的系统,它不再是一个固化的标准存贷汇功能堆积的能力集合,它不应该是不断修修补补加外挂的平台,它不再是和数据平台和数据服务能力割裂的系统,它不再是一个牵一发动全身的架构体系。首先它必须是银行数字化转型中最重要的一把手工程,是一个能够让内部员工和外部客户都能感受到数字化能力无处不在的平台;它是一个能够快速生成新流程,快速创建和发布新业务新产品,能力单元高度复用的平台;它是一个能够具备移动化数据化智能化特征的平台;它是一个分布式基础架构技术支撑的平台,能够以弹性能力应对互联网类业务的峰值;它是一个融合云计算中的先进技术能力去应对开放银行和生态银行时代所有业务的一栈式平台,这就是我们脑海中那个未来的样子。今天我们已经看到有些银行已经在这个路上去积极的探索,这些探索的背后我相信就是未来引领行业,全新的最佳实践。
我们在内部和外部不断的探索与实践中,逐渐提炼和总结了一些系统性的思考,也就是如何构造具备核心竞争力的核心系统,打造真正“硬核的内核”,逐渐优化和改变目前建设的工程化体系,同时在基础技术平台和应用系统的耦合度上深入的进行研究探索,对于系统物理和逻辑部署形态上做了创新的实践,同时融合了云计算体系当中最先进的云原生技术理念。
希望此文能够给从业者带来一些新的思考,从更大的视角去构建智能化内核能力无处不在的新平台,重塑数字金融时代的商业价值。
此刻我和团队就在某银行数据中心现场参与主机应用迁移到分布式云原生架构平台的过程,能亲身见证这些推动金融行业发展变革的历程,是我们这一代从业者的荣耀,也是我们的责任!
本书分为五个章节,比较完整的涵盖了金融行业,尤其是银行行业的核心领域在进行转型、升级过程中遇到的方方面面的问题与挑战。可以说,在数字化成为现代企业转型发展的标配下,金融行业、尤其是银行行业,其问题、思考与实践具有相当的代表意义。作为这个过程的亲身观察者,参与者,直到推动者的过程当中,我们如实的记录下来了从业者的艰难实践,以及结合我们内部的和外部的实践总结,希望能够为这一伟大的历程做出自己的一些贡献,为从业者提供一些中肯的建议,少走一些弯路,多一些从容与信心。
第一章综合的介绍了目前核心领域分布式架构转型,云原生分布式转型的21个问题与困惑,这是历经两年多的实地走访与调研的100%真实的问题。同时不光有问题,也有我们总结归纳并交叉验证过的核心转型成功的三大标志,这是本文一切努力服务的三大目标。同时根据一些有代表性的实践,我们列举了核心从业者的实际的窘境,并引出了六大断言。综合这些问题,窘境与断言,我们总结归纳出六个新的思路方向来解决这个世纪的难题。
第二章从不确定性时代的金融业务挑战出发,主要从业务方向的角度分析了当下相对较新的金融业务形态对于传统金融核心的挑战与要求,主要是开放金融体系对于标准构件的要求,普惠金融体系对于灵活组装核心的需求,绿色金融体系对于核心可泛化性的要求。当下的核心阻碍业务敏捷的障碍,这些新业务对于敏捷的要求,一一为您呈现
第三章从银行核心系统的转型能力需求的方面,主要从技术方向的角度分析了转型的能力要求,回答了不少第一章行业和核心从业者的困惑。提炼了五层十二大能力体系,这些是新一代云原生分布式核心建设的最佳参考模型。涵盖业务建模领域,应用架构集成领域,应用系统开发建设领域,基础软件设施领域,以及基础资源设施领域。
第四章在第二章业务角度和第三章技术角度的基础之上,分析了不同细分银行行业的大致模式,经过提炼总结成为实施与建设的四阶段五层的实施路径。同时介绍了三种不同的建设模式,重构模式,平行迁移模式以及SaaS化批量模式。供不同规模的银行机构参考。并且按照相关的国家指引,给银行提供了双核心并行与在线迁移的大致方案。
第五章最后进行了全篇的总结,从实际的数据出发,给出了核心云原生分布式转型的价值,给出了第三代核心,也就是云原生分布式核心的一些建议标准与定义,同时再次总结了一些建设过程中的经验教训,帮助金融企业,银行机构早日实现核心转型的重要价值。
一 金融核心分布式转型的行业变革
曾几何时,银行业务系统、特别是银行核心系统都与“云技术”没有任何联系,云原生的种种技术和架构优势(
微服务解耦
、敏捷开发、自动化测试与发布、不可变基础设施、去中心化的服务治理、声明式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核心转型成功的标志
桥梁越大,内部结构就越重要。
在实践和探索的过程中,我们通过不断分析归纳总结,得到了下列这张大图,这是志同道合的客户和我们共同的认知与成果,在这个领域,我们必须要心怀敬畏。因为在传统银行核心下移分布式云原生改造的领域,这是一条无人之路,大家都在不断探索和学习。
这张图展现的就是核心转型的初心,以及金融机构对合作伙伴的要求。也是考虑迎接核心转型这个挑战“以终为始”的出发点。整体而言,分为两个部分。
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.1开放金融体系需要可标准化的构件式核心
2.1.1不能变成新“竖井”的场景金融
2.1.2必须实现生态化的产业金融
2.2普惠金融体系需要可灵活组装的核心系统
2.3绿色金融体系需要可泛化设计的核心系统
3.1何为“金融级云原生”
分布式微服务:微服务的核心就是将大的单体应用拆分为更小的组件服务(微服务)。能够做到从底层IT基础设施、到数据库、到中间件、到应用部署包等全部环境都能够独立部署。这样实现从需求设计、开发、打包、部署全部都能够独立完成。实现各个微服务之间彻底的松耦合。同时微服务之间又能够通过轻量的接口进行交互。 DevOps:核心就是敏捷研发、持续集成和持续交付。需要将软件生命周期过程中的需求、设计、开发、编译、构建、打包、部署,从测试环境、到生产环境整个过程能够实现全部自动化。将敏捷研发、自动化测试进行集成和协同。 服务网格:去中心化的服务集成和治理框架。原来架构一般采用集中式ESB总线/API网关来做接口、API的服务治理和管控,将API接口注册到API网关。由于ESB/API网关是一个中心化的架构,所有的请求和流量通过API网关,所以中心化的API网关可以对流量进行安全、日志、限流熔断、监控等各方面的管控和治理能力。当在去中心化的架构下,没有中心化的EBS/API网关情况下,所有流量下沉到了各个微服务中去了,需要在为服务端增加一个边车代理,通过边车代理来做流量的拦截,同时实现对流量的管控和服务治理。 不可变基础设施:当传统环境部署中,当有各类变更(应用程序、数据库、中间件、基础设施等)发生时,往往可以直接修改配置来实现。但云原生强调任何应用当你部署到生产环境中形成一个实例(容器/虚机)后,这个实例不能发生任何变更。当发生了变更修改时,应该基于镜像生成一个新的实例,同时销毁旧的实例。 声明式API:与命令式API操作相对应的概念。传统环境的后端操作(比如创建一个容器实例)会去执行命令行,来完成操作动作(这种方式对小规模应用而言比较有效,但大规模和自动化而言,就非常低效)。而对于声明式API而言,需要通过定义声明配置文件(比如:YAML文件),来声明清楚所要做的动作、以及做完后需要达到的状态。只需要完成这个声明式的配置文件,底层平台再去解释这个声明式API配置文件的内容,再去做后端的操作,同时把各个底层的技术组件协调到需要的状态。声明式API下面,任何对生产环境、对软件的修改都不是直接去操作一个命令来完成,都是先要写声明、写配置,这个配置文件可以纳入配置管理中集中去做管控和管理的。这样既可以大规模、自动化去执行变更和管理任务,也可以当生产环境出问题时,可以快速去追溯对生产环境做过什么样的操作,方便做相关的回退和回滚操作。
3.2银行核心系统转型能力需求
3.2.1业务能力
3.2.2工程能力
3.2.3技术能力
3.3支撑核心转型的五层十二大能力体系
3.3.1业务领域建模
基于银行同业已有建模实践成果敏捷建模,而非投入大量资源且周期长的建模过程; 通过建模平台实现成果保鲜,持续为业务迭代和创新服务,而非核心系统建设完成之后束之高阁,逐步与系统演进结果脱节; 建模成果能够借助建模平台、结合云原生技术快速落地。
3.3.1.1业务建模与技术建模
业务流程建模:通过对业务流程现状分析,结合目标核心系统建设能力要求,参考行业建模成果,形成结构化的业务流程模型; 业务对象建模:基于信息模型资产,结合对业务流程提取的业务实体,进一步分析实体间关系,获得业务对象模型和业务行为模型。
业务流程模型到服务流程组合的转换; 业务对象模型到逻辑/物理数据模型的转化; 对象行为模型到API接口/原子服务的转换。
3.3.1.2建模平台
领域架构作为系统的整体架构,包含系统中所有的业务模型,把系统中的业务模型按架构图的方式编排起来; 业务模型是由业务流程组成,是多条业务流程的集合; 业务流程串联交易模型,形成业务流程图; 交易模型中定义交易行为、交易的属性及交易行为的输入输出; 信息模型主用于定义九大信息要素:参与者、产品、合约、账户、事件、条件、地理位置、资源项、渠道,理论上任何交易模型都是由九大信息要素构成,在不能满足时也支持添加新的信息要素。
微服务模型是利用云原生特性,把业务流程中的步骤进行聚类分析,获得相应的微服务模型; 流程模型承接业务建模中的业务流程,通过对业务流程中的功能进行细化分析,获得实现业务功能的一个或多个具体接口,明确每个接口的输入输出字段,分析出实现业务功能所需的实体及实体间关系,获得实体模型; 需要持久化的实体模型,按数据库设计的相关要求转换为数据模型,通常情况下实体模型与数据模型是一对一或一对多关系。
3.3.2应用架构集成
不是:简单的将核心系统按照业务条线划分为客户、存款、贷款等应用,采用分布式技术重新实现一遍,很多公共的能力(例如产品管理、合约管理等)都需要各个应用重复建设,数据层面不互通; 而是:将核心系统按照业务领域建模体系进行整体规划设计,形成可供全行IT系统复用的业务中台能力,提供业务构件;通过服务运营与编排,使用业务构件快速进行业务创新。
3.3.2.1应用架构中台化
功能丰富:经过核心系统实际使用验证、具备能够支撑产品系统的必备业务功能; 迭代稳定:作为企业级能力共享组件,被大量产品系统复用,需要能够保持稳定、清晰的迭代升级路径; 非功能特性卓越:具备优秀的性能和可用性,为整个产品系统的性能和业务连续性提供保障。
3.3.2.2服务治理与组合
3.3.2.3异构应用集成
3.3.3应用系统建设
统一ISV(独立软件开发供应商)开发技术栈,避免技术管理失控,降低系统运行风险; 统一、易用的开发平台与框架,简化和规范化应用开发; 全流程覆盖的DevOps体系,涵盖需求结构化管理、代码版本与分支管理、质量管控与度量,自动化编译打包与部署等方方面面。
3.3.3.1统一开发体系
通过脚手架,快速创建规范化、标准化、金融级的应用开发工程; 通过组件模板,生成符合不同金融场景的组件使用模板代码,确保使用的正确性和规范性; 在工具类包层面,提供全面的金融级工具类,避免安全隐患。
3.3.3.2开发运维一体化
需求结构化与变更管理:业务需求条目化之后存储,需求变更影响分析、代码修改与测试用例变更整个过程形成闭环管理; 代码版本、分支的管理策略:面对不同上线周期的需求,如何设定代码分支、如何进行合并管理,需要有成熟的指引与配套工具; 代码质量管控与度量:面对不同合作伙伴、不同能力层级的开发人员产出的代码,需要做到代码质量可度量并得到有效的管控; 自动化编译、打包与部署:众多微服务应用、多环境和大规模部署集群,手工构建与发布已经完全不具备可行性,必须有配套的工具支撑。
项目协同:提供对需求、迭代、缺陷等各个维度的协同管理以及相关的统计报告,让研发团队高效协作; 代码管理:提供代码托管、评审和扫描、质量检测等功能,保护企业代码资产,实现安全、稳定高效的研发生产; 测试管理:标准化管理测试用例,快速搭建一体化(开发、测试、反馈)流程,有效提升交付效率和治理; 持续集成、发布流水线:提供灵活可用的持续集成、持续验证、持续发布功能,帮助企业高质量、高效率的交付业务; 制品仓库:提供多种软件包管理工具的企业级私有仓库服务,支撑企业级依赖托管。 知识库:通过可协作的结构化文档,将知识沉淀下来,并在团队中有效流动,提升企业创造力。
3.3.4基础软件设施
采用充分磨合与验证、功能完备(如单元化支持)的中间件体系,而非在应用系统开发阶段还需要不断修修补补、甚至进行架构妥协的中间件体系; 满足自研可控与容灾需求的分布式数据库,容灾情况能够真正做到可切换、敢切换; 异地多活单元化能力,不只是架构设计,还需要中间件、数据库和运维体系都具备必需的单元化支撑能力。
3.3.4.1分布式服务能力
高性能:核心的一个交易可能涉及到多次服务调用,服务框架必须高性能以避免提高服务响应时间; 可扩展:扩展性包括多个方面,例如:每家银行内部通讯协议各有不同,强大的扩展性是服务框架适配行内需求的重要考量; 企业级的服务注册中心:具备支撑海量服务注册发现的能力,从而实现银行内部真正服务打通; 服务治理能力:在具备限流、熔断、服务访问控制等动态服务质量治理能力的同时,具备与静态服务治理打通的能力,从而形成服务动静结合、全生命周期的管理; 高性能的服务链路跟踪:支持抽样的高性能跟踪能力,为分布式环境下的问题排查提供必需的基础能力。
应用分布式架构的调度、协同:统一调度、协调分布式下的批处理应用集群,充分利用分布式算力、提升批处理执行效率、降低处理时间,为日终作业链加速,留出更充分的时间给大数据处理等系统; 数据分布式架构的作业拆分与事务控制:数据分布式存储之后,一个作业中的数据按照合理的规则进行数据分包,以数据包为单位并发处理以提升执行效率,同时,要考虑分包策略对数据库事务的影响。
多种事务模式:支持TCC、SAGA等多种分布式事务实现模式;支持跨服务、跨数据库的分布式事务需求; 异常处理能力:支持空回滚、防悬挂等能力,完善的异常处理机制,包括挂起事务、异常事务的重试、监控与告警等处理。
高性能:作为每个对外服务都经过的链路节点,高性能是API网关最基础的要求; 支持多协议和协议转换:支持常见RPC协议(Dubbo、HTTP等)和行内特色通讯协议的自动转换能力; 灵活的路由规则配置:支持自定义扩展路由策略,从而可以快捷的实现单元化路由功能; 服务治理能力:在网关层提供熔断、限流、降级、访问控制等治理能力。
3.3.4.2分布式数据能力
分布式事务引擎:内置成熟的分布式事务引擎,严格支持事务的ACID属性; 透明可扩展:支持对应用透明的在线平滑扩缩容,提供不受限的数据容量和处理能力; 极致的高可用:作为核心系统数据库,需要有完备的高可用架构和高可用等级; 同城容灾RPO为零:确保同城容灾可切换、敢切换; 满足自研可控需求:国内自主知识产权的数据库,安全可控。
分布式数据访问组件:支持对应用代码透明的分库分表、读写分离和全表扫描,能够生成全局唯一序列号,可以实现平滑扩容; 数据同步组件:实现数据变更的准实时处理。通常用于数据多副本同步、分库分表数据汇聚、分布式缓存更新等场景。
3.3.4.3高可用运维能力
随着核心系统进行微服务应用拆分,原有运维管理的应用从个位数增长为数十甚至上百个; 核心应用微服务拆分后,交易链路需要跨多个微服务应用完成,对业务监控和定位提出了挑战; 以往核心系统主要采用被动运维方式,即出现故障然后定位故障和处置故障,而随着业务的不断发展,核心系统也面临互联网流量、业务快速上线等冲击,为应对多方冲击需要从被动运维转向主动运维; 技术的进步也驱动了核心系统容灾的升级,同城容灾切换RPO=0也成为新核心建设的目标,既满足合规要求,也极大的减少了业务损失; 此外还有诸如混沌工程,AIOps等智能化运维工具的优势也在逐步应用到核心系统运维中。
资金安全:发现资金损失的风险。通过执行核对规则,以小时为频率、准实时等多种时效策略,发现资金类数据问题,向用户告警;用户可以第一时间收到告警,根据异常数据排查问题,分析原因,进而解决问题; 系统安全:通过IaaS层安全系统和安全攻防演练,确保基础设施层面的安全;基于应用安全体系、数据隔离和安全扫码,确保应用层面的安全; 高可用能力:高可用能力包括风险预防能力和应急处置能力。一是通过高可用巡检能力和应急演练能力建设加强高可用风险预防能力;二是通过监控能力,故障定位能力,应急预案能力建设和打通加强应急处置能力; 成本容量管理:通过全链路压测来提升系统和业务真实水位测试能力,以此为基础去打通资源管理平台和容量管理平台。在保障业务容量稳定的前提下实现容量管理自动化,快速进行容量调拨。
3.3.4.4异地多活单元化
容灾与业务连续性:支持同城和异地容灾模式,RPO=0,RTO很短;单元化多活,缩小故障影响范围;借助自动化容灾平台,可支持容灾预案和便捷的容灾演练; 弹性:异地多活提升扩展性,理论上无限扩展;按照单元灵活部署,提升扩容效率; 资源利用率:相对传统两地三中心部署架构,单元化架构能够充分利用各个数据中心资源,显著提升资源利用率; 灰度:灵活的流量调拨能力,支持单元级灰度发布;新老单元调用隔离,避免交叉访问兼容性,提升发布效率。
数据分区:对于数据的存储至少需要具备两项能力。其一是数据分区拆分,即是把数据按照某一个维度水平划分开来;其二就是系统业务数据分区所用的拆分维度和拆分规则都保持一样,确保同一条交易在整个链路中各个业务系统的数据分区是一致的,避免出现因拆分规则不一致导致的跨单元访问; 交易路由:一笔交易链路中能够按照预先设计的单元流量规则进行流量的路由和转发。
中间件能力要求:各中间件(API网关、服务框架、消息队列等)集成单元化路由能力,并且能够通过全局的动态配置中心实时修改并准确推送路由规则到各中间件,实现单元化的切流。例如:API网关能够根据路由规则选择合适的单元进行调用分发;服务框架能够根据路由规则进行服务提供者路由、消息队列能够根据路由规则进行消息跨单元投递 数据分区能力要求:数据按同一维度水平拆分;数据分片按地域部署,各数据分片在同城和异地均有副本,数据库分片主备副本可随时切换;非容错场景各机房应用只访问本单元数据分片,容灾场景可直接访问同城的数据分片; 运维体系能力要求:支持单元化架构下的监控、容灾切换、应急预案等能力。
分布式数据在线分区调整与扩容能力:传统实现数据分区的方式是数据结构上增强拆分键用于分库分表后的数据访问路由。这种方式一旦投产后数据拆分规则就不能随意进行调整,如迫不得已必须调整,则要进行数据拆分的重新分布迁移,对业务连续性会有较大的影响。分布式数据库依靠自身的分区技术可以实现对应用相对透明的数据扩展能力;支持在线分区调整的能力则对单元化架构下实现数据分区的在线调整提供了可行性; 服务网格统一管理路由规则能力:服务网格技术是将中间件等能力下沉,实现原有各中间件的功能。同样,对于单元化的路由,也可以下沉到服务网格统一处理,减少单元化架构落地实施时对各中间件的能力需求。 通过服务网格加分布式数据库的单元化方案,因为可以根据业务需求而动态的调整分区和路由规则,所以我们称之为“动态单元化”方案。
3.3.5基础资源设施
IaaS层能够真正做到按需快速交付,避免复杂又漫长的申请、审批和采购流程; 安全、稳妥的推进自研可控能力建设,确保核心系统的业务连续性。
3.3.5.1弹性扩展能力
软件定义平台,屏蔽底层硬件差异,资源可根据需求进行横向或纵向的扩展,对上层应用无感知; 生产级的可靠性及安全合规,保证金融机构数据的连续性和安全性; 统一管理入口,对不同人员的角色进行权限隔离,便于用户运维管里。
3.3.5.2自研可控能力
3.4基于能力体系打造的金融级云原生工场
设计车间:业务领域建模是将业务需求转化为IT能力的关键设计环节,充分考虑云原生应用的特点,使用领域建模及管理平台,把建模过程变得简单、敏捷,建模成果易落地并持续保鲜; 原材料(功能完备的组件与连接器):核心引擎通过中台化能力中心,承接业务领域建模成果,为生产业务系统提供功能完备的业务组件;服务治理与集成作为连接器,集成各业务组件进行服务组合,支撑业务快速创新;服务网格作为连接器集成多种技术栈的新老系统,为应用互联互通提供保障能力; 标准化生产线:通过企业级应用开发和架构治理平台、企业级一站式DevOps平台,屏蔽复杂的云原生技术细节,提供低代码编排生产能力,助力金融机构和合作伙伴(ISV)高效开发业务应用; 运行底座:坚实的技术底座,涵盖充分磨合的PaaS、IaaS、单元化架构和高可用运维体系,为云原生分布式核心的稳定运行奠定坚实的基础;基于单元化架构和一云多芯的自研可控能力,满足金融机构自研可控需求。
4.1四阶段五层模式
4.2多种实施路径
4.2.1重构模式
4.2.1.1业务重构
4.2.1.2技术重构
4.2.2平行迁移模式
4.2.3 SaaS化批量模式
4.3 在线迁移与双核心并行
4.3.1 面临的并行挑战
4.3.2 云原生分布式核心推荐迁移策略
4.3.3迁移平台能力建设
5.1 第三代云原生分布式核心的价值体现
5.2 第三代云原生分布式核心的关键标准
5.3 核心相关系统建设的经验教训总结
5.系统建设实施的巴别塔
关键词
云原生
平台
微服务
模式
问题
最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。
版权声明:以上内容为用户推荐收藏至CareerEngine平台,其内容(含文字、图片、视频、音频等)及知识版权均属用户或用户转发自的第三方网站,如涉嫌侵权,请通知[email protected]进行信息删除。如需查看信息来源,请点击“查看原文”。如需洽谈其它事宜,请联系[email protected]。