近期读到腾讯发布的《商业银行核心系统分布式转型白皮书》，书中介绍了银行核心分布式改造的架构路线、关键技术及最佳实践等内容。结合自己之前在金融业的一些体验，感觉总结整理的不错，特分享出来。文中的部分内容摘自此白皮书。
1. 背景：分布式选择成为必然
无论从业务还是技术角度，银行业都正在完成从“集中式”到“分布式”的转型。其背后是有必然性的，可概括为以下几个方面：
❖ 业务发展需求
随着互联网技术和移动支付的快速发展，银行的业务形态和模式发生了巨大变化。传统的集中化核心系统往往难以满足快速应对市场变化、实时处理大量交易的要求，因此需要进行分布式核心改造。
❖ 系统性能瓶颈
传统的集中化核心系统往往存在系统性能瓶颈，无法满足大规模用户同时在线交易、高频交易的需求。通过分布式核心改造，可以将系统对各项业务进行分拆和扩展，提高系统的并发处理能力和吞吐量。
❖ 系统可扩展性不足
传统的集中化核心系统往往难以实现快速灵活的业务拓展和系统扩展。通过分布式核心改造，可以将不同的业务模块分布在不同的服务器上，实现业务功能的独立扩展，提高系统的可扩展性和灵活性。
❖ 系统稳定性和安全性
传统的集中化核心系统往往存在单点故障风险，一旦发生故障或被攻击，将对银行的正常运营造成严重影响。通过分布式核心改造，可以将系统分布在多个服务器上，实现故障隔离和负载均衡，提高系统的稳定性和安全性。
❖ 技术创新驱动
现代分布式技术和云计算技术的快速发展为银行分布式核心改造提供了技术支持。通过采用分布式数据库、分布式计算等技术手段，可以实现银行业务的高效处理和大规模扩展，进而提升银行的竞争力和用户体验。
2. 方法：建设模式与整体架构
1).建设模式
银行核心分布式改造，可分为两种模式：一是技术平移，二是规划重建。
- 技术平移
这是科技部门内部能够闭环的模式，在保持功能基本不变的情况下，将应用迁移到分布式平台或将应用适配到国产数据库或云平台上。技术平移首先要确定平移目标，如平移到国产化的云、操作系统、数据库、中间件等等。其次是要确定平移的路径，比如优先使用产品、定价等模块做试点，再平移核算，形成完善的平移经验和工序后，最后是进行存贷模块的平移。
- 规划重建
这是比较彻底的一种模式，需要联合业务部门，结合全行业务发展战略，整合业务需求，重新设计建设新一代核心系统。规划重建整体上比技术平移更具挑战，不同银行也都根据自身特点走出一条适合自己道路。
业务建模
业务建模是最早由建行联合众多业内专家实践产生的需求分析与统一建模的方法论，随后在几家国有大行的新核心建设中逐步丰富延展。IT工艺是与之配套的新核心建设方法论，其能承接业务建模的产出，用业务模型指导微服务模型落地，用识别、定义、分解等标准工序拆解复杂架构，最终基于构件实现松耦合的组装和编排，在复杂项目设计与建设中发挥了重要作用。
2).整体架构
图片
从核心系统整体架构上，可分为七大部分内容。
- 底层是IaaS云平台，中间是PaaS云原生平台，上层是SaaS核心应用领域，左侧为研发效能体系和混沌测试体系，右侧为智能运维体系和安全体系。上图七块内容形成新核心所需的整体能力框架。
- SaaS层包括了银行核心系统的应用域，如：存贷、支付结算、银行卡、核算及公共服务等。所需的能力中心和7*24等公共机制。分布式技术组件用于封装分布式底层技术，负责对上层应用模块屏蔽产品差异与技术复杂度，同时连接着下层PaaS平台的各项能力。其中，一部分与云厂商的产品存在一定重叠，如：单元化能力组件、分布式事务、聚合查询组件、服务调用代理等。在实际落地过程中需要明确双方边界，进行有效的整合与联动形成一体化的、稳定的技术平台底座。
- PaaS层以云原生容器平台、分布式数据库、分布式消息队列、分布式缓存、微服务平台等中间件为主。
- IaaS层主要包括了云平台的计算、存储、网络、资源编排、多云管理和安全能力。
- 研发效能体系中包括了传统的Devops体系，同时还集成了项目管理和质量管控体系。以需求为抓手，贯穿设计、开发、测试、安全、发布、生产全生命周期管理，每个环节形成有效的反馈机制，确保在每一轮迭代都能有效量化生产数据，实现精益管理。
3. 路线：微服务与单元化
对于核心提供的分布式改造，有两种技术路线选择：一是微服务、二是单元化。微服务和单元化之间并不是一个包含关系，而是一种加强关系：单元化是微服务架构在宏观架构层面的增强，而微服务是单元化架构在微观机制层面的支撑。我们可以从多方面对比两者的差异。
图片
在若干核心的设计要点上，两者均存在一些差异，可以从下面六个方面进行对比。
- 数据切分策略上，需考虑几个问题：一是按什么维度进行何种拆分，二是采用什么存储方式，三是如何进行扩容，四是需处理那些数据。
- 技术架构标准上，需考虑几个问题：一是交易调用处理策略，二是分布式事务策略，三是聚合查询策略，四是灰度发布策略。
- 服务实现策略上，需考虑几个问题：一是服务颗粒度的选择，二是落地实施工艺，三是技术组件。
- 业务连续性上，需考虑高可用架构及容灾切换策略。
- 研发效能上，将研发、测试、发布环节打通，形成一体化的持续跟踪、反馈、提升体系。
- 分布式运维上，一改传统运维方式，突出发现隔离能力，并可引入大数据与AI提高分布式下的分析预测能力。
图片
4. 路线：微服务架构
1).基本概念
微服务架构是一种软件架构风格，其中应用程序被拆分为一组小型、松耦合的、自治的服务。每个服务都可以独立地进行开发、部署和扩展，并通过轻量级的通信机制（如HTTP、消息队列等）进行互相通信。微服务架构的核心原则是将复杂的单体应用程序拆分成更小、更可管理的部件，每个部件专注于完成一个特定的业务功能。这些服务旨在可以独立开发、测试、部署和扩展，以满足不同的需求和快速变化的业务要求。
❖ 架构特点
- 松耦合：每个服务都是独立的，可以独立部署和扩展，没有共享的数据库或技术限制。
- 独立自治：每个服务具有自己的代码库、数据库和团队，可以独立地进行开发和管理。
- 服务边界明确：每个服务都定义了明确的业务边界，可以专注于解决特定的业务问题。
- 分布式：不同的服务可以运行在不同的服务器或容器中，并通过网络进行通信。
- 弹性和可伸缩性：由于每个服务都是独立的，可以根据需求进行单独的扩展，提高系统整体的弹性和可伸缩性。
- 高可用性：通过服务复制和负载均衡等机制，提高系统的可用性，一个服务的故障不会影响整个系统的正常运行。
❖ 银行微服务特点
微服务架构可以带来像应用解耦、独立自治等诸多优势，但微服务并没有解决所有问题，如服务拆分后的服务编排问题、分布式事务问题，或者数据拆分后的聚合查询问题等。在银行核心如此严谨的领域，微服务的使用一定要综合考虑各种场景，充分听取多方意见，从中找到平衡点。如果一味从理论角度推进，往往得不偿失。考虑到微服务颗粒过细所带来的整体复杂度，通常在设计时会按照标准的业务领域进行组件的设计和开发，但在发布时会将多个相关的组件进行合并发布。以此来减少组件间的调用链路，提供系统稳定性和性能，简化运维复杂度，包括减少分布式事务的产生。
2).设计要点
❖ 数据切分策略
- 维度字段：数据切分维度主要以客户号Hash和List两种方式为主，可分别从分布式事务出现概率、数据分布均匀程度、访问压力的均匀程度、扩容的难易度等几个维度结合核心业务特征来确定。客户号并未唯一选择，只是在核心业务场景中单客户的交易场景居多，为避免产生分布式事务所以大多以客户号作为数据分片的维度。当然也有按地域和机构的维度来切分数据的，这种切分方式一定程度上解决了核心场景中非客户维度的查询问题，但会导致潜在的数据分布不均以及访问不均的风险。
- 聚合查询：针对数据分散之后带来的聚合查询问题，业界有不同的技术手段来处理，比如把相关数据同步到聚合库或搜索引擎，或者采用分布式数据库产品自带的AP引擎进行处理。
- 扩容问题：设计切分策略时需要同步考虑未来的扩容策略，针对微服务架构路线，可直接采用分布式数据库自身的扩容能力实现数据层的扩容。无论用哪种方案原则都是在扩容时要尽可能的减少数据迁移的规模。在银行核心场景中，我们建议充分评估未来业务增长量，结合单个物理分片能承载的业务量基线，评估能满足未来5年的规模容量，尽可能避免数据迁移场景的产生。
❖ 服务交互方式
技术标准主要以SpringCloud微服务体系的标准为主，服务注册和发现模型是目前分布式系统最主流的模块交互模式。应用实例在启动时均会向注册中心提交自身信息，而注册中心会维护一个全量的服务目录，并下推到所有消费方。服务消费方通过微服务提供的负载均衡组件和服务调用组件实现对目标服务的寻址与点对点的调用能力。这个过程中，注册中心作为非关键交易路径提供服务，提升了该模型的整体稳定性。负载均衡算法需要支持主流的几种策略，包括：随机、轮询、最小连接数等。
❖ 分布式事务
分布式事务是集中式系统微服务化之后不可避免的问题，在金融领域显得格外重要。然而目前为止在微服务体系中尚未统一分布式事务的处理标准。其产生的原因不同，对应也有不同解法。
图片
分布式事务最好的处理方式是“恰好不用解决”。即通过合理的应用规划和数据切分来有效地避免分布式事务的产生。所有的分布式事务处理机制都会带来不同程度的损耗，无论是在应用侧实现还是数据库侧实现。在数据库性能和容量允许的情况下，也会考虑将相关微服务组件对应的数据库进行合并，来减少因为数据拆分而产生的分布式事务，应用层也会考虑将关联的服务组件合并成一个微服务组件进行发布，以减少因为应用拆分而产生的分布式事务。
❖ 扩容策略
扩容可分为应用扩容与数据库扩容。在微服务架构下，因为有注册中心的存在，新的应用实例在启动时会自动注册到注册中心，注册中心会更新服务目录并推送到服务消费方，随后消费方在新的服务目录中负载时就会将一部分流量随机到新的实例上，以此来实现应用集群的扩容。对于数据库扩容，则基本依托分布式数据库能力实现。
❖ 高可用策略
在同城两个数据中心中，标准架构中数据库采用分布式实例，对上层应用屏蔽底层数据库结构，应用只需连接本单元的数据库代理进行访问。数据主副本都在主中心部署，应用在两个中心中分别部署。
图片
流量通过顶层接入，经过 DNS 到中心内负载均衡服务再到微服务网关，经过鉴权、限流等一些列检测后进到微服务业务集群，处理时两个中心的应用都连接本机房的数据库代理进行访问数据，但在数据库代理这一层会根据路由算法计算客户所在的数据主备位置，并发起转发，这个过程中同城机房的请求将出现横向流量访问主中心的数据主本，这个过程应用是不可见的，因为分布式数据库对上屏蔽了底层的数据库架构和数据路由。以此实现同城两个数据中心同时处理业务请求的双活架构。当下基础设施在同城之间的数据传输和稳定性已经非常成熟，对于大多数系统组建这样的分布式架构是完全没有问题的。只有在两个机房间超过一定距离，或延时过高时才需要考虑横向流量的治理问题，那时单元化架构是一种好的解决方案。
异地容灾上，由于在分布式应用系统中，应用的无状态属性使得扩容和迁移都变得方便许多，我们只需要考虑有状态服务，站在核心系统视角主要是数据库。数据库的 RTO 和 RPO 是整个核心做异地切换的主要关键指标。在大型复杂的银行核心系统中，会涉及到多个业务数据库，且每个数据库下又会有多个数据分片，由于异地间的数据传输是异步模式，其切换过程比同城切换要复杂许多，会涉及网络状况的判断，数据补偿与校验等。
图片
当数据库切换完成后，容灾中心的应用集群连到切换后的数据库，随后启动内部校验，确认无误后，在全局负载均衡服务（GSLB）中将流量指向异地的容灾中心，实现地域级故障的业务连续性保障能力。整体异地容灾切换的流程极为复杂，且与客户的实际运维环境有关。
5. 路线：单元化架构
1).基本概念
单元化，通过把一部分计算资源和一部分数据资源进行逻辑上的绑定，形成一个标准化的处理单元。我们将一个大型系统拆解成多个标准的处理单元，每个处理单元具备完整的业务能力，但只处理全量数据中的一部分，简单理解一个单元就相当于一个小分行。单元化架构因其学习成本和实施成本较高，比较适合体量相对较大或有异地多活规划的银行，需要结合具体银行客户在账户数、预算、自主研发能力、业务连续性要求、异地多活规划等方面来综合考虑。单元化架构是银行核心分布式转型的一种重要方向，但不是唯一的技术方向。
单元化与微服务区别
标准微服务架构默认不对跨中心流量进行治理，其对双活两个机房之间的距离和延时有一定要求。假设两个异地机房，没有单元化的微服务架构中，应用在访问数据库时会存在异地间的数据访问，因为计算层的负载是无状态的，而数据的主本是固定在某一机房的，应用跨异地访问数据时，其稳定性和时延是无法保证核心系统正常运行的，也就是微服务架构在不做改进的情况下较难适应未来异地多活的场景。这是标准微服务架构和单元化架构之间较大的区别之一。
2).设计要点
❖ 数据切分策略
单元化架构下，数据分片的维度、分布规则都与微服务架构相似，主要以客户号 Hash 和 List 两种方式为主。同样需要考虑分布式事务出现概率、数据分布均匀程度、访问压力的均匀程度、扩容的难易度等几个方面。不同的是单元化架构多以应用侧主导数据分片策略及路由策略。这种方式能摆脱对分布式数据库或中间件产品的依赖，灵活可控是单元化架构的重要优势。
❖ 服务交互方式
单元化架构下交易处理策略以注册发现体系为基础，但在调用与负载时需要遵循以单元维度和就近调用原则，即：所有路由均需要判断单元维度，识别单元内调用还是跨单元调用，对于相同服务的调用顺序为：优先单元内调用，其次本中心调用，最后同城中心调用。
单元化架构会要求所有应用在往注册中心注册时需要带上自身所在单元的标记信息，同时微服务之间在调用时需要先根据单元标记过滤目标服务的实例，确保在指定单元的服务实例之间进行负载均衡算法。这种根据单元标记进行路由和目标寻址的逻辑在标准微服务架构中是不存在的。
❖ 分布式事务
同“微服务”的处理机制一致
❖ 扩容策略
在分布式系统中，应用的无状态化让计算资源的扩容变得容易，但在银行核心场景中就显得不规范和不受控，而单元化架构则提供了一种分布式系统下计算和数据资源扩容的标准规范。针对数据层的扩容，在单元化架构中会将全量数据分为若干份，每一份称为一个逻辑分片，然后建立逻辑分片到物理分片和单元的映射关系。扩容时，首先加入新的物理分片，再将指定逻辑分片迁移到新的物理分片中，最后更新逻辑分片到物理分片的映射关系。这个扩容的逻辑通常是由应用侧结合数据迁移工具来做定制化开发，也可以通过分布式数据库的扩容功能实现。在核心场景中，原则上要尽可能减少数据层的扩容，其次是扩容时要尽可能减少数据迁移的规模。
图片
举例：假设以客户维度切分全量数据，每个逻辑分片中存放着1万客户数据。现在有两个单元，每个单元中各一个物理分片，每个物理分片中有32个逻辑分片，也就是一个单元中有32万客户数据。其中1号逻辑分片原本是在1单元的1号物理分片中，由于识别到其为热点分片，现要将其迁移至一个新的3号单元的3号物理分片。那么首先要将1号逻辑分片中的所有数据迁移至3号物理分片，再修改1号逻辑分片到3号物理分片的映射关系以及1号逻辑分片到3号单元的映射关系。当更新生效后，1号逻辑分片中的客户再发起交易时，网关就会将其路由到3号单元，其中的应用会从3号物理分片中获取数据进行处理。通过这种方式解决扩容问题。
❖ 高可用策略
在单元化下的业务连续性，通过设计“互备单元表”来建立两个单元间的互备关系。当其中一方出现故障时，通过更新状态，来指向其互备单元ID从而进行路由调整。实现单元间互备要求单元的数据库副本需要放置在对方单元中，当发生切换时，数据库会将对方单元下的副本调整为主本。
图片
如图，请求通过全局负载服务进入到两个机房，机房内部通过负载均衡服务转发到本中心的微服务网关集群，在网关这一层识别请求对应的单元和路由信息，转发到指定单元处理。当单元1发生故障时，停用单元1的流量，并获取单元1对应的互备单元信息（单元5），等待数据库主备切换完成，更新全局路由将流量转发至单元5。此时单元5除了承载自身业务流量还会承载单元1的业务流量。单元切换的指标绝大部分情况下取决于数据库的RPO和RTO。回切过程类似，先关停单元1的流量，执行主备切换，让主库回到原单元1下，调整网关层路由回到单元1。
与微服务的区别
单元化架构在同城高可用设计上与标准微服务架构有所不同，微服务架构因为没有单元概念，在故障发生时是直接将整个数据库切到同城，再切换GSLB的流量。而单元化架构则是以单元维度进行切换，虽然最终效果是一样的，但是内部运作机制不同，切换控制的颗粒度也不同。
3).示例：腾讯银行单元化架构
腾讯单元化架构是一种针对银行分布式核心系统技术架构的体系化、分层次、分领域的架构思想。接入层负责接收流量、识别流量、转发流量。识别后的流量被转发至应用层对应单元处理，单元默认按照客户维度拆分，单客户交易实现单元内闭环处理。跨客户交易存在一定比例的跨单元协同处理。数据默认被分为64份，被均匀放置在若干个单元内。可通过灰度机制将指定标签的客户放置在灰度单元实现生产灰度运行或验证。其中：接入单元(ADU)负责接入接出能力、标准处理单元(SDU)负责业务处理能力、本地单元(LDU)和同城单元(RDU)分别用于提供单AZ共享服务能力和同城共享服务能力、以及在异地多活架构中会涉及的全局类型服务则由全局单元(GDU)提供。
