金磐石：银行核心业务系统如何应用分布式架构

相对于主机集中式架构，以X86 和云计算为基础、以数据切分为特征的现代 分布式架构 在扩展性、低成本、降低运行风险等方面的优势明显，已经成为主流的联机交易系统架构方案。本文针对分布式架构在银行核心业务系统中的应用，分享了分库分表、读写分离数据共享和访问性能优化、高效运维等关键技术方案设计要点。敬请阅读。

---

分布式架构概念

各大型国有 商业银行 经过十多年的发展，都已经实现了数据集中，而且，随着客户服务的不断发展和提升，各家银行核心业务系统的账户量和交易量都已经达到了超大规模，系统的处理能力和性能以及可用性、可靠性、数据一致性、业务连续性等要求极高。在这个过程中，集中式架构发挥了重要作用，各家银行的核心系统基本都构建在集中式架构之上，尤其以大型主机架构为代表。集中式架构下，一般采用纵向扩展的方式即通过增加单机的资源配置来提升系统的处理能力。通过硬件设备和基础软件的集群机制来提升系统的可用性。

本文谈及的分布式架构是指近年来兴起于互联网公司的一种现代分布式架构。分布式架构以X86和云计算为基础、以数据切分（Sharding）、读写分离为特征，采用横向扩展的方式，通过增加服务器的数量，提升系统的处理能力，每个节点都是一个可独立运行的单元，失效时也不会影响应用整体的可用性。另外，系统可以分散到多个节点运行，降低了对单节点的处理能力和可靠性要求，给使用X86服务器替代高性能的主机和小型机服务器创造了条件，可大大降低基础设施的投入成本。

长期以来，银行核心业务系统一直是安全、稳定、可靠的典范。但采用集中式架构的核心业务系统建设费用和运营成本昂贵，随着银行业竞争的加剧，特别是面对采用了低成本分布式架构技术的互联网公司向金融领域的渗透，各大银行都在探索主机迁移方案以节约成本。更大的挑战是随着银行经营转型和业务拓展，核心业务系统的规模急剧扩大，支持的交易模式也更加复杂，核心业务系统处理能力的瓶颈逐渐凸显，需要采取有效措施降低主机负荷，控制运行风险。因此，将分布式架构应用于核心业务系统必然成为各大银行应对上述双重压力的一种选择。

困难和挑战

由于分布式架构采用了单体处理能力较小、可靠性较低的常规服务器，与主机或小型机相比存在一些弱点，要将分布式架构应用到银行核心业务系统中，将面临以下困难和挑战。

1.并发处理能力。 采用分布式架构的银行核心业务系统一般采用两层结构，即应用服务器层和数据库服务器层，按照SOA的设计原则，部署在应用服务器层的业务逻辑采取服务化和无状态的处理，易于实现横向扩展。而数据库服务器层采取分库分表、读写分离的策略实现处理能力的扩展，如何提高数据库服务器层的并发处理能力是分布式架构在银行核心业务系统应用面临的最大挑战。

2.可用性水平。 高可用性是银行核心业务系统最重要的运行指标。各大银行之所以仍然采用主机集中式架构构建核心业务系统，最主要的原因是开放平台比主机的可靠性要低。分布式架构下使用的X86服务器可靠性更低，由于应用服务器层采取了负载均衡及高可用设计，其总体可用性可以达到更高标准。而数据库层采用分库分表和读写分离技术后，也更有利于提高数据库总体可用性，但基础设施包括云平台及网络、存储以及复制、同步软件的可用性将成为主要挑战。    

3.交易一致性。 交易一致性是银行核心业务系统的基本要求，核心业务系统交易一致性要求远高于电商平台和其他互联网应用。交易一致性指的是数据库事务管理必须满足ACID（原子性Atomic、一致性Consistency、隔离性Isolation、持久性Durability）要求，否则将会发生交易一致性问题。由于分布式架构采取分库分表策略，导致跨库跨表的事务增多，如果采用二阶段提交（Two Phase Commit）机制来进行事务管理，则会引起性能和可用性问题，成为了影响分布式架构在银行核心业务应用的最大障碍。另一个交易一致性问题是由于分布式架构下数据采取读写分离的策略造成的。根据CAP理论：一个系统不能同时满足一致性、可用性和分区容忍性这三个要求。数据库读写分离实际上是要满足分区容忍性，所以可用性和一致性不可能同时得到满足。如何调和因读写分离带来的可用性和一致性矛盾，也是分布式架构设计必须解决的问题。

4.运维复杂度。 分布式架构下，采用大量的X86服务器来实现主机或小型机才有的处理能力和高可用性，使得系统的服务器数量急剧膨胀，应用结构和关联关系更为复杂，给运维工作带来巨大挑战。

解决方案

分布式架构的核心在于“分”，难点在于“既要能分，也要能合”。下面是分布式架构中几个关键技术方案的设计要点。

