核心系统转型，相当于给正在跳动的心脏，做一场不停摆的换心手术。
不少核心系统采用的传统集中式架构，已经不止是一种技术架构模式，而成为一种根深蒂固的思维习惯和设计理念。当它成为潜规则而影响了创新时，我们往往身在此山中而不为所知。
在阿里巴巴集团副总裁、阿里云新金融&互联网事业部总经理刘伟光看来，不少机构在做核心系统转型时，极易陷入窘境：
选择应用平迁、不做架构大变化，最简单和快捷。有的银行正因如此，开发力量80%以上的时间是在做代码的性能优化，难以承接新功能、新业务的开发。
先从简单系统着手进行架构转型，再推导到核心转型。结果非核心领域的转型实践对于核心领域的参考借鉴意义有限。
核心系统按照功能模块切分，再众包给不同的开发商来完成，避免被一家绑定。
选择各个领域的最佳“供应商”，完成各自擅长的工作任务（咨询建模、架构、设计、应用、基础软硬件），大家只熟悉自己这部分的“最佳实践”。
追求技术架构完成解耦，碎片化供应商。实际上项目实施过程中IaaS/PaaS层适配虽然功能大体能够适配，但在非功能性领域的磨合总出现莫名其妙的问题，产生大量沟通与适配成本。
业务应用是业务应用开发商的事情，技术平台是技术平台供应商的事情，两者没有关系。
……
这次，刘伟光将全面探讨金融行业，尤其是银行业，在进行核心系统转型、升级过程中遇到的方方面面的问题与挑战。本文从酝酿到成文历经四年，期间他与团队拜访过近千家金融机构，沉淀出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化批量模式。供不同规模的银行机构参考。并且按照相关的国家指引，给银行提供了双核心并行与在线迁移的大致方案。
第五章最后进行了全篇的总结，从实际的数据出发，给出了核心云原生分布式转型的价值，给出了第三代核心，也就是云原生分布式核心的一些建议标准与定义，同时再次总结了一些建设过程中的经验教训，帮助金融企业，银行机构早日实现核心转型的重要价值。
曾几何时，银行业务系统、特别是银行核心系统都与“云技术”没有任何联系，云原生的种种技术和架构优势（微服务解耦、敏捷开发、自动化测试与发布、不可变基础设施、去中心化的服务治理、声明式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开放金融体系需要可标准化的构件式核心
规模是问题（业务）的解药，规模也是问题（系统）的根源。
如今，开放银行的理念已经成为银行业的发展共识，最基本要求是银行服务通过API、SDK的方式将银行账户、支付、结算能力提供给合作方，以实现把银行的服务融入到各行各业中。做为开放银行战略的升级，场景金融、产业链金融正在描绘更大的开放格局，形成一个“泛在化”“毛细血管”式的金融服务。这些业务需要规模来解决泛在化的场景和需求，但这样的规模也是核心系统问题根源所在。
2.1.1不能变成新“竖井”的场景金融
场景金融是基于各类金融或者非金融场景顺畅地融入金融服务。从银行的角度看，最初的场景金融主要是与平台类公司接入合作，在消费者眼中，场景金融则是便捷的支付、贷款等金融服务的获得。
随着场景金融的演进，其场景正在扩展到人们生活、学习、工作的各个方面，一些银行已经共建、自建了大量的场景金融业务。但基于场景的用户转化需要一套完整的业务系统进行支持，包括大量标准化、模块化的能力，业务能力方面包括用户中心、产品中心、合约中心、账户中心、权益中心等，数据能力方面包括用户画像、推荐模型、联邦计算等数据。
此外，随着数字人民币试点领域的扩大，金融场景正在越来越丰富，仅数字人民币的应用场景就已经超过350万个。场景的价值日益受到重视，银行都在努力构造更多的场景，这也导致了场景的碎片化以及对场景构建的敏捷性要求。我们建议银行需要及早认识到如何让场景不成为新一轮的“竖井式开发”，而业务的中台化、标准化、构件化正是解决这一问题的出路，越来越多的银行正在为其业务设计结构化的业务模型，并探索将其与应用设计紧密连接起来。
2.1.2必须实现生态化的产业金融
从理论上来讲，供应链金融是金融业务从核心企业向周边企业拓展的最好方式，也是推动产业金融发展的理想模式。但是，供应链金融的发展往往需要依靠核心企业的意愿、平台的服务水平、周边企业的实际收益等诸多关键因素的综合作用，因此，尽管很多研究机构将供应链金融视为十万亿级别以上的大市场，但其总体发展一直不是很顺利。
如果只为供应链金融单独去建设平台，那之前存在的建设成本、相关方收益等问题，恐怕依然难以解决。只有通过超越供应链视角的大型商业平台承载供应链服务，才有可能解决单一用途平台面临的问题。国家倡导建设的行业云，可以承载这样类型的商业平台，现有商业平台也可以进一步扩大互联，使任何一家企业可以加入平台即加入供应链，在平台中也可以自由加入任何供应链，这样的平台模式，才可能突破传统供应链平台高封闭、重成本、低收益的困境，这一模式也符合国家要求大型企业开源、开放的政策基调。
多功能的大型商业互联平台不仅承载供应链，也是各类型企业建立自身应用的“标准化构件库”，企业可以根据自身需要选择云原生的标准化构件组装自己的业务，这是“产业数字化”的一大推手。当然，这需要高度的业务标准化，所幸，国家标准化发展政策正在推动这一趋势的形成，未来银行也会融入到这一宏大的数字化商业生态中，这将催生金融机构新一代面向数字生态的构件化核心系统。
2.2普惠金融体系需要可灵活组装的核心系统
普惠金融是致力于持续提高金融服务金融服务公平性、可获得性的金融服务体系，是通过更有社会责任感的经营理念、更有效率的风控手段、更低的运营成本来使更大范围的客户群体可以获得优质金融服务，在普惠金融的发展过程中，数字化技术将扮演越来越重要的角色。
普惠金融的发展需要做好以下三个方面的工作：
1.灵活的管理：在额度管理、计价定价、风险计量等体系中需要更灵活的能够支撑不同策略调整，适应不同区域、不同时期、不同行业、不同客户分层的普惠的要求；
2.经济的管理：降低单账户/单交易成本，降低整体的综合财务成本；
3.弹性的管理：业务系统可扩展支撑更大数量的中长尾市场。
普惠的客群对象和业务特点决定了其产品碎片化、上线周期短、业务变化频繁，要求能够像积木块一样解构业务和技术能力，灵活配置、实现业务需要，金融机构的核心系统只有变得像一个可组装的流水化工场才能应对环境的快速变化，而对长尾客户群体的支持，更需要一套易扩展的核心系统架构。
2.3绿色金融体系需要可泛化设计的核心系统
发展绿色金融是不仅是金融行业的商业机会，更是金融行业的社会责任。绿色金融包括两个部分，一是面向客户的“双碳”要求触发的业务变革，一是金融机构自身要完成“双碳”目标。
按照“双碳”要求，金融机构要控制信贷资金流向，逐步减少高排放用户的信贷支持，未来也可能会逐笔核算信贷资金的“碳排放量”，控制信用业务的“碳”风险。这需要社会数据的支持，而不仅仅是来自用户的数据，需要更多的外部数据源、权威数据支持金融机构计算“碳”风险。通过构建绿色金融账户，完善绿色金融产品，提升绿色金融智能化评估，金融机构可以更好地支持绿色生态链上下游体系的开放性融合，打通绿色循环。绿色金融将推动对金融账户应用模式的泛化，从而影响核心系统的设计理念。
全生态链绿色金融模式设计
“重大问题的解决方案，永远不可能在产生这个问题的维度上出现。”--爱因斯坦
数字韧性被越来越多的金融机构所提及，什么是数字化韧性？当应对外界环境变化，或者客户需求变更时，软件产品需要有弹性和韧性，要有反应足够快的数字化体系。当集中式架构在面临“数字韧性”而“力不从心”的时候，我们认为很难用“旧时代的方法”去解决新时代的问题。云原生似乎成为一个数字化企业的“标准答案”了。
3.1何为“金融级云原生”
何为云原生呢？为什么现在云原生这么火了？
云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。
云原生技术主要以容器、DevOps、微服务、分布式中间件、分布式数据库、Serverless、服务网格、不可变基础设施、声明式API、开放应用模型（OAM）等技术为核心，能够帮助我们实现业务应用与基础设施的解耦，因此被认为新一代云计算的“操作系统”。如下是一些云原生的核心架构思想（而无关于产品）：
分布式微服务：微服务的核心就是将大的单体应用拆分为更小的组件服务（微服务）。能够做到从底层IT基础设施、到数据库、到中间件、到应用部署包等全部环境都能够独立部署。这样实现从需求设计、开发、打包、部署全部都能够独立完成。实现各个微服务之间彻底的松耦合。同时微服务之间又能够通过轻量的接口进行交互。
DevOps：核心就是敏捷研发、持续集成和持续交付。需要将软件生命周期过程中的需求、设计、开发、编译、构建、打包、部署，从测试环境、到生产环境整个过程能够实现全部自动化。将敏捷研发、自动化测试进行集成和协同。
服务网格：去中心化的服务集成和治理框架。原来架构一般采用集中式ESB总线/API网关来做接口、API的服务治理和管控，将API接口注册到API网关。由于ESB/API网关是一个中心化的架构，所有的请求和流量通过API网关，所以中心化的API网关可以对流量进行安全、日志、限流熔断、监控等各方面的管控和治理能力。当在去中心化的架构下，没有中心化的EBS/API网关情况下，所有流量下沉到了各个微服务中去了，需要在为服务端增加一个边车代理，通过边车代理来做流量的拦截，同时实现对流量的管控和服务治理。
不可变基础设施：当传统环境部署中，当有各类变更（应用程序、数据库、中间件、基础设施等）发生时，往往可以直接修改配置来实现。但云原生强调任何应用当你部署到生产环境中形成一个实例（容器/虚机）后，这个实例不能发生任何变更。当发生了变更修改时，应该基于镜像生成一个新的实例，同时销毁旧的实例。
声明式API：与命令式API操作相对应的概念。传统环境的后端操作（比如创建一个容器实例）会去执行命令行，来完成操作动作（这种方式对小规模应用而言比较有效，但大规模和自动化而言，就非常低效）。而对于声明式API而言，需要通过定义声明配置文件（比如：YAML文件），来声明清楚所要做的动作、以及做完后需要达到的状态。只需要完成这个声明式的配置文件，底层平台再去解释这个声明式API配置文件的内容，再去做后端的操作，同时把各个底层的技术组件协调到需要的状态。声明式API下面，任何对生产环境、对软件的修改都不是直接去操作一个命令来完成，都是先要写声明、写配置，这个配置文件可以纳入配置管理中集中去做管控和管理的。这样既可以大规模、自动化去执行变更和管理任务，也可以当生产环境出问题时，可以快速去追溯对生产环境做过什么样的操作，方便做相关的回退和回滚操作。
金融机构采用云原生技术，并不是将应用上公有云，而是将金融对安全合规、交易强一致性、单元化扩展、容灾多活、全链路业务风险管理、运维管理等各方面行业要求与云原生技术进行深度融合，发展为一套既符合金融行业标准和要求、又具备云原生技术优势的“金融级云原生架构”。
金融级云原生能将过去在应用架构层做的大量工作，尤其是弹性与韧性、可靠性、自动化等，下沉到技术架构去实现，让应用只需要关注业务逻辑本身。所以，我们有理由相信，银行的主流技术架构将从以IOE为核心的集中式架构向金融级云原生架构演进。未来金融机构基于云原生的应用，将天然具备弹性与韧性。
3.2银行核心系统转型能力需求
“总有人问我未来十年，会有什么样的变化，但很少人问我，未来十年，什么事不变的。我认为第二个问题比第一个问题更重要。因为你要把战略建立在不变的事物上。”--- 杰夫-贝索斯
通过前文的分析，不论未来金融的服务形态如何演变，我们看到，对“灵活性、易扩展、高并发、标准化组件、低成本、可靠的在线服务”的追求是金融核心的“不变”所在。所以需要将核心战略聚焦在这个“不变”上面。我们从业务、工程和技术的角度，总结了云原生分布式核心应该具备“不变”的能力需求；针对每一项能力需求，进行详细拆解为十二项支撑能力；对十二项支撑能力进行归纳分层，形成建议的云原生分布式核心建设过程中的五层十二大能力体系，如下图所示：
针对核心系统建设过中的困惑、业务转型对核心系统的要求，本节从业务、工程和技术能力三个方面分别进行回答。
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业务建模与技术建模
业务领域建模包括业务建模和技术建模，整体建模流程图如下：
1.业务建模包括业务流程建模和业务对象建模：
业务流程建模：通过对业务流程现状分析，结合目标核心系统建设能力要求，参考行业建模成果，形成结构化的业务流程模型；
业务对象建模：基于信息模型资产，结合对业务流程提取的业务实体，进一步分析实体间关系，获得业务对象模型和业务行为模型。
2.技术建模是为了对业务模型进行落地实现，把上述业务模型转换为技术模型。通过技术建模，实现三个模型的转换：
业务流程模型到服务流程组合的转换；
业务对象模型到逻辑/物理数据模型的转化；
对象行为模型到API接口/原子服务的转换。
3.3.1.2建模平台
建模工具是支持业务领域建模的平台，包括对领域模型、数据模型、中台能力模型等的管理，提升建模设计效率并有效沉淀最佳实践。
在建模平台中，业务模型包含领域架构、业务模型、业务流程、交易模型、信息模型五层，五层概念逐层缩小：
领域架构作为系统的整体架构，包含系统中所有的业务模型，把系统中的业务模型按架构图的方式编排起来；
业务模型是由业务流程组成，是多条业务流程的集合；
业务流程串联交易模型，形成业务流程图；
交易模型中定义交易行为、交易的属性及交易行为的输入输出；
信息模型主用于定义九大信息要素：参与者、产品、合约、账户、事件、条件、地理位置、资源项、渠道，理论上任何交易模型都是由九大信息要素构成，在不能满足时也支持添加新的信息要素。
在建模平台中，技术模型包含：微服务模型、流程模型、实体模型、数据模型。
微服务模型是利用云原生特性，把业务流程中的步骤进行聚类分析，获得相应的微服务模型；
流程模型承接业务建模中的业务流程，通过对业务流程中的功能进行细化分析，获得实现业务功能的一个或多个具体接口，明确每个接口的输入输出字段，分析出实现业务功能所需的实体及实体间关系，获得实体模型；
需要持久化的实体模型，按数据库设计的相关要求转换为数据模型，通常情况下实体模型与数据模型是一对一或一对多关系。
通过上述步骤，最终得到技术模型中的微服务模型、流程模型、实体模型和数据模型。
3.3.2应用架构集成
应用架构集成层承接业务领域建模成果，将核心系统按照业务领域建模体系进行整体规划，形成可供全行IT系统复用的业务中台能力，提供生产各业务系统必须的业务组件；通过服务治理与组合的低代码能力，快速支撑业务创新；服务网格为传统应用、迁移到云原生分布式架构下的应用互通提供技术保障。
应用架构层面，云原生分布式核心与传统瘦核心或分布式核心重大区别是：
不是：简单的将核心系统按照业务条线划分为客户、存款、贷款等应用，采用分布式技术重新实现一遍，很多公共的能力（例如产品管理、合约管理等）都需要各个应用重复建设，数据层面不互通；
而是：将核心系统按照业务领域建模体系进行整体规划设计，形成可供全行IT系统复用的业务中台能力，提供业务构件；通过服务运营与编排，使用业务构件快速进行业务创新。
3.3.2.1应用架构中台化
1.云原生分布式核心中台化应用架构
通过多年自身金融业务实践和实际参与银行客户核心系统转型项目，基于标准化业务建模和技术建模成果，建议将用户、产品、合约、额度、交易、账户、计价等金融服务的核心商业要素数字化、中台化，构建出全行级中台能力地图，从而支持前台业务的快速迭代。
云原生分布式核心中台化应用架构，可参考下图：
2.强大、稳定的中台组件
每一个中台组件的设计，都承接自业务领域建模成果，具备丰富的业务功能。为确保中台组件集能支撑业务敏捷创新，中台组件应具备如下能力：
功能丰富：经过核心系统实际使用验证、具备能够支撑产品系统的必备业务功能；
迭代稳定：作为企业级能力共享组件，被大量产品系统复用，需要能够保持稳定、清晰的迭代升级路径；
非功能特性卓越：具备优秀的性能和可用性，为整个产品系统的性能和业务连续性提供保障。
3.3.2.2服务治理与组合
金融行业通常采用了分层、分域的IT架构，每一个层、每个域都提供了大量的服务。
架构转型的过程中，通过服务统一治理和运营，在技术层面支撑研发过程、确保安全生产运行；在业务层面通过金融业务中台提供服务复用能力，高效进行流程组装，支持业务敏捷、快速响应市场需求。
1.服务治理保障生产稳定运行
通过架构分层、能力域、系统、应用、服务等多级领域模型，全面梳理软件资产，建立服务目录，提升服务复用率；提供服务的全生命周期管理，覆盖事前、事中、事后环节，支持服务保鲜，建立服务反馈和优化闭环。
2.服务运营编排，支撑业务敏捷、快速创新
服务组合方面，通过业务中台提供的可复用原子金融服务使用可视化服务编排能力，实现低代码快速开发业务场景，缩减研发周期，提高产研效率，降低投产风险。
服务编排平台内置流程模型驱动业务开发，通过编排、执行两大核心能力取代研发过程中部分枯燥而重复的工作；同时，我们认为平台应该深度集成中间件，提供一个完整的金融级服务编排解决方案。服务编排能力大图如下：
3.3.2.3异构应用集成
1.传统微服务、ServiceMesh和传统单体应用集成需求
在向云原生架构转型的过程中，传统单体应用也面临着迁移云原生分布式转型的挑战；同时，两种微服务架构（传统SDK微服务和Sidecar模式）并存已经是一个不可回避的现实问题。如何打通诸多异构应用系统，实现全面云原生分布式转型，需要有一套强大的技术支撑体系。
2. 基于服务网格(ServiceMesh)实现异构系统集成
在云原生架构下，服务网格可以轻松应对异构系统集成的问题。通过服务网格平台，提供与平台无关、语言无关、轻量无侵入的云原生架构集成与治理能力：兼容 Kubernetes和 Istio生态、支持传统SDK模式微服务框架的服务治理；支持物理机、虚拟机场景，兼容过渡阶段的容器化和虚拟化混合部署的场景，满足传统单体应用向Service Mesh转型的需求。
3.3.3应用系统建设
应用系统建设层提供标准化生产线，屏蔽复杂的云原生技术细节，规范云原生应用开发标准。
应用系统建设层面，应重点考虑以下几方面：
统一ISV（独立软件开发供应商）开发技术栈，避免技术管理失控，降低系统运行风险；
统一、易用的开发平台与框架，简化和规范化应用开发；
全流程覆盖的DevOps体系，涵盖需求结构化管理、代码版本与分支管理、质量管控与度量，自动化编译打包与部署等方方面面。
3.3.3.1统一开发体系
1.复杂的云原生技术细节和难以管理的ISV（独立软件开发供应商）多技术栈应用
在云原生体系下，应用开发所采用的技术架构，涉及到数量庞大、使用复杂的技术组件，如何让技术服务于应用开发而不是成为障碍和故障点，是一个必须回答的问题；同时，采购了大量独立软件供应商（ISV）的应用，不同ISV使用了不同微服务框架、注册中心、消息中间件、事务中间件等中间件，实际造成行里的开发技术栈不统一，提高了开发人员的学习成本，同时也增大了系统的运维难度。
2.简化、标准化和规范化应用开发
通过云原生应用开发框架，提供从金融级应用、组件到工具类包等多层次的开发支持，从而提升研发效能、保障研发质量。这里面应该主要包括：
通过脚手架，快速创建规范化、标准化、金融级的应用开发工程；
通过组件模板，生成符合不同金融场景的组件使用模板代码，确保使用的正确性和规范性；
在工具类包层面，提供全面的金融级工具类，避免安全隐患。
在应用层面，通过脚手架可以快速创建规范化、标准化、金融级的应用开发工程。工程基于应用模板（灵活可定制）创建，目录结构和应用分层标准化，集成金融级中间件和架构规范（日志、错误码等规范）；
在组件层面，可生成符合不同金融场景的组件使用模板代码，确保使用的正确性和规范性。以金融IT开发中备受关注的分布式事务组件为例，可以基于不同业务场景选择合适的事务模型，生成标准化代码模板，开发人员只需要关注业务逻辑实现即可；
在工具类包层面，提供全面的金融级工具类（例如金融日期操作类、金额操作类等），避免安全隐患。
3.3.3.2开发运维一体化
1.云原生分布式核心对研发、运维发布的挑战
从传统核心到云原生分布式核心，不仅仅是系统本身的架构进行了重塑与变化，更是在团队、度量、流程、规范、质量、工具、时效等层面都提出了更高的要求。有以下几方面的挑战需要去应对：
需求结构化与变更管理：业务需求条目化之后存储，需求变更影响分析、代码修改与测试用例变更整个过程形成闭环管理；
代码版本、分支的管理策略：面对不同上线周期的需求，如何设定代码分支、如何进行合并管理，需要有成熟的指引与配套工具；
代码质量管控与度量：面对不同合作伙伴、不同能力层级的开发人员产出的代码，需要做到代码质量可度量并得到有效的管控；
自动化编译、打包与部署：众多微服务应用、多环境和大规模部署集群，手工构建与发布已经完全不具备可行性，必须有配套的工具支撑。
2.开发运维一体化支撑高效研发与运维发布
开发运维一体化平台，覆盖从项目协同、代码管理到持续集成、持续发布等阶段全流程管理，避免多入口和流程割裂，实现规范、标准的快速落地，提供从研发到发布的全链路数字化管理，确保核心系统的研发效能和高效可靠发布。
开发运维一体化平台我们认为应该具备以下几方面的能力：
项目协同：提供对需求、迭代、缺陷等各个维度的协同管理以及相关的统计报告，让研发团队高效协作；
代码管理：提供代码托管、评审和扫描、质量检测等功能，保护企业代码资产，实现安全、稳定高效的研发生产；
测试管理：标准化管理测试用例，快速搭建一体化（开发、测试、反馈）流程，有效提升交付效率和治理；
持续集成、发布流水线：提供灵活可用的持续集成、持续验证、持续发布功能，帮助企业高质量、高效率的交付业务；
制品仓库：提供多种软件包管理工具的企业级私有仓库服务，支撑企业级依赖托管。
知识库：通过可协作的结构化文档，将知识沉淀下来，并在团队中有效流动，提升企业创造力。
3.3.4基础软件设施
基础软件设施层面，提供在苛刻的金融场景中久经考验的基础软件设施和架构体系，涵盖从运行时和运维时所需要的各项能力，包括异地多活单元化架构能力、分布式服务能力、分布式数据库、高可用运维能力。
基础软件设施层面，应关注以下几点：
采用充分磨合与验证、功能完备（如单元化支持）的中间件体系，而非在应用系统开发阶段还需要不断修修补补、甚至进行架构妥协的中间件体系；
满足自研可控与容灾需求的分布式数据库，容灾情况能够真正做到可切换、敢切换；
异地多活单元化能力，不只是架构设计，还需要中间件、数据库和运维体系都具备必需的单元化支撑能力。
3.3.4.1分布式服务能力
作为支撑云原生分布式核心应用分布式、微服务化的基础能力，分布式服务能力应该涵盖：同步调用的双模微服务、异步解耦的消息队列服务、支撑批量作业的任务调度和API网关。
1.高性能的双模微服务体系，满足联机交易场景需求
双模微服务体系，支持传统SDK服务框架和ServiceMesh两种模式的微服务体系。核心系统对双模微服务体系，有以下具体的能力需求：
高性能：核心的一个交易可能涉及到多次服务调用，服务框架必须高性能以避免提高服务响应时间；
可扩展：扩展性包括多个方面，例如：每家银行内部通讯协议各有不同，强大的扩展性是服务框架适配行内需求的重要考量；
企业级的服务注册中心：具备支撑海量服务注册发现的能力，从而实现银行内部真正服务打通；
服务治理能力：在具备限流、熔断、服务访问控制等动态服务质量治理能力的同时，具备与静态服务治理打通的能力，从而形成服务动静结合、全生命周期的管理；
高性能的服务链路跟踪：支持抽样的高性能跟踪能力，为分布式环境下的问题排查提供必需的基础能力。
2.高可靠的消息队列服务，满足异步解耦需求，提升交易响应时间
云原生分布式核心系统中，通过消息队列可以将很多业务功能从联机交易中解耦，在提升联机交易性能的同时，也为业务的扩展性提供了可能。
例如：存款账户余额变动通知，可以通过异步消息发送给不同的系统进行消费，从而实现多种类型的业务功能（短信/微信通知、头寸实时计算等）；交易核算分离也可以通过异步消息做到准实时的核算。
云原生分布式核心系统中，消息队列应做到消息不丢、确保能够被消费成功。
同时，事务消息机制是消息队列应该提供的能力；无需核心应用再建立一套消息发送表，来实现消息的可靠发送。
3.高性能、高可用的调度框架，支撑核心系统大量的批处理作业
核心系统有大量的批处理作业，包括基于文件的批处理（如代发工资）和周期性执行的批处理（如存款结息、计提等）。
在分布式架构下，批处理调度框架具备两个层面的能力，提升处理性能：
应用分布式架构的调度、协同：统一调度、协调分布式下的批处理应用集群，充分利用分布式算力、提升批处理执行效率、降低处理时间，为日终作业链加速，留出更充分的时间给大数据处理等系统；
数据分布式架构的作业拆分与事务控制：数据分布式存储之后，一个作业中的数据按照合理的规则进行数据分包，以数据包为单位并发处理以提升执行效率，同时，要考虑分包策略对数据库事务的影响。
同时，调度框架的高可用性也非常重要，完善的重试、断点续作等自动化异常处理机制，可以大大降低运维人员的人工介入，在提升效率的同时避免人工干预带来新的风险。
4.多种模式、高性能和保障一致性的分布式事务组件
核心应用服务的分布式化和数据分布式存储，必然会引入分布式事务。分布式事务组件具有以下能力：
多种事务模式：支持TCC、SAGA等多种分布式事务实现模式；支持跨服务、跨数据库的分布式事务需求；
异常处理能力：支持空回滚、防悬挂等能力，完善的异常处理机制，包括挂起事务、异常事务的重试、监控与告警等处理。
5.高性能、多协议且具备灵活路由规则的API网关
在部分银行的实践中，云原生分布式核心在银行整体IT架构中对外还是一个完整的系统。在这种架构下，核心系统可以通过API网关作为对外服务门户，实现服务治理、协议转换等统一的处理；同时，在单元化架构下，基于API网关进行服务路由分发，是单元化必备的能力。
对于API网关，需要具备如下几方面的特点：
高性能：作为每个对外服务都经过的链路节点，高性能是API网关最基础的要求；
支持多协议和协议转换：支持常见RPC协议（Dubbo、HTTP等）和行内特色通讯协议的自动转换能力；
灵活的路由规则配置：支持自定义扩展路由策略，从而可以快捷的实现单元化路由功能；
服务治理能力：在网关层提供熔断、限流、降级、访问控制等治理能力。
3.3.4.2分布式数据能力
分布式数据能力有三种不同的架构模式：分布式数据库、传统关系型数据库+分布式数据中间件体系、分布式数据库+分布式数据访问中间件。
这三种模式中，推荐采用“分布式数据库+分布式数据访问中间件”模式配合单元化架构，在充分发挥分布式数据相关优势（容灾、自研可控、弹性）的同时，又能享受单元化架构带来的红利。
1.分布式数据库
应用于金融核心系统的分布式数据库，必须在核心金融场景中稳定运行、经过严格的验证。分布式数据库应具备以下几方面的能力，降低核心系统研发和运维难度：
分布式事务引擎：内置成熟的分布式事务引擎，严格支持事务的ACID属性；
透明可扩展：支持对应用透明的在线平滑扩缩容，提供不受限的数据容量和处理能力；
极致的高可用：作为核心系统数据库，需要有完备的高可用架构和高可用等级；
同城容灾RPO为零：确保同城容灾可切换、敢切换；
满足自研可控需求：国内自主知识产权的数据库，安全可控。
2.传统关系型数据库+分布式数据中间件体系
基于传统关系型数据库和分布式数据中间件，也可以实现数据分布式存储与访问能力。该模式下，分布式数据中间件体系需要包含以下组件：
分布式数据访问组件：支持对应用代码透明的分库分表、读写分离和全表扫描，能够生成全局唯一序列号，可以实现平滑扩容；
数据同步组件：实现数据变更的准实时处理。通常用于数据多副本同步、分库分表数据汇聚、分布式缓存更新等场景。
3.分布式数据库+分布式数据访问中间件
在单元化架构下，通常采用这种模式。分布式数据库基于业务数据某个维度切分为多个集群部署，每个集群相互独立；数据访问中间件提供对应用透明的集群选择能力。
3.3.4.3高可用运维能力
1.核心系统转型中带来的运维挑战
核心系统在云原生分布式转型过程中，运维同样也面临了一系列新的挑战，其中最为主要的几个挑战有：
随着核心系统进行微服务应用拆分，原有运维管理的应用从个位数增长为数十甚至上百个；
核心应用微服务拆分后，交易链路需要跨多个微服务应用完成，对业务监控和定位提出了挑战；
以往核心系统主要采用被动运维方式，即出现故障然后定位故障和处置故障，而随着业务的不断发展，核心系统也面临互联网流量、业务快速上线等冲击，为应对多方冲击需要从被动运维转向主动运维；
技术的进步也驱动了核心系统容灾的升级，同城容灾切换RPO=0也成为新核心建设的目标，既满足合规要求，也极大的减少了业务损失；
此外还有诸如混沌工程，AIOps等智能化运维工具的优势也在逐步应用到核心系统运维中。
2.四位一体的高可用运维保障体系
核心在云原生分布式转型的同时，构建与之对应的高可用运维保障体系显得尤为必要。总体来说，高可用运维保障体系需包括系统安全、资金安全、高可用能力以及成本容量管理四大部分，如下图所示：
资金安全：发现资金损失的风险。通过执行核对规则，以小时为频率、准实时等多种时效策略，发现资金类数据问题，向用户告警；用户可以第一时间收到告警，根据异常数据排查问题，分析原因，进而解决问题；
系统安全：通过IaaS层安全系统和安全攻防演练，确保基础设施层面的安全；基于应用安全体系、数据隔离和安全扫码，确保应用层面的安全；
高可用能力：高可用能力包括风险预防能力和应急处置能力。一是通过高可用巡检能力和应急演练能力建设加强高可用风险预防能力；二是通过监控能力，故障定位能力，应急预案能力建设和打通加强应急处置能力；
成本容量管理：通过全链路压测来提升系统和业务真实水位测试能力，以此为基础去打通资源管理平台和容量管理平台。在保障业务容量稳定的前提下实现容量管理自动化，快速进行容量调拨。
3.3.4.4异地多活单元化
异地多活是分布式系统的一种高可用部署架构，可以满足金融机构城市级容灾的需求。实现异地多活架构的关键问题是如何处理跨地域的网络延迟影响，而单元化架构为异地多活架构的实现提供了可行路径。
所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。
单元化架构就是把单元作为部署的基本单位，在所有机房中部署数个单元，每个机房里的单元数目不定，每一个单元都部署了系统所需的所有应用，数据则是全量数据按照某种维度划分后的一部分。
通过采用单元化架构，在容灾、弹性、资源利用率和灰度发布方面都将有显著收益：
容灾与业务连续性：支持同城和异地容灾模式，RPO=0，RTO很短；单元化多活，缩小故障影响范围；借助自动化容灾平台，可支持容灾预案和便捷的容灾演练；
弹性：异地多活提升扩展性，理论上无限扩展；按照单元灵活部署，提升扩容效率；
资源利用率：相对传统两地三中心部署架构，单元化架构能够充分利用各个数据中心资源，显著提升资源利用率；
灰度：灵活的流量调拨能力，支持单元级灰度发布；新老单元调用隔离，避免交叉访问兼容性，提升发布效率。
单元化架构的核心原则是单元内流量封闭，这样将同一笔业务处理的上下游链路均在同一个单元内完成，避免了中间跨地域调用的网络延迟。为了实现单元化架构，需要围绕两个方面来设计系统能力，一方面是数据分区，另一方面是交易路由：
数据分区：对于数据的存储至少需要具备两项能力。其一是数据分区拆分，即是把数据按照某一个维度水平划分开来；其二就是系统业务数据分区所用的拆分维度和拆分规则都保持一样，确保同一条交易在整个链路中各个业务系统的数据分区是一致的，避免出现因拆分规则不一致导致的跨单元访问；
交易路由：一笔交易链路中能够按照预先设计的单元流量规则进行流量的路由和转发。
1.经典单元化
采用中间件来实现单元化的方案，在头部互联网公司和一些大中型金融机构获得了广泛实践，并且获得了广泛的技术收益，我们称之为“经典单元化”架构。
经典单元化架构对中间件、数据分区和运维体系都提出了相应的能力要求：
中间件能力要求：各中间件（API网关、服务框架、消息队列等）集成单元化路由能力，并且能够通过全局的动态配置中心实时修改并准确推送路由规则到各中间件，实现单元化的切流。例如：API网关能够根据路由规则选择合适的单元进行调用分发；服务框架能够根据路由规则进行服务提供者路由、消息队列能够根据路由规则进行消息跨单元投递
数据分区能力要求：数据按同一维度水平拆分；数据分片按地域部署，各数据分片在同城和异地均有副本，数据库分片主备副本可随时切换；非容错场景各机房应用只访问本单元数据分片，容灾场景可直接访问同城的数据分片；
运维体系能力要求：支持单元化架构下的监控、容灾切换、应急预案等能力。
2.动态单元化
经典单元化架构中，对应用数据分区和中间件能力建设提出了很高的要求，系统建设成本较高、实施周期较长。
伴随技术的演进，分布式数据库、服务网格技术逐步成熟，并已在头部互联网企业获得了广泛应用，这些新技术应用也为单元化架构的实现带来了新的思路。
仍然从单元化架构落地需要具备的两项能力出发，数据分区和交易路由：
分布式数据在线分区调整与扩容能力：传统实现数据分区的方式是数据结构上增强拆分键用于分库分表后的数据访问路由。这种方式一旦投产后数据拆分规则就不能随意进行调整，如迫不得已必须调整，则要进行数据拆分的重新分布迁移，对业务连续性会有较大的影响。分布式数据库依靠自身的分区技术可以实现对应用相对透明的数据扩展能力；支持在线分区调整的能力则对单元化架构下实现数据分区的在线调整提供了可行性；
服务网格统一管理路由规则能力：服务网格技术是将中间件等能力下沉，实现原有各中间件的功能。同样，对于单元化的路由，也可以下沉到服务网格统一处理，减少单元化架构落地实施时对各中间件的能力需求。
通过服务网格加分布式数据库的单元化方案，因为可以根据业务需求而动态的调整分区和路由规则，所以我们称之为“动态单元化”方案。
3.3.5基础资源设施
基础设施层具有高度开放性和弹性扩展能力，可以灵活适配、稳定管理不同类型的基础设施，为核心系统的自主掌控和降本增效提供无限可能。
云原生架构下的基础资源设施层面，应重点考虑以下几方面：
IaaS层能够真正做到按需快速交付，避免复杂又漫长的申请、审批和采购流程；
安全、稳妥的推进自研可控能力建设，确保核心系统的业务连续性。
3.3.5.1弹性扩展能力
采用云原生架构的IaaS层，实现云原生分布式核心系统按需获得IT资源、保持业务持续性的需求。
通过基础设施云化，实现资源打通，通过弹性扩容，使得成本、性能及稳定性达到最优。
IaaS层应具备以下几方面的特征：
软件定义平台，屏蔽底层硬件差异，资源可根据需求进行横向或纵向的扩展，对上层应用无感知；
生产级的可靠性及安全合规，保证金融机构数据的连续性和安全性；
统一管理入口，对不同人员的角色进行权限隔离，便于用户运维管里。
3.3.5.2自研可控能力
核心系统作为银行最关键的业务系统，逐步落地自研可控的信息技术体系成为必然的发展方向。然而，在落地层面存在以下几方面的难点：
1.核心系统的自研可控涉及技术面较广，包括应用、中间件、数据库、云软件/虚拟化软件、各类硬件设施；
2.核心系统在落地自研可控的同时仍需保障高标准的可用性，不能因单个或部分替代导致技术水平降级；
3.不仅是中大型银行，小型银行也需要在科技人员规模较小的情况下对核心系统的开发和维护实现自研可控。
而通过多云管理与一云多芯能力、自研可控单元化架构体系，可以满足银行核心系统在自主掌控方面的需求。
1.多云管理与一云多芯
多云管理和一云多芯是解决基础资源可管理、可替代的重要基础。多云管理使用单一控制器对多种云资源（也可包括虚拟化环境）进行灵活的管理、编排、部署。一云多芯则通过适配多种类型服务器和服务器芯片，屏蔽底层硬件的差异，实现统一的云资源纳管。
2. 自研可控单元化架构
单元化架构本身具备单元内应用封闭、业务自闭环、流量可调拨、可快速容灾切换等良好的架构特性。特别适合使用到核心系统这种跨多层技术栈的自研可控场景，可通过分别构建传统软硬设施的单元和可替换软硬设施的单元，并合理分配业务流量，当某个单元出现故障时也可快速把流量切换到另外一个单元，既可逐步落地自研可控，又满足了业务连续性和技术水平不降级的要求。
3.4基于能力体系打造的金融级云原生工场
基于上节对五层十二大能力的分析，我们认为需要一整套端到端的能力体系，能够覆盖从业务建模、架构设计到系统建设，再到系统运行和运维的全流程；同时，这套能力体系应具备明确的实施工艺和高度的自动化能力，从而形成可标准化、规模化与高效的工场化生产模式。
基于这套能力体系打造的核心系统云原生分布式转型与建设模式，我们称之为“金融级云原生工场”模式。其中“云原生分布式核心轻咨询”与 “双核心并行与不停机迁移”作为系统实施路径的两个阶段，在下一章中进行阐述。
从生产过程与运行的视角来看，金融级云原生工场整体上包含了以下几方面的内容：
设计车间：业务领域建模是将业务需求转化为IT能力的关键设计环节，充分考虑云原生应用的特点，使用领域建模及管理平台，把建模过程变得简单、敏捷，建模成果易落地并持续保鲜；
原材料（功能完备的组件与连接器）：核心引擎通过中台化能力中心，承接业务领域建模成果，为生产业务系统提供功能完备的业务组件；服务治理与集成作为连接器，集成各业务组件进行服务组合，支撑业务快速创新；服务网格作为连接器集成多种技术栈的新老系统，为应用互联互通提供保障能力；
标准化生产线：通过企业级应用开发和架构治理平台、企业级一站式DevOps平台，屏蔽复杂的云原生技术细节，提供低代码编排生产能力，助力金融机构和合作伙伴（ISV）高效开发业务应用；
运行底座：坚实的技术底座，涵盖充分磨合的PaaS、IaaS、单元化架构和高可用运维体系，为云原生分布式核心的稳定运行奠定坚实的基础；基于单元化架构和一云多芯的自研可控能力，满足金融机构自研可控需求。
经过对国内一些金融机构的核心下移与改造的实施路径和建设模式分析，可以基本上分为两种建设模式：
1）核心自主重构模式
路线特点：
1.自主研发新核心系统，非采购ISV（独立软件开发供应商）核心系统产品，强调自研可控
2.大多数原有核心采用AS400或大机的银行希望采用重构的方式完成核心下移
3.建设目标包括业务建模、领域架构重构
4.绝大多数银行构建了全新的核心应用技术平台
5.部分银行选择基于云平台进行核心系统重构
6.部分银行在核心重构过程中包含自研可控规划
7.核心开发实施过程会采购ISV（独立软件开发供应商）的人力资源
采用该路线的银行范围：国有大行、股份制、大农信、部分中大城商/农商
2）采购核心产品套件模式
路线特点：
1.采购ISV的核心系统产品，并主要基于ISV的人力资源完成核心实施交付
2.主要诉求为替代原有第一代的老旧核心
3.基于ISV核心产品的业务模型和架构建设
4.基于ISV核心产品自带的应用技术平台
5.部分银行要求ISV产品简单部署在云平台上
自研可控方面，部分银行仅能够要求ISV产品集成国产数据库
采用该路线的银行范围：部分中小城商/农商、民营银行、外资银行
4.1四阶段五层模式
通过结合国内金融行业核心相关领域的实践以及核心领域对于技术的云原生分布式转型的业务能力，工程能力，技术能力要求，横纵结合形成4阶段5层的建设模式和路径：
通过这张图我们可以清晰的认识到核心下移云原生分布式转型的路径的全貌以及自身所处的不同阶段。上图中任务颜色的深浅代表在不同阶段中任务的关键程度和优先级，颜色更深的优先级更高。且每一个阶段的产出是下一个阶段的输入。从而形成一个系统化的完整的核心下移的顶层工作任务与路径阶段安排。
例如部分银行采用重构模式，即业务架构和技术架构并行改造，以金融业的领域模型重构核心业务的同时配以主流的分布式架构支撑系统；也有部分银行采用平迁模式，保持原有系统业务逻辑和流程不变，仅通过选用分布式数据库来满足底层海量数据要求。
4.2多种实施路径
4.2.1重构模式
银行核心系统的重构之旅，不仅仅只是互联网技术改造，更是自身服务模式和服务思维的再造。从流程银行转向数字银行，从产品为中心到客户为中心，从做功能转向做场景，从做渠道转向做平台。整体的实施路径会从业务重构及核心应用技术平台搭建两大方向入手,进而实现核心银行业务数字化转型。
4.2.1.1业务重构
回顾“面对误区的破局思维”的断言6
断言6：核心转型相比选择“供应商”而言，更为重要的是选择具备“端到端落地实践”的。从理念、方法论、设计规划、平台架构、标准规范都能够战略性长期投入和总体把控的“合作伙伴”才能真正落地实现业务敏捷和推动数字化转型，而不是为一堆冠名“数字化转型”的文档买单。
业务重构主要是根据业界领先的理论和最佳实践建立企业级业务模型，进而基于模型逐层细化业务规划并向产品参数化设计转变。整个改造过程会以现状业务流程、数据和产品实践为基础，以待实现的业务需求为输入，以领域驱动设计思想为指导，形成具备模型驱动的核心业务架构体系。
传统的建模方式注重在企业级架构规范的范畴，能够以结构化的方式将战略，业务连接起来，但是从实际的落地来说，并不是传统建模方式关注的。以产品为例，结合领域分层的理念，下图能够比较清晰的表明企业级建模与系统架构设计两者之前的差异。
同时传统的领域建模需要耗费大量的人力和资源，通常周期比较长，并不是所有的金融企业都能够参考建行的模式。往往全行级建模花费了数年的时间之后，整个格局，环境，战略又发生了变化，导致与时代的错配。在这个背景之下，敏捷，中台化，领域化建模的理念开始逐步进入大家的视野。
核心系统领域化架构设计的原则
1.把核心系统打开，对原有核心的业务能力重新进行领域划分
2.把核心系统中的领域实体构建成微服务应用，实现核心服务能力的对外暴露，以及业务的松耦合
核心系统领域架构设计的进一步描述
1.将核心系统的通用领域提升到中台能力层次：客户中心、产品中心、合约中心
2.将核心系统的基础功能放入基础服务层，并构建成为对应的微服务应用：账户域、定价计价域，核算清算域、公共域、财务域等。
3.将核心系统中的各个业务产品放入产品服务层，各个业务产品的微服务包含了对中台能力服务和基础服务的流程编排组装。
经过中台化的重构之后，原有的业务流程建模和逻辑也会发生相应的改变，以定期支取为例，在经过中台化的建模改造之后的流程变成如下的模式
4.2.1.2技术重构
回顾“面对误区的破局思维”的断言2、3、5
断言2：“基础不牢、地动山摇”，底层架构的高效稳定是第一目标。底层架构在起步阶段从“统一架构”更加容易走稳，再逐步进行局部优化和解耦。
断言3：核心架构中“非功能性需求”考虑要大于“功能性需求”。“非功功能性需求”应由技术架构来承载。业务模块可以解耦设计和分包，技术架构要统一规划和统一标准，实现核心领域的“统、分结合”。
断言5：核心转型最佳路径是追求“P/PC平衡”-- 产出和产能平衡。不仅仅是完成 “产出”任务（应用迁移），更为重要的是升级“产能”（技术架构能力）。“产能”（技术架构）升级后会推动更大的“产出”（业务价值），成为全行数字化转型的助推引擎。
从这三个重要的判断可以看到，核心云原生分布式转型需要一整套具备可伸缩、高可用的分布式金融技术平台作为支撑，核心应用技术平台的搭建整体包括DevOps平台、分布式中间件平台以及运维保障平台三部分。其中DevOps平台能提高核心应用开发上线的效率，主要包括有项目协作、代码托管、持续集成持续交付等；分布式中间件平台提供核心应用分布式能力层，提供了兼备应用分布式和数据分布式能力；运维保障平台主要承载核心业务系统高可用应急管理功能，提供支持容量管理、压测管理及容灾管理。
同时，技术重构由于涉及的方面太多，我们进一步的进行层次化的拆解与明确，定义了五层十二大能力体系，帮助金融机构进行相应的落地设计。
企业自身可能不太具备这样的技术能力和相应匹配的团队，需要借助大量的外部资源与伙伴来完成整个理想中的蓝图。整体的价值，优势的可获得性相对比较低。我们建议在建设过程中配套匹配的工场，流水线，实施工艺等模式，降低整体的设计，开发，部署，运营，运维的难度。让这些先进的技术真正可以落地，可以自主的掌控。建议增加中间框架体系与流水线体系，进一步降低落地难度，增加技术的可获得性，让终端的开发、运维等技术人员更容易上手，更容易使用。
4.2.2平行迁移模式
平迁模式实施的原则和前提是对业务不产生影响。业务流程不变、业务功能不变、应用处理逻辑不变、与外围系统接口不变以及数据逻辑模型不变。
在这种模式下，主要解决的是国家一些指引的要求，同时解决集中式架构的非功能层面带来的一些挑战，例如性能、扩展性这些阻碍业务发展和损害客户体验的障碍。但从助力业务发展的视角来看，平迁模式是一个过渡性的中间状态，从长远来说，最终还是要解决业务敏捷带来的挑战。
从目前行业目前的实践来看，目前具体有这么几种平行迁移形式
1）数据不动，应用下移
数据架构不动，应用按照一个一个模块进行下移和分布式改造，在过程中建立起全局的注册中心，基础微服务框架体系，同时引入分布式中间件相关技术来支持交易路由、交易熔断降级、安全中心、统一配置中心等功能。此外，为更好应对核心下移，运维体系需要相关改造完成相应日志监控、链路追踪和监控报警等功能。
这种模式的利：
数据体系和架构一般与业务和应用关联度比较高，尤其经过长期的运行之后，数据体系非常复杂，牵一发可能会动全身，回归测试等成本也会非常高。所以不动数据的模式相对比较简单，业务人员的参与程度非常低。基本上技术可控，在过程中锻炼了技术人员的分布式，云原生能力，锻炼了团队。
这种模式的弊端：
没有新的业务价值的过多体现，并且整体架构没有太多变更，转型不彻底，尤其是数据架构容易造成各种瓶颈，无论是对业务敏捷而言，还是性能角度而言。并且代码的自动化翻译工具等体系无法很好的应对领域建模等中台化要求，翻译代码需要大量的性能优化与调整，采取这种模式的开发人员通常需要花费70%的经历在代码的性能结构优化上，无暇应对新业务应用的开发。
2）应用不动，数据下移
为了灵活应对海量交易和超量数据的冲击，需要使用分布式数据技术来解决数据一致性问题。这种核心下移和分布式改造模式多辅以少量人工完成主机核心应用程序改造，或者自身已经在x86虚拟机等集中式架构下。通过接口改造与适配等来对接分布式数据库体系。这种模式对于底层的分布式，云原生数据库的技术要求非常高。
这种模式的利：
底层的交易瓶颈比较容易解除，并且实现了分布式情况下的最大挑战之一的数据一致性挑战。
这种模式的弊端：
对于分布式数据库的技术要求，成熟度要求太高，可供选择的供应商不太多。同时从业务角度而言，没有新的价值体现，也无法做到业务敏捷。
4.2.3 SaaS化批量模式
相比传统集中式架构，云原生分布式核心建设对技术积累、人员能力的要求也更高，相比有自研能力的大中型银行，中小银行新建核心除了依赖厂商的支持，也存在另一条新的路线，即金融核心SaaS。
基于云原生架构研发的金融核心，经过实地落地验证后逐步完善、标准化，最终走上SaaS化。对于银行、尤其中小银行研发资源有限的情况下，避免投入大量时间、资源做核心的下移或重构，利用SaaS产品提供的标准化组件、OpenAPI，采用低代码、服务编排快速实现业务敏捷，通过服务网格、Serverless等技术将非功能的需求下移，保障系统的高可用、可扩展、可灰度、可观测。
选择SaaS化的金融核心开拓了核心下移之旅的“批量模式”，也是面向云原生未来的架构。
4.3 在线迁移与双核心并行
4.3.1 面临的并行挑战
云原生分布式核心建设一个关键必经之路就是如何在保障安全可控的基础上完成新老核心的切换，金融机构出于人员、成本、风险等因素考虑，针对账务核心部分往往会采用按模块、按机构分批迁移的策略，云原生分布式核心建设进入到投产期将会存在双核心并行。传统方案中迁移动作需要在停业期间进行，对银行提供服务的连续性造成影响。
金融机构对自身分布式技术平台、运维体系以及核心应用的成熟度存在担忧，传统做法是在投产之前进行大量的功能测试、迁移演练、旁路验证等，但这些均不能完全呈现生产环境实际运行情况。
另外，对核心实施人员来说项目周期长、压力大，核心下移是持久战、要打硬仗，但也需要有阶段性成果进行激励、给团队信心。
4.3.2 云原生分布式核心推荐迁移策略
在按模块、按机构分批次迁移的基础上，将迁移颗粒度进一步缩小到按单客户、单账户进行迁移，把迁移的风险控制在可接受的程度。同时，整个迁移过程全部实时在线完成，包括从旧核心的数据迁出、新核心的数据迁入、并保障数据一致性。整个核心迁移期间银行不间断对外提供服务、客户无感知。
具体实施中迁移批次可以按照先内后外（银行内部客户到外部客户）、先简单后复杂（基于大数据分析客户交易习惯）等策略进行安排。
4.3.3迁移平台能力建设
要达到双核心并行以及在线平滑迁移的效果，云原生平台需要具备如下关键能力：
1.全局路由模块实现新老核心数据识别和路由转发，新核心采用单元化架构的要同步考虑单元路由；
2.迁移管控平台对数据迁出、转换、迁入等迁移步骤进行统一调度，并且保障数据迁移一致性；
3.新老核心并行期对外提供服务保持一致，减少系统间集成的影响。
只有具备以上的能力要求才能到达客户无感、不停机在线迁移和双核心并行方案，支持核心系统从集中式架构平稳、有序过渡到云原生架构。
基于该方案，金融架构将获得两方面的收益：
1.降低迁移实施风险：按客户分批次迁移、试点，逐步验证、排查与解决风险，最终完成新老核心切换。
2.提高业务连续性：在线迁移对客户正常进行业务操作没有影响；同时，技术上可以实现迁移不涉及到停业。
爱它的人，总会让它一次次重生，并赋予它更大的意义。
经过上述的探讨，我们归结出来核心转型的一些价值，一些共识和通用的标准，结论如下，可以作为行业机构设计和实施的参考。
5.1 第三代云原生分布式核心的价值体现
核心的云原生分布式转型，成为第三代云原生分布式核心，有如下的一些价值方向:
1.自研可控，100%满足相关的国家要求
2.运维成本降低400%
云原生架构基于相对廉价的PC服务器构建，在同等处理能力下，分布式架构的单位运行成本大幅度降低，分布式架构的年均运行维护成本是大型机的17%
3.业务敏捷，缩短40%以上的落地时间
云原生，中台化的模式降低业务模块间的强耦合性，业务交付更加敏捷，平均需求交付周期可以缩短40%左右，在进一步提升效率之后，可以达到数量级的效率提升
4.弹性扩展，完全线性
云原生架构具备良好的横向弹性扩展能力，较好的满足中国特有的“春节高峰”时段的特殊要求以及每年超过20%以上的业务增长量的需求，同时在底层资源充足的情况下，能够做到即时的线性扩容。
5.下一代的异地多活架构，RPO=0，RTO<1分钟
基于云原生的单元化异地多活架构，以及分布式中间件，分布式数据库，云原生分布式框架，可以构建超过三地五中心全活多活架构，具备城市级别灾备能力，城市级别RPO=0，RTO分钟级别RTO<1分钟。
5.2 第三代云原生分布式核心的关键标准
通过全篇的介绍，我们最后尝试提出云原生第三代核心的一些关键标准，这也是行业从业者的一些共识。而为了达成这些标准，我们必须转换思路，打造能实现这些标准的自动化流水线工厂。
1.云原生
云原生是应用架构演进，整体降本增效的必然趋势和要求
2.异地多活单元化
单元化是架构灰度，进行架构在线升级的关键企业级架构设计
3.中台化
中台化是实现业务敏捷，业务弹性，应对未知挑战的关键要素
4.数字化
数字化是实现面向未来金融基础设施的关键设计
5.自研可控
自研可控是实现金融安全的必要保障
而云原生工场模式，是将这些标准与规范融入至整个的标准化制造与加工流水线以及实施工艺的端到端体系化模式，助力金融机构的核心云原生分布式转型。
5.3 核心相关系统建设的经验教训总结
1.分离采购与建设模式的折扣
核心的下移不简单是从主机等集中式环境换一个云原生和分布式的平台，传统的应用是应用开发商去建设，技术平台是技术平台供应商去建设的分离模式从最终预期要达到的效果和价值来说，并不会很好。因为应用开发商对于云原生底层技术平台并没有很深的了解，很多特性和优势用不上，只能当虚拟机或者普通的数据库来使用，基本上无法发挥出云原生的真正的价值。最终实现的业务价值会大打折扣。所以建议在整体建设之前，需要通过一个轻咨询或者咨询项目设计出整体的模式，架构，规划，周期，预算等，为后期的建设做好统筹的设计，而不要盲目的开展建设项目。
2.承上启下的困难与挑战
核心等关键业务系统的云原生分布式转型，需要对于核心业务以及对于底层云原生平台都非常了解，才能够真正实现高价值的核心云原生分布式转型。应用架构和数据架构，数据模型等关键要素需要匹配分布式的环境做适应性的改造和优化设计才能保证最终的效果。例如在云化分布式环境下的账户与账务数据模型的设计，例如在两地三中心多活架构下的业务应用分域，以及客户中心，产品合约的部署设计，例如在单元化模式下的单元区分规则，数不胜数。而这一点，往往很多传统核心从业人员不太理解，认为应用业务与技术平台无关，业务是业务，应用是应用，技术平台是技术平台。这三者的之间的隔阂，导致的业务无法敏捷，应用无法扩展。而我们急需的，便是运用工场流水线模式将这两个鸿沟进行联通，运用业务建模数字化平台和工序将业务与应用有机贯穿以及同步，达成业务敏捷，运用架构治理与脚手架数字化平台和工序，将应用和最终的开发运营运维体系有机贯穿与同步，达成应用敏捷以及安全可靠。实现最终的业务端到端敏捷。
3.性能等非功能性的忽视
从集中式架构的CA取向向云原生平台的扩展性取向进行下移和建设的时候，由于增加了很多的网络，RPC，分布式存储等传统集中式架构没有的底层开销，性能层面通常在早期的设计中没有很好的考量和设计，而到最后的整体端到端性能压力测试等时候才会爆发出来，无法满足基本的并发与时延标准，达不到上线标准，然后重新进行各种调整，这个时候大的体系基本上已经建设完毕，无法做整体性优化，无法达到最优的效果。所以，建议在架构设计以及开发的早期，就要引入全链路测试与容量规划的工具，早期识别关键链路以及关键设计的缺陷，为后期大规模应用建设排雷以及打好框架基础。
4.技术风险与运营的挑战
传统集中式架构的运维保障通常由厂商和传统的服务生态来保障，而到了云原生分布式体系下，整体需要运维的技术栈和平台的数量，整体架构的复杂程度远超以前，此时需要更多的将运维保障的任务交给自动化的，体系化的技术风险防控体系来处理，这部分的设计和建设的经验传统厂商基本上比较难以具备，也没有实际落地的经验。这对于整体系统的可用性，稳定性等带来很大的隐患和风险，这部分的提前的考量，设计与建设也需要在早期同步开展，因为SRE体系对于架构，应用开发等有一定的规范和要求，遵从这些最佳实践，才能给最后的运维提供必要的支持，便利和保障，确保整体性的运维管控能够做到实效，给生产系统稳定高效运行提供真正的高效保障。
5.系统建设实施的巴别塔
系统架构即组织架构，这里的组织架构从传统意义上大家理解是系统建设成之后，整体的内部开发，运维，管控的组织结构，权责边界以及沟通交流等体系。但是从实际情况来看，新一代核心的建设周期往往都比较长，通常比较大型的金融机构建设周期都会在20个月以上，参与方众多，大家往往会忽视这个长周期项目建设团队自身的组织形式与管理模式。在云原生分布式，中台化，业务敏捷驱动的这种新的核心架构方式之上，整个核心项目组的组织形式，具体工作任务划分的方式和边界，沟通交流方式这些也会有变化。这部分目前如果还按照以前集中式架构的项目组织和开展形式来运作的话，可能会有比较大的信息不对称以及摩擦，影响整体的工程效率和最后落地的实际效果。因此我们也建议整个项目工程管理和沟通模式需要采用新的组织理念，采用数字化的工具体系来进行组织协调，更高效更高质量的完成实际落地交付上线。
最后，如果需要用几句话来进行总结的话，那就是
“集中式架构，已经不止是一种技术架构模式，而成为一种根深蒂固的思维习惯和设计理念。当它成为潜规则而影响了创新时，我们往往身在此山中而不为所知。朝着云原生分布式转型的过程中，打破这种集中式架构的思维惯性和习惯（设计、开发、运维），这些才是最难改变的”
“从金融行业的角度而言，要实现核心的云原生分布式转型的关键在于打造一套新的云原生数字化流水生产线、配套设计工艺以及稳固的云原生分布式基础设施，尝试用综合的视角去改变那些最难改变的部分”。
本文希望能够给各位读者带来一些思考和收获，能够带来一定的借鉴。如果未来一定会发生，那就先进入那个未来！
雷峰网(公众号：雷峰网)
正在生成分享图...
nebula