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

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

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

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

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

        刘伟光阿里巴巴集团副总裁阿里云新金融&互联网事业部总经理中国金融四十人论坛(CF40)理事2022.01.08 上海

引言


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

第一章综合的介绍了目前核心领域分布式架构转型,云原生分布式转型的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)易用透明化原则:金融机构和合作伙伴可以利用该体系进行自研可控的业务应用的高效开发而不用关注云原生应用的特殊细节与技巧,因为这些复杂的分布式与云原生装配与衔接工艺流程已经通过自动化流水线自包含实现了。

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

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


相关文章
|
3月前
阿里云ARMS的新版和老版界面是两套不同的系统
阿里云ARMS的新版和老版界面是两套不同的系统
54 2
|
3月前
|
人工智能 监控 算法
阿里云加强公共云能力服务香港客户,建立新合作支持各行各业加快数字转型
阿里云加强公共云能力服务香港客户,建立新合作支持各行各业加快数字转型
95 1
|
3月前
|
弹性计算 Linux Shell
阿里云ecs linux系统如何进行系统盘的扩容
【1月更文挑战第25天】【1月更文挑战第122篇】阿里云ecs linux系统如何进行系统盘的扩容
212 1
|
1月前
|
存储 人工智能 自然语言处理
“智能+”时代,深维智信如何借助阿里云打造AI内容生成系统
随着数字经济的发展,线上数字化远程销售模式越来越成为一种主流,销售流程也演变为线上视频会议、线下拜访等多种方式的结合。根据Gartner报告,到2025 年60%的B2B 销售组织将从基于经验和直觉的销售转变为数据驱动的销售,将销售流程、销售数据、销售分析合并形成一致的运营实践。
405 0
“智能+”时代,深维智信如何借助阿里云打造AI内容生成系统
|
1月前
|
消息中间件 编解码 运维
阿里云 Serverless 异步任务处理系统在数据分析领域的应用
本文主要介绍异步任务处理系统中的数据分析,函数计算异步任务最佳实践-Kafka ETL,函数计算异步任务最佳实践-音视频处理等。
175311 348
|
1月前
|
自然语言处理 算法 关系型数据库
阿里云PAI大模型RAG对话系统最佳实践
本文为大模型RAG对话系统最佳实践,旨在指引AI开发人员如何有效地结合LLM大语言模型的推理能力和外部知识库检索增强技术,从而显著提升对话系统的性能,使其能更加灵活地返回用户查询的内容。适用于问答、摘要生成和其他依赖外部知识的自然语言处理任务。通过该实践,您可以掌握构建一个大模型RAG对话系统的完整开发链路。
|
2月前
|
弹性计算 安全 Linux
阿里云ECS Linux系统漏洞修复详细教程
阿里云ECS Linux系统漏洞修复详细教程
|
2月前
|
监控 数据可视化 测试技术
集成阿里云 RPA 与现有系统
随着企业对自动化和数字化转型的需求不断增长,阿里云 RPA(机器人流程自动化)技术成为了提升业务效率和减少人工操作的重要工具。本文将介绍如何集成阿里云 RPA 与现有系统,以实现更高效的业务流程自动化。
|
2月前
|
人工智能 自然语言处理 搜索推荐
阿里云推出企业级大模型RAG系统,几次点击即可连接PB级知识库
阿里云推出企业级大模型RAG系统,几次点击即可连接PB级知识库
738 1

热门文章

最新文章