图1 分库分表概念模型

1.分库分表策略。 常见的分库分表策略包括垂直切分和水平切分。垂直切分是指从业务分析入手，将系统按照不同的业务功能，划分为一些相对独立的子系统或模块。水平切分是指按照一定的逻辑，将数据表按照分区键值进行切分，实现数据的分布式存储。

多数场景下都需要将垂直切分和水平切分联合使用，先对数据进行垂直切分，再针对场景下数据访问特征选择性地进行水平切分（如图1所示）。

2.数据分布算法。 可以使用SBF数据分布模型解决分库分表的问题（即Shar d i n g K e y分区键-DataBucket数据桶-TableFamily表族）。其核心思想是应用数据逻辑态与物理态的隔离，从请求数据识别出分区键，然后应用算法确定数据桶的编号，相同编号的数据桶形成一个表族。最后将数据桶映射为物理数据库的表，然后根据数据库的数量，将所有的表族均匀分布到各物理数据库中。

采用一致性“哈希算法”来分库分表，其核心是将要分布的数据经过计算映射到一个具有0～（232-1）的数据空间中，形成一个闭合的环形。然后将物理节点也通过“哈希算法”映射到这个环上，以顺时针方向将所有的对象存储到离自己最近的物理节点上（见图2）。

图2 使用SBF 数据分布模型解决分库分表问题

将该算法应用于核心业务系统的数据库分库分表场景下，最重要的就是让应用的数据访问模型与算法特征、数据库特征和数据库物理部署相结合，充分发挥一致性“哈希算法”的优势。

3.数据访问路由。 数据访问路由模块的功能是将数据分布算法嵌入到交易流程中，使应用能够透明地访问对应的数据库分库和分表（如图3所示）。

图3 数据访问路由模块的功能设计

首先，需要在请求接入时确定应用的分区键，输入是服务的请求数据，然后根据应用场景的不同嵌入分区键的识别逻辑，实现分区键的转换功能。转换后的分区键和计算的桶编号需要写入本交易的内存区，用于后续的分库分表处理。

其次，采用统一的应用访问数据库接口实现数据库访问层，在数据库访问层嵌入数据访问路由逻辑。核心功能包括SQL的解析和重写、多数据源管理、单库数据访问接口等，通过几个模块的协作就可以完成数据访问路由的决策、分发和执行。

4.数据重分布。 数据重分布是分库分表后的基本能力要求。重分布过程应该以最大程度地保证应用可用性为前提，避免因为重分布导致全量数据的重组。从服务视角来看，每一次的服务调用，都是针对单一的数据记录进行操作，数据表中存储的也是数据记录。基于关系型数据库进行数据重分布，最好的方式并不是通过记录，而是通过表。将重分布的颗粒度定义到表级别，可以利用数据库的导入导出工具，大大提高数据重分布的效率，降低对系统可用性的影响。

5.数据聚合。 跨库查询是分库分表模式下最为典型的应用场景，解决的思路是将查询下发到所有的数据库执行，然后再对结果集进行合并和筛选。方案主要包括并行执行调度、多分区键识别和重组、线程池管理、多数据源管理和数据访问接口、SQL解析和执行计划优化、结果集合并筛选等几个模块。

6.数据共享和访问性能优化。 对于读多写少的公共数据，可采用分布式缓存技术实现数据共享，优化访问性能。

但应用缓存也有一个问题，即缓存的数据都存储在内存中，如果出现服务器宕机和进程异常退出的情况，极有可能造成数据丢失。在应用时应该遵循以下几条原则：一是应用缓存的交易必须具有大并发量的特性，放在缓存的数据应当满足只读且使用频繁的条件；二是由于银行业务对可用性的要求，在使用缓存时要在设计时做到应用的高可用，一旦缓存出现问题，应用要能够无缝切换；三是将缓存组件整合到数据访问层，避免对整体业务逻辑的影响。

7.读写分离。 数据存在多个副本，包括一个主数据库和多个从数据库。主库负责数据更新和实时数据查询，从库负责历史和准实时的数据查询。分布式架构设计时，可从下面几个层级实现读写分离机制。

组件级：从服务的维度将历史查询和准实时查询从核心应用的主库中隔离出来，在企业级服务总线（ESB）实现组件和交易级的服务路由选择，从而在组件级实现读写分离的要求。

联机服务级：当交易请求通过ESB到核心业务系统后，在请求接入层进行数据访问路由选择，实现交易服务数据访问的读写分离。

数据访问层级：在数据访问层中实现对于SQL语句的解析和识别，如果是可以访问读库的查询功能，则可通过多数据源管理模块路由到读库访问，降低主库的处理压力。

8.可用性保证机制。 应用分库分表后，在大幅提升系统处理性能的同时，规避了大型单一集中式数据库的运行风险。可以采取以下几个可用性保证机制。

