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产品集成国产数据库采用该路线的银行范围：部分中小城商/农商、民营银行、外资银行
