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个月以上，参与方众多，大家往往会忽视这个长周期项目建设团队自身的组织形式与管理模式。在云原生分布式，中台化，业务敏捷驱动的这种新的核心架构方式之上，整个核心项目组的组织形式，具体工作任务划分的方式和边界，沟通交流方式这些也会有变化。这部分目前如果还按照以前集中式架构的项目组织和开展形式来运作的话，可能会有比较大的信息不对称以及摩擦，影响整体的工程效率和最后落地的实际效果。因此我们也建议整个项目工程管理和沟通模式需要采用新的组织理念，采用数字化的工具体系来进行组织协调，更高效更高质量的完成实际落地交付上线。最后，如果需要用几句话来进行总结的话，那就是“集中式架构，已经不止是一种技术架构模式，而成为一种根深蒂固的思维习惯和设计理念。当它成为潜规则而影响了创新时，我们往往身在此山中而不为所知。朝着云原生分布式转型的过程中，打破这种集中式架构的思维惯性和习惯（设计、开发、运维），这些才是最难改变的”“从金融行业的角度而言，要实现核心的云原生分布式转型的关键在于打造一套新的云原生数字化流水生产线、配套设计工艺以及稳固的云原生分布式基础设施，尝试用综合的视角去改变那些最难改变的部分”。