故障隔离机制：通过“SBF”数据分布模型，准确地识别数据桶编号与物理数据库的对应关系，快速地通过改变物理数据库可用性的标识，实现故障隔离。

集群架构：每个分库仍然应该保持集群架构，利用关系型数据库管理系统的高可用机制进一步提升分库的可用性水平。

数据库的灾备：可以部署灾备数据库，保证极端情况下数据库层的可用性。

9.高效运维。 建立分布式架构下的高效运维体系，在资源供给、应用部署、集中监控、故障诊断和应急处置等方面提升自动化水平，是确保分布式架构能够应用和推广的必要条件。

一是通过云平台封装标准PaaS云服务，可实现多套数据库、中间件服务的快速供给及动态伸缩，还可根据主备库配置关系，实现日常检查、一键式切换、服务启停、数据迁移、软件分发、配置管理等自动化操作。二是通过集中监控系统实现从基础设施到应用的全面事件和性能监控，采用规则引擎、可视化引擎、工作流引擎实现事件智能化分析、展现、处置及信息推送，为分布式架构下的快速故障定位、故障自愈和应急处置提供有力的保障。三是通过应用监控系统可度量组件间可用性、性能、流量等指标数据，从而实现端到端交易监控，并实时展现各组件的交易性能、组件间调用关系、追踪单笔交易路径。四是通过大数据技术实时分析系统、数据库、中间件等基础服务和应用服务的性能、容量，动态调整资源，提高资源利用率。

分布式架构转型路径

按照整体规划、分步实施、风险可控的策略，推进系统从集中式架构向分布式架构转型。

1.整体架构设计。 “新一代”架构的基本特征是企业级、组件化和面向服务，在架构分层的基础上，建设12个应用平台，承接业务架构建模成果，将115个业务组件所对应的应用组件部署在平台上，组件之间通过标准化的服务和事件驱动架构（EDA）进行交互。可以说，应用的解耦为分布式架构的采用提供了极大便利，分布式处理是“新一代”架构所具备的重要能力之一。

2.合理选用平台架构。 根据整体架构设计，我们将115个应用组件绝大多数在开放平台上部署，只保留极少的关键核心应用（如存贷款、借记卡、贷记卡等）在主机平台上。

一是对于客户积分管理这类应用，将其全部功能部署在分布式架构平台上。

二是对于客户信息这类查询交易为主的应用，将客户信息的维护操作保留在主机上，将客户信息查询下移到分布式架构平台上。三是对于对私存款与借记卡这类应用，其交易量大，数据一致性要求高，目前还很难将其全部迁移到分布式架构平台。基于读写分离的原则，将涉及客户合约、账户、介质维护类的交易保留在主机平台上；将对合约、账户、介质、以及交易明细的查询交易部署到分布式架构平台。主机和分布式平台之间的数据采用日终批量或准实时方式同步。

在组件化、SOA架构特点下，组件之间的服务调用不可避免，因主机技术特点限制，其外呼能力较弱，将此类需要组合主机上存款借记卡服务和开放平台服务的组合场景部署到分布式架构平台，通过交易一致性事中和事后机制保证业务一致性。

3.分布式架构平台研发与应用。 如本文所述，将分布式处理的一些关键技术应用在基于X86的分布式架构平台研发上，使其具备高并发、高可用、可扩展的能力。建设银行基于分布式架构的应用已经成功开发和投产，以客户积分管理应用为例，“新一代”3.2期投产后，积分管理的客户数超过6000万，账户数9000万，经过分库分表处理后，数据分布到1024套表中，每套表约存储12万左右的账户记录和相关明细数据，联机日均交易量约为1300万笔，峰值TPS约750，交易平均处理时间约60ms。

4.持续推进分布式架构平台应用。 分布式平台的应用显著提升了IT自主可控研发能力，降低了IT成本，下一步将从四个方面深化其应用：一是尝试将贷记卡这类核心应用整体迁移到开放分布式平台；二是推进主机上存款、借记卡、客户信息这类核心应用功能继续向开放分布式平台迁移；三是将一些具有“秒杀”交易特征、突发交易量大的基于小型机的集中式处理系统向x86分布式平台迁移；四是完善分布式架构灾备方案，实现分布式架构平台多活。

结语

实践证明，商业银行通过自主设计、自主研发的方式实现分布式技术的应用是可行的。银行引入分布式技术，应对互联网行业竞争，应发挥在网络资源、经营对象、信息安全及线下服务的优势，坚持以自身为主做“银行+互联网”、以开放的态度谋求合作性竞争、以“客户体验至上”为宗旨设计产品提供服务、以积极稳妥的态度推进分布式架构的建设，不断提升银行IT的管理和技术水平。

本文已标注来源和出处，版权归原作者所有，如有侵权，请联系我们。