在银行的IT建设历程中，尤其是中大行，大多都基于大型机和小型机来构建核心系统。随着银行业务的快速发展，这样的系统对业务的支持越来越举步维艰，主要体现在以下四个方面：
首先是难以支持银行快速发展的业务。随着国内电商、互联网支付、手机支付的迅猛发展，银行的交易量出现指数级的增长。比如我们的某银行客户，当前每秒的交易量峰值在一万多左右，预计在未来几年会逐渐增长到每秒6万笔交易，而且后续还会继续增长。在这种情况下，基于大型机的集中式架构，单纯靠硬件的升配，已经无法支持业务的持续增长。第二是难以匹配银行系统的迭代更新速度。原有的基于大型机的胖核心架构，迭代周期往往在数月甚至半年。但随着银行间、以及银行与互联网金融企业之间的竞争加剧，银行迫切需要快速推出新业务进行创新，他们也希望能够像互联网公司那样，能够按周级进行快速迭代，快速响应业务需求。第三是系统风险。银行业迫切需要做到软件及硬件的自主可控。第四是生态封闭。大型机技术发展慢、人才难招。现在再去外面招一个懂IBM大型机的人已经很难了。因此，在国家现有政策的引导下，各大银行最近几年都在做一个事情：把原有的核心架构从大型机下移到传统的通用服务器架构上，并建设一套自主可控的新技术体系，简称核心系统下移。在进一步理解银行系统之前，我们先了解下银行客户的业务体量、业务需求以及核心系统对业务支持情况。以一个国有大行来举例：它的客户量在5-7亿，有10-20亿账户，在全国有2-4万个网点。从每秒峰值交易量来看，约为每秒5-8万笔交易。具体到数据库层，支持以上业务还需要联机交易系统，例如存贷汇业务。数据库层最大的表有百亿级记录数，TPS达到百万级。此外，统一查询业务要求支持近十年交易明细的查询，即万亿级的查询记录数。即使放到互联网公司用的通用服务器，也是需要上千台服务器才能支撑相关业务的开展。
通过以上的介绍，大家可以发现，银行客户的业务体量和数据量已经达到了大型互联网公司的量级。如果想把这个系统从大型机下移到通用服务器架构，那么原有的集中式架构肯定是无法满足的，必须像互联网公司一样采用分布式架构。因为银行有和大型互联网公司相近的业务体量，因此在技术体系上，也借鉴了互联网公司的技术体系。
从IaaS层来看，银行采用了X86、ARM架构的通用服务器，也用到了混合云技术，大量使用了虚拟机与容器服务。
在PaaS层，银行使用了大量的分布式系统，如开源的微服务框架（例如SpringCloud），以及开源的或者商业的数据库，包括分布式/单机/关系型/缓存型的数据库，以及日志数据库ES、时序数据库等。在中间件层，也用到了大量的开源的或者基于开源改造后的组件，例如消息队列、对象存储、分布式锁等。在SaaS层，银行主要通过单元化+微服务的架构来实现分布式扩展。银行将自身业务应用划分成三种单元。最上层是全局单元，主要是起到全局路由及流量分发的作用。第二层是业务单元，核心的业务逻辑都在该部分来实现。同时，为了实现业务的横向扩展并支持数亿客户量，银行业跟互联网公司一样，对业务进行单元化拆分。例如我们接触到的某银行，就是将自身的业务拆分为了16个业务单元，每个单元五千万客户，16个单元部署在两个机房形成同城双活的架构。最底层是公共单元，一些不太好或没必要做单元化拆分的应用，放在公共单元提供公共服务。通过上述分析可以看到，在新一代银行核心系统里面，整体的架构体系已经和互联网公司很接近了，大家用的都是相同的技术栈，只是服务的业务场景不同。在未来，银行业跟互联网业的技术交流会进一步紧密，人才的流动也会进一步频繁。在业务采用了单元化划分后，数据库的架构是怎么样的呢？目前在银行的新核心系统下移中，主要采用了以下两种数据库架构：
第一种是单机数据库架构。这种数据库架构比较简单，故障域较小，但相对来说业务系统会比较复杂。因为有些模块，如全局路由模块，是全局的总入口，没法做单元化拆分。因此一组单机数据库无法满足性能与容量需求，依然需要在业务层做数据拆分。除此之外，单机数据库无法完全支持业务单元层的业务落地。前面提到，我们接触到的某银行一个业务单元要承担五千万的客户数，一组单机数据库依然无法支持。于是在业务层进一步拆分为4组数据库共64张子表，业务层需要去解决大量的拆分及分布式事务相关的业务逻辑，整体就更复杂了。
另外一种是分布式数据库架构。这样的数据库内部架构虽然更为复杂，但它可以提供更好的性能。对业务层来说，一个单元采用一组数据分布数据库即可，业务层的逻辑就更为简单了。
因此我们认为，随着分布式数据库的逐步成熟与应用逐渐广泛，业务单元化+分布式数据库会逐渐成为流行的银行业务架构。综上，银行核心系统在下移的场景下，对数据库在如下几个方面提出了要求：第一是分布式扩展性。由于采用了通用服务器，它的单机性能要远弱于大型机或者小型机。在这种情况下，数据库需要具备分布式可扩展的能力来满足上亿客户的金融需求。第二是强一致性。金融场景对数据正确性、一致性的要求极高。因此要严格保障对事务的ACID特性。否则，业务层就要做大量的工作。第三是容灾能力。通用服务器在硬件故障率方面要比大型机、小型机高很多。因此需要我们的数据库有更为可靠的可用机制以保障SLA。同时，监管对于容灾能力的要求也在不断提升。比如，对于新建设的核心系统，监管要求必须满足5级以上的容灾能力，且满足同城双活并保证RPO为0。在具体执行上，监管的要求也越来越严格，比如同城双活，之前是只需要具备相关的技术方案即可，但现在每年人行的监管都会直接到现场，要求做机房级实战故障切换。第四是运维能力。系统下移到通用服务器并实现去IOE，数据库节点数量要出现50倍的增长。以我们的一个银行客户举例，从小型机下移后，数据库节点数从20增长到（当然这里面也预留了几倍的性能增量）。在和客户的交流过程中，他们也认同这个观点，认为系统下移后，节点数要增长一到两个数量级。但运维的人力不可能因此增加几十倍，在这种情况下，就要求我们的运维效率要有质的提升，需要能够智能化、自动化去做相关的运维工作。2分布式数据库GaiaDB-X的金融场景方案接下来我们分享第二部分，分布式数据库GaiaDB-X针对金融场景的解决方案。GaiaDB-X数据库是百度智能云研发的SharedNothing架构的分布式数据库，它可以基于通用服务器做横向扩展，来满足高性能、大数据容量的需求。总体来看它分为计算层、存储层、元数据三层架构：计算层是无状态、可横向扩展的一层。它对外兼容MySQL协议，接收到SQL请求后，再经过SQL解析、权限检查、逻辑优化、物理优化之后，生成DistSQL下发到各个存储层的分片。为了达到更好的性能，逻辑与物理上尽量将数据过滤及计算能力下推到存储层，收到结果后，再把数据进行聚合计算，最后返回给客户端。计算层的下面是存储层。它采用多分片的方式进行扩展，数据按照一定的分片规则打散到了各个分片中。我们支持Hash、Range、List等分区方式来做数据分区。同时，分片内数据采用多副本的方式来保证可靠性。第三是GMS节点，即全局元数据管理模块。它用来管理全局性数据，例如表的Schema信息、权限信息、表的路由信息，还有后面要介绍到的用于做分布式事务的全局逻辑序列号。GMS也采用多副本的方式，采用Raft协议进行数据同步。在最底层是我们的统一数据库管控平台，来实现对数据库集群的管理。比如在百度集团内部数十万的数据库节点，都是由该管控平台来管理的。GaiaDB-X数据库是百度集团发展历史最久、应用最广泛的一款数据库，到现在为止已有18年的发展历史。它的发展也与百度的业务发展息息相关，大概可以归纳为四个阶段：第一阶段是从年开始，为了满足搜索、社区业务中大量读请求的场景，我们通过一主多从的集群化外加读写分离来扩展读性能。第二阶段是为了支持凤巢广告系统与百度网盘，满足它们对万亿级数据量的需求，我们开始做分布式系统。到了年，我们就已经在凤巢广告系统中替换了基于Oracle的盘柜，为凤巢每年节省了上千万的成本。针对百度网盘，我们有个台服务器的集群支持网盘业务，所有网盘文件的元数据信息都存储在这里，最大的表达到万亿级记录数，至今仍是国内最大的关系型数据库集群之一。第三阶段是随着百度钱包等泛互联网业务的兴起，对数据的一致性要求更高了。因此，我们实现了分布式事务强一致的特性，保障金融数据的正确性。第四阶段，也就是现在。随着百度智能云对外技术输出，我们已经把数据库输出到了十余个行业，覆盖家客户。在金融行业，GaiaDB-X已经承接了金融核心业务，包括百信银行、银联商务、某交易所及国有行等。对于分布式数据库，水平扩展能力是其核心能力。除了在计算层与存储层做水平扩展外，我们还要着力去解决影响我们扩展能力的单点。
第一个是GMS，即全局元数据模块。因为它要提供一个全局递增的全局逻辑时钟，每一次事务都需要调用它。为了避免其成为瓶颈，我们采用批量预分配的方式来提升其总吞吐，在此模式下，其每秒可分配万个TSO序号，远超出百万级TPS的需求。
第二个是全局事务表。为了保证分布式事务的原子性，我们需要将正在进行中的事务保存到一张全局表中，因此它的性能也会直接影响到全局性能。我们采用自管理的方式，将全局事务表做成分布式表，分布式地存储在集群中，这样就可以实现分布式扩展。
在实际应用中，比如说像19年的春晚抢红包，我们支持了三亿用户抢红包，支撑了峰值达每秒12万交易量。除此之外，针对某银行拥有8万账户的核心账务系统，我们也平稳支持了其6万每秒的TPS，充分验证了GaiaDB-X的水平扩展能力。除分布式外，我们也支持单机场景，实现了单机分布式一体化。为什么需要单机分布式一体化呢？以我们的一个银行客户来说，全行的业务系统有多个，其中大部分系统（大概占70%左右）对性能与吞吐的要求并不高，一组单机数据库就能够满足其业务需求。但对于剩下的0%业务，它对性能的要求是单机数据库无法满足的，需要分布式数据库来满足其扩展性。
因此我们通过一体化的方式，来满足银行不同体量的业务对于数据库的需求。同时，我们也具备单机数据库扩展为分布式的能力，在对应业务的数据量增长后，能够扩容为分布式。扩展性的另外一个目的是自动做数据分离。在金融场景里面，存在多个业务共用一个数据库集群的场景，比如业务分为联机交易系统与查询类系统，数据库便对应划分为交易库和历史库两个。
对于交易库来说，只保存联机交易会频繁使用到的数据。例如账务结果数据及当天的交易记录，以满足对交易业务的快速响应。对于查询不那么频繁的即时交易记录，这可能就是一个相当大的数据量，一般都能达到千亿甚至万亿级别。这时，我们就可以将这个数据自动转移到历史库上去，用更高密度的存储机型来存储。一方面可以降低硬件成本，同时也可以避免对联机业务的影响。
这样做对业务来说，对外呈现的是一套数据库，业务可以根据需要来处理不同数据分区的逻辑，也不用在多套库之间通过DTS做数据同步。同时还把交易数据和历史数据做分离，以保障对联机业务的性能，同时也满足了查询业务的查询需求，避免其相互影响。在金融场景中，对事物的ACID特性有着严格的要求：持久性。指的是事务一旦提交就不会丢失，一般通过多副本+强同步来解决。原子性。一个事务要么全部提交，要么全部回滚，不存在部分提交的情况。通常，数据库的XA协议，通过两阶段提交能解决这个问题。但是XA协议不能很好地满足一致性与隔离性。以简单的转账场景为例，A、B原来各有块钱，总共块。然后A给B转账50块钱。此时，我们会先给A扣50，再给B加50。如果通过XA协议来做的话，先走prepare再