文/刘伟光
本文摘自《云栖战略参考》第8期
阿里巴巴集团副总裁 阿里云新金融&互联网事业部总经理 中国金融四十人论坛理事
银行核心系统是IT建设皇冠上的明珠，我们与诸多银行交流碰撞的火花中，未来核心系统的建设蓝图逐渐清晰。它不再是银行科技部门按部就班建设的系统，不再是标准存贷汇功能的集合，不再是修修补补加外挂的平台，不再是和数据平台、数据服务能力割裂的架构。
要实现金融核心云原生分布式转型，关键在于打造一套新的云原生数字化生产线、配套设计工艺以及稳固的云原生分布式基础设施，用综合的视角去变革那些最难的部分，从更高的视角去构建智能化内核能力无处不在的新平台，重塑数字金融的商业价值。
核心系统转型，相当于给正在跳动的心脏，做一场不停摆的换心手术。
不少金融机构核心系统采用的传统集中式架构，成为了根深蒂固的思维惯性和设计、开发、运维习惯。当这一习惯开始影响创新时，我们往往因身在此山中难以察觉。
四年多时间，我和团队拜访了近千家金融机构，在移动互联网和金融科技的新技术大潮中，见证了技术驱动数字金融的新时代。
国外的基础技术平台和最佳实践支撑了过去几十年的金融业发展，很多单项技术仍具备极强的竞争力。今天我们面临一个高速发展、充满不确定性的时代，需要与移动互联网和音视频能力结合。过去的技术不是不先进了，而是限制我们对未来全面数字化金融的创造力，急需一套新的技术体系以实现金融机构真正的业务和技术转型。
银行核心系统是IT建设皇冠上的明珠，我们与诸多银行交流碰撞的火花中，未来核心系统的建设蓝图逐渐清晰。它不再是银行科技部门按部就班建设的系统，不再是标准存贷汇功能的集合，不再是修修补补加外挂的平台，不再是和数据平台、数据服务能力割裂的架构。
它必须是银行数字化转型中最重要的“一把手”工程，让内部员工、外部客户都感受到数字化能力无处不在；是一个能快速生成新流程，发布新业务新产品，能力单元高度复用的平台；是一个移动化、数据化、智能化，以分布式基础架构技术支撑的平台，能以弹性能力应对业务的峰值；是一个融合云计算中先进技术，应对开放银行和生态银行所有业务的一栈式平台。不少银行已经在这条路上积极探索，引领未来行业的重要实践。
从实践中，我们提炼出了一套系统性的思考：如何构造具备竞争力的核心系统，优化工程化体系，优化基础技术平台和应用系统的耦合度，对逻辑部署形态进行创新，并融合云计算中最先进的云原生技术。
能够亲历金融行业的发展变革，是我们这一代从业者的荣耀，也是责任。
一、金融核心分布式转型的行业变革
核心系统承载了银行存款、贷款、银行卡、清算核算等核心业务，被称为“银行业跳动的心脏”。回顾银行信息化30多年历程，核心系统经历了从“胖核心”到“瘦核心”的演变。“胖核心”以IBM大型机为代表，“瘦核心”则以典型的IOE（IBM小型机、Oracle数据库、EMC存储设备的缩写）技术架构为代表。
随着银行以消费互联网、产业互联网、开放银行生态为重点的业务快速增长，新一代银行核心建设面临“挑战”。虽然集中式架构仍具备很强的竞争力和高度的稳定性，但问题也日益凸显，即高并发、线性扩展、敏捷开发、按需弹性、精细化治理、多活可靠能力，已经达到极限，系统部署无法及时响应业务需求，系统弹性能力差，资源过度规划和冗余浪费。银行核心系统的云原生重塑来到了“时代拐点”，云原生的技术架构，如微服务解耦、敏捷开发、自动化测试与发布、去中心化的服务治理、声明式API、Serverless等，必然成为银行的主流技术。
（一）核心转型的常见误区与破局
核心转型要“站在整体看局部，站在结果看过程”。
实践中，我们看到很多机构在面临核心系统转型时有一些普遍的困惑：金融核心到底该如何转型？云原生分布式是否是金融核心的未来？金融核心云原生分布式转型究竟带来哪些价值？云原生在解决原有问题的同时带来了什么新问题、如何应对？
带着这些灵魂拷问，我们调研了数十家金融机构，梳理出以下核心转型中的常见误区。
误区1：先从简单系统着手进行架构转型，再到核心转型。
例如实践中出于技术自研要求，只考虑了OA系统的架构转型，但是核心领域被卡脖子的问题依然存在。因为OA系统的技术自研对核心领域没有借鉴意义，导致未来核心应用转型仍需大量的探索。
破局：非核心领域的转型对核心领域的参考借鉴意义有限，需要尽早考量核心架构的技术自研，避免二次迁移的金钱和时间成本。
误区2：核心转型全流程选择各个领域的最佳供应商，就能达到好效果。
核心转型全流程涉及咨询建模、架构、设计、应用、基础软硬件等，实践中如果只是找了专业咨询团队进行业务咨询与建模，但大部分停留在纸面上，缺乏实操指导，核心研发团队依旧不清楚如何开展大规模开发。
后继各业务板块招采了各领域的最佳供应商，仰赖于应用开发商的经验，各开发商都只熟悉自己这部分，无法落地前期业务建模的成果，无法形成端到端总控和业务落地。
破局：核心转型选择具备“端到端落地实践”的合作伙伴。从理念、方法论、设计规划、平台架构、标准规范都能够战略性长期投入和总体把控，才能真正落地数字化转型。
误区3：追求技术架构解耦，随时可切换到可替代的技术供应商。
在核心云原生分布式转型过程中，对核心技术平台要求能够完全分层分模块解耦，不绑定任何一家技术平台供应商。实际上项目实施中IaaS/PaaS层虽然功能大体能够适配，但在稳定性、性能等“非功能性”领域常出现莫名其妙的问题，协调多家厂商的研发，产生大量沟通与适配成本。供应商众多导致无法做到全局架构管控和统一技术标准打通。
破局：“基础不牢、地动山摇”，底层架构的高效稳定是第一位的。从起步阶段“统一架构”更容易走稳，再逐步进行局部优化和解耦。业务模块可以解耦设计和分包，技术架构则要统一规划和统一标准，“统分结合”。
误区4：业务应用是应用开发商的事，技术平台是技术平台供应商的事，两者没有关系。
传统集中式架构下，技术平台经过了经年累月的标准化和适配，应用的普适性相对更强，应用开发不需要太多考虑底层架构的差异性。但在云原生架构时代，需要考虑分布式CAP（Consistency，Availability，Partition tolerance）原则，即一致性、可用性、分区容错性三者最多同时实现两点，不能三者兼顾，对应用进行折中的设计。同时，需要考虑分布式事务、分布式数据一致性、异地多活等难题对于业务模式、业务流程、业务底层数据模型的特殊影响。
这部分是传统上层应用与传统底层技术平台之间的灰色地带，往往决定了系统的整体表现，尤其在极端情况下。
破局：传统集中式架构，在云原生架构下，大多数情况下并不适用，需要引入额外的框架、机制与设计来保障核心系统的整体表现。
（二）新思路新出路
针对以上核心转型中的常见误区与挑战，要达成核心云原生分布式转型的成功，我们需要一套能够指引行动的“原则”。我们将金融核心转型所需的行动指导总结为“六边形”原则：1、业务技术闭环原则；2、自动化生产线原则；3、开放可插拔原则；4、可组装构造原则；5、普适性兼容性原则；6、易用透明化原则。
阿里云将这套“六边形”原则沉淀为一套全新的方法论、工具平台和工作模式，涵盖了业务模型与流程建设的最前端，以及在云原生环境下的运维和运营。同时，明确的工序和生产流程，具备高度的自动化，能从一个工序自动化衔接到下一个工序。我们将这种核心系统云原生分布式转型的建设模式，以及配套的自动化生产线体系，称为“金融级云原生工场”模式。
（三）核心转型成功的标志
在实践和探索的过程中，我们得到了下面这张金融核心转型的落地大图：
一是客户成功的三大标志。
首先，安全可控。第一种维度是技术架构安全可控，整体把握系统架构和关键技术，主要涉及自产自研、关键技术产品代码自主、知识产权可控等。第二种维度是业务层的解耦，按照业务发展进行自主研发迭代，而不是高度耦合、牵一发动全身。
其次，财务成本、单交易/账户成本下降。上一代集中式架构，TCO（Total Cost of Ownership）成本相对较高。不仅包括购置成本，还包括长达十多年的运营维护成本、扩容成本、人员成本等，核心转型成功应当带来成本下降。
最后，业务稳定性、连续性不降低的前提下，支撑业务敏捷。业务敏捷是面对不确定性的制胜法宝，例如对新业务的快速功能性支撑，对老业务的快速升级迭代等。但是前提是保证可靠性和稳定性。没有稳定，就没有金融安全，一切都是空中楼阁。
二是客户对合作伙伴的诉求。
要完成核心转型是整个产业链和生态的大协作，而不是一两家技术公司的事，我们总结出核心转型必备的四大要素，环环相扣，缺一不可：首先，咨询设计云原生分布式的架构设计、迁移方案、并行方案、实施路径等；其次，项目实施和组织阵型的提前设计，包括基础平台和应用开发的组织阵型规划；第三，运维保障，快速解决核心故障问题，白盒化，更自动的监控和运维工具及机制保障；第四，产品与方案层的长期规划，产品与方案是整个核心迁移和云原生分布式转型的基础支撑。
从集中式到分布式，再到云原生分布式架构的转型，是一条必经之路。
二、呼唤技术的“供给侧改革”
数字时代的金融业以数据为关键生产要素、以场景和用户价值为中心，是以线上便捷服务为主、线下人工服务为辅，融合数据智能和人的温情，注重用户体验和风控的服务模式。新兴金融体系包括开放金融体系、普惠金融体系、绿色金融体系，满足嵌入式且灵活多变，对账户、交易、结算等核心能力提出了“泛在化”“全时在线”的要求。
（一）开放金融体系可标准化的构件式核心
开放银行已成为银行业的发展共识，场景金融、产业链金融正形成“泛在化”“毛细血管”式的金融服务，描绘出更大的开放格局。这些业务需要“规模化”来满足泛在化的场景需求，“规模化”反过来也对核心系统提出了挑战。
1.不能变成新“竖井”的场景金融
随着场景金融的演进，一些银行共建、自建了大量场景金融业务。基于每个场景都需要一套完整的业务系统支持，包括大量标准化、模块化的能力，如用户中心、产品中心、合约中心、权益中心等业务能力，用户画像、推荐模型、联邦计算等数字化能力。
此外，随着数字人民币试点领域的扩大，金融场景越来越丰富，仅数字人民币的应用场景就超过350万个。银行都在努力构造更多的场景，覆盖生活、学习、工作各个方面，这导致场景的碎片化及对场景构建的敏捷性要求。
银行需要认识到如何不让场景成为新一轮的“竖井式开发”。业务的中台化、标准化、构件化是解决这一问题的出路，越来越多的银行正为业务设计结构化的业务模型，并探索将其与应用设计紧密连接。
2.必须实现生态化的产业金融
供应链金融是金融业务从核心企业向周边企业拓展的最好方式，也是推动产业金融发展的理想模式。实践中，供应链金融的发展需要依靠核心企业意愿、平台服务水平、周边企业的实际收益等诸多因素，因此，尽管很多研究机构将供应链金融视为十万亿级以上的大市场，其总体发展一直不是很顺利。
如果为供应链金融单独建设平台，其建设成本、相关方收益等难以解决。只有通过超越供应链视角的大型商业平台承载供应链服务，才有可能解决单一用途平台面临的问题。国家倡导建设的行业云，就可以承载这样的商业平台，平台中可以自由加入任何供应链；同时，现有商业平台也可以进一步扩大互联，任何一家企业加入平台即加入供应链。这样才能突破传统供应链平台高封闭、重成本、低收益的困境，也符合国家要求大型企业开源、开放的政策基调。
多功能的大型商业互联平台不仅承载供应链，还是各类企业建立自身应用的“标准化构件库”。企业可以根据自身需要，选择云原生的标准化构件组装业务，这是“产业数字化”的一大推手，需要高度的业务标准化。国家标准化发展政策正在推动这一趋势，未来银行也会融入这一数字化商业生态，催生金融机构新一代构件化核心系统。
（二）普惠金融体系可灵活组装的核心系统
普惠金融致力于提升金融服务的公平性、可获得性，通过更有社会责任感的经营理念、更有效率的风控手段、更低的运营成本赋能小微企业、农民、城镇低收入人群等弱势群体，让更广泛的客户获得优质金融服务。
普惠金融的客群对象和业务特点决定了其产品碎片化、上线周期短、业务变化频繁，需要能像积木一样解构业务和技术的能力，灵活配置、满足业务需要。针对普惠金融，金融机构的核心系统只有像可组装的流水化工场才能应对环境的快速变化，同时对长尾客户群体的支持，需要的是一套易扩展的核心系统架构。
（三）绿色金融体系可泛化设计的核心系统
发展绿色金融不仅是金融行业的商业机会，更是社会责任。绿色金融包括两个部分：一是金融机构自身要完成“双碳”目标；二是面向客户侧，“双碳”触发的业务变革。
按照“双碳”的要求，金融机构要控制信贷资金流向，逐步减少高排放用户的信贷支持，未来可能会逐笔核算信贷资金的“碳排放量”，控制信用业务“碳”风险。要实现“碳”风险计算，除了用户数据支持，还需要外部社会数据，尤其是权威数据支持。通过构建绿色金融账户，完善绿色金融产品，提升绿色金融智能化评估，金融机构可以更好地支持绿色生态链上下游体系的开放性融合，打通绿色循环。
绿色金融将推动金融账户应用模式的泛化，从而影响核心系统的设计理念。
三、金融核心转型的能力要求与建设体系
数字化韧性在当下金融核心转型中格外重要，软件产品需要有弹性、韧性，以及反应足够快的数字化体系。当集中式架构面临“数字化韧性”力不从心时，我们很难用旧时代的方法去解决新时代的问题。
（一）何为“金融级云原生”
云原生架构是基于云原生技术的架构原则和设计模式的集合，能将应用中非业务代码最大化的剥离，让云设施接管应用中原有的大量非功能特性，如弹性、韧性、安全、可观测性、灰度等，使业务不再被非功能性业务中断，同时具备轻量、敏捷、高度自动化的特点。
云原生技术主要以容器、DevOps、微服务、分布式中间件、分布式数据库、Serverless、服务网格、不可变基础设施、声明式API、开放应用模型（OAM）等技术为核心，能够实现业务应用与基础设施的解耦，被认为是新一代云计算的“操作系统”。
金融机构采用云原生技术，并不是将应用上公有云，而是将金融对安全合规、交易强一致性、容灾多活、全链路业务风险管理等各方面行业要求与云原生技术深度融合，发展为一套既符合金融行业标准，又具备云原生技术优势的“金融级云原生架构”。
（二）银行核心系统转型能力需求
对金融核心来说，不论未来金融服务的形态如何演变，对“灵活性、易扩展、高并发、标准化组件、低成本、可靠在线服务”的追求是不变的。我们从业务、工程和技术的角度，总结了云原生分布式核心应对“不变”的能力，并针对每项能力拆解出十二项支撑能力，再对这十二项支撑能力归纳分层，形成云原生分布式核心建设的五层十二大能力体系，如下图所示：
（三）支撑核心转型的五层十二大能力体系
第一层：业务领域建模
充分考虑云原生应用的特点，使用领域建模及管理平台，把建模变得简单、敏捷、易落地，并通过平台实现建模资产的保鲜。具体来说，简化建模过程；采用建模平台，管理模型资产；运用低代码技术，落地模型。
一是基于银行同业已有实践敏捷建模，而非投入大量资源进行长周期建模；二是通过建模平台实现成果保鲜，持续为业务迭代，而非核心系统建完之后束之高阁，逐步与系统演进结果脱节；三是建模成果能够借助建模平台、结合云原生技术快速落地。
第二层：应用架构集成
应用架构集成层承接业务领域建模成果，将核心系统按照业务领域建模体系整体规划，形成可供全行IT系统复用的业务中台能力，生产各业务系统必需的业务组件；通过服务治理与组合的低代码能力，快速支撑业务创新；基于服务网格实现异构系统集成，为传统应用、迁移到云原生分布式架构下的应用互通提供技术保障。即，应用架构集成层主要由应用架构中台化、服务治理与组合、异构应用集成三大能力支撑。
在应用架构层面，云原生分布式核心与传统“瘦核心”、分布式核心重大区别是：一、不是简单的将核心系统按照业务条线划分为客户、存款、贷款等应用，采用分布式技术重新实现一遍，导致很多公共能力如产品管理、合约管理等应用都需要重复建设，数据层面不互通；二、是将核心系统按照业务领域建模体系进行整体规划设计，形成可供全行IT系统复用的业务中台能力，提供业务构件，并通过服务运营与编排，使用业务构件快速进行业务创新。
第三层：应用系统建设
提供标准化生产线，屏蔽复杂的云原生技术细节，规范云原生应用开发标准，包括异构应用集成、统一开发体系、开发运维一体化三大支撑能力。
应重点考虑以下三方面：一是统一ISV开发技术栈，避免技术管理失控；二是统一、易用的开发平台与框架，简化和规范化应用开发；三是全流程覆盖的DevOps体系，涵盖需求结构化管理、代码版本与分支管理、质量管控与度量、自动化编译打包与部署等方面。
第四层：基础软件设施
提供在苛刻金融场景中久经考验的基础软件设施和架构体系，涵盖运行时和运维时所需的各项能力，包括异地多活单元化架构、分布式服务、分布式数据、高可用运维等能力。
应关注以下三点：一是采用充分磨合与验证过的中间件体系，不要在应用系统开发阶段还需要修修补补；二是采用满足技术自研与容灾需求的分布式数据库，能真正做到可切换、敢切换；三是具有异地多活单元化能力。不只是架构设计，中间件、数据库和运维体系都要有单元化支撑能力。
第五层：基础资源设施
具有高度的开放性和弹性扩展能力，灵活适配、稳定管理不同类型的基础设施，为核心系统的自主掌控和降本增效提供无限可能。
应重点考虑以下两点：一、IaaS层能够真正做到按需快速交付，避免复杂又漫长的申请、审批和采购流程；二、安全稳妥的推进自研技术能力建设，确保核心系统的业务连续性。
（四）基于能力体系打造的金融级云原生工场
基于对云原生分布式核心建设的五层十二大能力分析，我们认为需要一整套端到端的能力体系，覆盖从业务建模、架构设计到系统建设，再到系统运行和运维的全流程。同时，这套能力体系还需具备明确的实施工艺和高度的自动化能力，从而形成可标准化、规模化、高效的工场化生产模式。我们称为“金融级云原生工场”模式。
金融级云原生工场整体上包含以下几部分：一是设计车间。通过业务领域建模将业务需求转化为IT能力，并充分考虑云原生应用的特点，使用领域建模及管理平台，把建模过程变得简单、敏捷，让建模成果易落地。二是原材料，即功能完备的组件与连接器。具体来说，核心引擎通过中台化能力中心，承接业务领域建模成果，为生产业务系统提供完备的业务组件。服务治理与集成作为连接器，集成各业务组件进行服务组合，支撑业务快速创新。服务网格集成多种技术栈的新老系统，为应用互联互通提供保障能力。三是标准化生产线。通过企业级应用开发和架构治理平台、企业级一站式DevOps平台，屏蔽复杂的云原生技术细节，提供低代码编排生产能力，助力金融机构和ISV高效开发业务应用。四是运行底座。坚实的技术底座，涵盖充分磨合的PaaS、IaaS、单元化架构和高可用运维体系，为云原生分布式核心的稳定运行奠定坚实的基础，并基于单元化架构和一云多芯，满足金融机构自研技术需求。
四、金融核心转型的建设模式与实施路径
我们总结出四阶段五层的建设模式和三条重点实施路径，并着重介绍在线迁移与双核心并行方案。
（一）四阶段五层建设模式
综合国内金融行业核心领域的相关实践，分为四个阶段，即轻咨询期、平台能力建设期、云原生/分布式设计验证期、规模化重构或建设期；在技术能力、工程能力、业务能力上可以分为五个层次，即基础资源设施、基础软件设施、应用系统建设、应用架构集成、业务领域建模，横纵结合形成四阶段五层建设模式。
（二）三条重点实施路径
采用重构模式的，多是大型国有银行、股份制银行，对业务架构和技术架构并行改造；一些银行采用平行迁移模式，保持原有系统业务逻辑和流程不变，仅通过选用分布式数据库来满足底层海量数据要求；中小银行核心建设，还可以采用SaaS化批量模式。
1.重构模式
银行核心系统的重构不仅是互联网技术改造，更是自身服务模式和服务思维的再造。从流程银行转向数字银行，从产品为中心到客户为中心，从做功能转向做场景，从做渠道转向做平台，包括业务重构和技术重构两部分。
业务重构，根据业界领先理论和最佳实践建立企业级业务模型。改造以已有业务流程、数据、产品为基础，纳入待实现的业务需求，形成模型驱动的核心业务架构体系。
传统的建模方式，需要耗费大量人力和资源，且建设周期长，往往全行级建模花了数年时间后，整个格局、环境、战略又发生了变化。敏捷、中台化、领域化建模的理念进入大家的视野。
技术重构方面，需要一套可伸缩、高可用的分布式金融技术平台作为支撑，包括DevOps平台、分布式中间件平台、运维保障平台三部分。DevOps平台能提高核心应用开发上线的效率；分布式中间件平台为金融机构提供兼备应用分布式和数据分布式能力；运维保障平台主要承载核心业务系统高可用应急管理功能。
一般来说，企业需要借助大量外部技术力量与伙伴一起完成技术重构。我们建议在建设过程中配套相匹配的工场、流水线、实施工艺等，以降低整体设计、开发、部署、运营、运维的难度。
2.平行迁移模式
平行迁移模式实施的原则是对业务不产生影响，业务流程不变、业务功能不变、应用处理逻辑不变、与外围系统接口不变、数据逻辑模型不变，可以用较小的技术成本解决集中式架构非功能层面带来的挑战。但从业务发展的视角来看，平行迁移模式是一个过渡状态，长远来说，最终还是要解决业务敏捷带来的挑战。
从目前的行业实践来看，有以下两种：
一是数据不动，应用下移。即数据架构不动，上层应用按照一个个模块做下移和分布式改造，同时引入分布式中间件相关技术支持交易路由、交易熔断降级、安全中心、统一配置中心等功能。
好处在于，数据体系和架构一般与业务高度关联，长期运行之后，数据体系非常复杂，牵一发动全身，回归测试等成本也非常高。不动数据的模式就相对简单了。它的弊端在于，整体架构没有太多变化、转型不彻底，数据架构容易造成业务敏捷、性能上的瓶颈。开发人员通常需要花费70%的精力在代码的性能结构优化上，无暇应对新业务应用的开发。
二是应用不动，数据下移。通过分布式数据技术来解决数据一致性问题，辅以少量人工完成主机核心应用程序改造，或者本身已经在X86虚拟机等集中式架构下，通过接口改造、适配来对接分布式数据库体系，对底层的分布式技术、云原生数据库技术要求非常高。
好处在于，底层的交易瓶颈比较容易解除，即数据一致性挑战。弊端在于，对分布式数据库的技术要求、成熟度要求太高，可供选择的技术供应商不多。同时还无法做到业务敏捷。
3.SaaS化批量模式
相比传统集中式架构，云原生分布式核心建设对技术积累、人员能力的要求更高。相比有自研能力的大中型银行，中小银行在研发资源有限的情况下，为避免投入大量时间、资源做核心重构，还存在另一条路线，即金融核心SaaS化批量模式。
金融核心SaaS基于云原生架构研发，经过落地验证后逐步标准化，最终走上SaaS化。具体来说，SaaS化批量模式指利用SaaS产品提供的标准化组件、OpenAPI开放应用程序接口，采用低代码、服务编排快速实现业务敏捷，通过服务网格、Serverless等技术将非功能的需求下移，保障系统的高可用、可扩展、可灰度、可观测。
选择SaaS化的金融核心，开拓了核心下移的“批量模式”，也是面向云原生未来的架构。
（三）在线迁移与双核心并行
如何在保障安全可控的基础上完成新老核心的切换。金融机构出于人员、成本、风险等因素考虑，账务核心往往会采用按模块、按机构分批迁移的策略。于是，在投产期会存在双核心并行的情况，会对银行服务的连续性造成影响。
传统做法是在投产之前做大量的功能测试、迁移演练、旁路验证等，但这些并不能完全呈现生产环境的实际运行情况。同时，项目周期长、压力大。核心下移是持久战，需要有阶段性的成果给团队激励。
阿里云提出云原生分布式核心迁移的推荐策略，即在按模块、按机构分批迁移的基础上，将迁移颗粒度进一步缩小到按单客户、按单账户，把迁移风险控制在可接受的范围内。同时，整个迁移过程全部实时在线完成，包括从旧核心的数据迁出、新核心的数据迁入，保障数据一致性。整个核心迁移期间，银行不间断对外提供服务、客户对迁移过程无感知。
迁移顺序可以按照“先内后外”“先简单后复杂”的策略进行。“先内后外”指的是先银行内部客户再外部客户，“先简单后复杂”则可以基于大数据分析客户交易习惯先迁移简单模块。
要达到双核心并行以及在线平滑迁移的效果，迁移平台的能力建设至关重要：一是全局路由模块实现新老核心数据识别和路由转发，新核心采用单元化架构，要同步考虑单元路由；二是迁移管控平台对数据迁出、转换、迁入等迁移步骤进行统一调度，并保障数据迁移一致性；三是新老核心并行期对外照常提供服务，减少系统间集成的影响。让核心系统从集中式架构平稳、有序过渡到云原生架构。
五、核心云原生分布式转型的经验总结
我们归纳出金融核心转型的一些共识和通用的标准，供行业参考：
（一）第三代云原生分布式核心的价值体现
金融核心云原生分布式核心，首先是技术自研，100%满足国家相关要求；其次，运维成本能降低400%。云原生架构能基于相对廉价的PC服务器构建，在同等处理能力下，分布式架构的单位运行成本大幅度降低，年均运行维护成本是大型机的17%；第三，业务敏捷，平均交付周期能缩短40%以上；第四，弹性扩展，完全线性，能满足中国特有的“春节高峰”，以及每年20%以上的业务增长需求；第五，下一代异地多活架构，RPO=0，RTO<1分钟。基于云原生的单元化异地多活架构，以及分布式中间件、分布式数据库、云原生分布式框架，可以构建超过“三地五中心”的全活多活架构，故障恢复后不丢数据，故障恢复时间在1分钟以内。
（二）第三代云原生分布式核心的关键标准
云原生第三代核心有一些关键标准，我们打造了云原生工场模式，将这些标准与规范融入自动化流水线，并采用端到端的实施工艺。
这些关键标准有：1、云原生，是应用架构演进、降本增效的必然趋势和要求；2、异地多活单元化，是架构在线升级的关键企业级架构；3、中台化，是实现业务敏捷、弹性，应对未知挑战的关键；4、数字化，是面向未来金融基础设施的关键设计；5、技术自研，是实现金融安全的必要保障。
（三）核心系统建设的经验总结
实践中，我们总结出一些经验与教训：
一是做好整体规划与设计。核心系统下移是个复杂工程，在启动之前需要通过咨询，为后期建设做好统筹，避免盲目建设。
二是打通技术与业务，让云原生分布式发挥真正价值，需要参与者对于业务及底层云原生平台技术都非常熟悉。传统上应用的归应用开发商，技术的归技术平台供应商的分离建设模式，已经无法满足转型的需求。我们通过金融级云原生工场模式联通技术与业务的鸿沟。
三是技术运维的挑战。传统集中式架构的运维保障通常由厂商和生态来进行，而云原生分布式体系下，整体需要运维的架构复杂度远超以往，需要更多的将运维保障任务交给自动化、体系化的技术风险防控体系。技术风险防控体系的设计与建设，需要在早期同步开展。
四是复杂项目的组织管理模式迭代。核心系统的建设周期往往比较长，大型金融机构会在20个月以上，参与方众多。加上云原生分布式、中台化、业务敏捷驱动的新型架构，对项目的组织形式、具体工作划分有不同的要求。整个项目工程管理需要采用新的组织理念，通过数字化的工具来进行组织协调，更高效、高质量的完成落地交付。
要实现金融核心云原生分布式转型，关键在于打造一套新的云原生数字化生产线、配套设计工艺以及稳固的云原生分布式基础设施，用综合的视角去变革那些最难的部分，从更高的视角去构建智能化内核能力无处不在的新平台，重塑数字金融的商业价值。
