58同城 网站开发,短视频营销常用平台有,php网站开发文档,wordpress整站搬家教程1 银行新一代核心系统建设背景及架构
在银行的 IT 建设历程中#xff0c;尤其是中大行#xff0c;大多都基于大型机和小型机来构建核心系统。随着银行业务的快速发展#xff0c;这样的系统对业务的支持越来越举步维艰#xff0c;主要体现在以下四个方面#xff1a; 首先是…
1 银行新一代核心系统建设背景及架构
在银行的 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 增长到 1000当然这里面也预留了几倍的性能增量。在和客户的交流过程中他们也认同这个观点认为系统下移后节点数要增长一到两个数量级。但运维的人力不可能因此增加几十倍在这种情况下就要求我们的运维效率要有质的提升需要能够智能化、自动化去做相关的运维工作。 2 分布式数据库 GaiaDB-X 的金融场景方案
接下来我们分享第二部分分布式数据库 GaiaDB-X 针对金融场景的解决方案。
GaiaDB-X 数据库是百度智能云研发的 Shared Nothing 架构的分布式数据库它可以基于通用服务器做横向扩展来满足高性能、大数据容量的需求。
总体来看它分为计算层、存储层、元数据三层架构 计算层是无状态、可横向扩展的一层。它对外兼容 MySQL 协议接收到 SQL 请求后再经过 SQL 解析、权限检查、逻辑优化、物理优化之后生成 DistSQL 下发到各个存储层的分片。为了达到更好的性能逻辑与物理上尽量将数据过滤及计算能力下推到存储层收到结果后再把数据进行聚合计算最后返回给客户端。 计算层的下面是存储层。它采用多分片的方式进行扩展数据按照一定的分片规则打散到了各个分片中。我们支持 Hash、Range、List 等分区方式来做数据分区。同时分片内数据采用多副本的方式来保证可靠性。 第三是 GMS 节点即全局元数据管理模块。它用来管理全局性数据例如表的 Schema 信息、权限信息、表的路由信息还有后面要介绍到的用于做分布式事务的全局逻辑序列号。GMS 也采用多副本的方式采用 Raft 协议进行数据同步。
在最底层是我们的统一数据库管控平台来实现对数据库集群的管理。比如在百度集团内部数十万的数据库节点都是由该管控平台来管理的。 GaiaDB-X 数据库是百度集团发展历史最久、应用最广泛的一款数据库到现在为止已有 18 年的发展历史。它的发展也与百度的业务发展息息相关大概可以归纳为四个阶段 第一阶段是从 2005 年开始为了满足搜索、社区业务中大量读请求的场景我们通过一主多从的集群化外加读写分离来扩展读性能。 第二阶段是为了支持凤巢广告系统与百度网盘满足它们对万亿级数据量的需求我们开始做分布式系统。到了 2014 年我们就已经在凤巢广告系统中替换了基于 Oracle 的盘柜为凤巢每年节省了上千万的成本。针对百度网盘我们有个 3000 台服务器的集群支持网盘业务所有网盘文件的元数据信息都存储在这里最大的表达到万亿级记录数至今仍是国内最大的关系型数据库集群之一。 第三阶段是随着百度钱包等泛互联网业务的兴起对数据的一致性要求更高了。因此我们实现了分布式事务强一致的特性保障金融数据的正确性。 第四阶段也就是现在。随着百度智能云对外技术输出我们已经把数据库输出到了十余个行业覆盖 150 家客户。在金融行业GaiaDB-X 已经承接了金融核心业务包括百信银行、银联商务、某交易所及国有行等。 对于分布式数据库水平扩展能力是其核心能力。除了在计算层与存储层做水平扩展外我们还要着力去解决影响我们扩展能力的单点。
第一个是 GMS即全局元数据模块。因为它要提供一个全局递增的全局逻辑时钟每一次事务都需要调用它。为了避免其成为瓶颈我们采用批量预分配的方式来提升其总吞吐在此模式下其每秒可分配 1200 万个 TSO 序号远超出百万级 TPS 的需求。
第二个是全局事务表。为了保证分布式事务的原子性我们需要将正在进行中的事务保存到一张全局表中因此它的性能也会直接影响到全局性能。我们采用自管理的方式将全局事务表做成分布式表分布式地存储在集群中这样就可以实现分布式扩展。
在实际应用中比如说像 19 年的春晚抢红包我们支持了三亿用户抢红包支撑了峰值达每秒 12 万交易量。除此之外针对某银行拥有 8000 万账户的核心账务系统我们也平稳支持了其 6 万每秒的 TPS 充分验证了 GaiaDB-X 的水平扩展能力。 除分布式外我们也支持单机场景实现了单机分布式一体化。为什么需要单机分布式一体化呢以我们的一个银行客户来说全行的业务系统有 200 多个其中大部分系统大概占 70% 左右对性能与吞吐的要求并不高一组单机数据库就能够满足其业务需求。但对于剩下的 30% 业务它对性能的要求是单机数据库无法满足的需要分布式数据库来满足其扩展性。
因此我们通过一体化的方式来满足银行不同体量的业务对于数据库的需求。同时我们也具备单机数据库扩展为分布式的能力在对应业务的数据量增长后能够扩容为分布式。 扩展性的另外一个目的是自动做数据分离。在金融场景里面存在多个业务共用一个数据库集群的场景比如业务分为联机交易系统与查询类系统数据库便对应划分为交易库和历史库两个。
对于交易库来说只保存联机交易会频繁使用到的数据。例如账务结果数据及当天的交易记录以满足对交易业务的快速响应。对于查询不那么频繁的即时交易记录这可能就是一个相当大的数据量一般都能达到千亿甚至万亿级别。这时我们就可以将这个数据自动转移到历史库上去用更高密度的存储机型来存储。一方面可以降低硬件成本同时也可以避免对联机业务的影响。
这样做对业务来说对外呈现的是一套数据库业务可以根据需要来处理不同数据分区的逻辑也不用在多套库之间通过 DTS 做数据同步。同时还把交易数据和历史数据做分离以保障对联机业务的性能同时也满足了查询业务的查询需求避免其相互影响。 在金融场景中对事物的 ACID 特性有着严格的要求 持久性。指的是事务一旦提交就不会丢失一般通过多副本 强同步来解决。 原子性。一个事务要么全部提交要么全部回滚不存在部分提交的情况。通常数据库的 XA 协议通过两阶段提交能解决这个问题。
但是 XA 协议不能很好地满足一致性与隔离性。以简单的转账场景为例A、B 原来各有 100 块钱总共 200 块。然后 A 给 B 转账 50 块钱。此时我们会先给 A 扣 50再给 B 加 50。如果通过 XA 协议来做的话先走 prepare 再 commit我们可以看到commit图中第 7、第 8 步过程不是原子过程存在一个执行时间差。在这个时间差内另外一个事务去读取数据就可能存在读到提交了一半的数据A 和 B 的总和是 150 而不是 200。这是 XA 2PC 解决不了的问题。
为了解决这个问题业内一般是引入一个全局时钟来做一致性的保证。通常有三种实现方式 TrueTime 方案。这个是大家比较熟悉的方案Google Spanner 也发过论文。但它的缺陷是依赖硬件要引入 GPS 与原子钟这个一般来说是难具备的。 HLC 方案。采用该方案的典型数据库系统是 CockroachDB它的优点是不依赖硬件而且是去中心化的。但是缺点也很明显一致性比较弱而且要求服务器间的时钟误差不能超过 250ms否则就无法正常运行。 TSO 方案比如 TiDB 就是采用了这种方案。TSO 本质上来说是一个全局唯一而且自增的逻辑序列号一个事务在开始时与事务 commit 时需要两次找 GMS 获取序列号然后把 TSO 号作为版本号提交到存储层存储层的 MVCC 机制来判断数据是否可见。它不需要硬件具备强一致性但缺点是依赖一个全局中心的时钟分配器 GMS。但这并不是一个问题因为刚刚我们也提到了虽然 GMS 不具备扩展性1200 万的 TPS 已经完全满足业务的常规需要了。因此我们最终采用了这种方案。 除了保障事务的一致性外我们还需要保障上下游系统的数据一致性。在开始之前我们首先要讲一下银行的典型业务场景它一般分为三个子系统 第一个是联机交易系统例如存取款、在线支付等。这个系统的并发量高、延迟敏感直接影响到用户体验。 第二个是跑批类的业务系统。例如结息每天晚上半夜计算前一天的利息。这些业务是后台业务有大量的读取与计算操作延迟不敏感但是对数据一致性要求高。怎么能够让这样的业务尽量避免对在线业务的影响同时又能够读取到最新的数据呢我们的方式是让跑批业务去读取从库数据从而避免对主库的性能影响同时结合 TSO即全局逻辑时钟的对位对齐机制。等到从库水位追齐之后才返回读取数据。当然这会引入一定的延时但是因为跑批业务对响应延时不那么敏感所以是可以接受的。 第三个子系统是大数据类的离线业务。通常来说就是银行内部的各种大数据、数仓等系统需要把数据库的数据同步过去。这样的业务对实时性要求不高但要求最终的数据是一致的。由于各个计算节点都会承担流量也会生成 BinLog。因此如何对多份 BinLog 进行排序让它们能够严格保持时序是我们需要解决的问题。我们的全局 BinLog 有两个模块一个是 pump从各个CN 节点抽取 BinLog然后在 Sorter 节点基于 TSO全局逻辑时钟进行排序来保障形成一个全局时序正确的 BinLog以保障这个离线系统收到的数据的最终正确性。 接下来我们看一下容灾能力除了对单机故障的容灾之外还有对特定机型的容灾。因为银行把系统下移到通用服务器通常都是通过两阶段来实施第一阶段是下移到 X86 的 CPU 芯片上这个过程银行、互联网厂商都一定的经验。第二阶段是要实现服务器芯片的基本国产化就是说使用国产的鲲鹏、飞腾或海光 CPU 芯片这方面大家都是在探索性的开展相关业务。
以百信银行举例它与其母行中信银行一样选择了基于鲲鹏做国产化的路线而且在业内比较超前。相较于其他银行仅在周边系统或者数据库从库来做国产化百信银行的周边业务跟核心系统都和主站一样基于鲲鹏服务器来做这个在业内是较为领先的。
为了保证客户业务系统实现平滑的国产化我们在产品上实现了一库多芯的方案主要资源池基于鲲鹏但放置了一个独立 X86 资源池在技术上实现托底同时也能够将原有换下来的服务器能够利用上避免资源浪费。 根据人行的监管要求银行核心系统一般要具备 5 级以上的容灾能力这就要求具备两地三中心的容灾能力。
下图是我们客户的一个典型机房部署架构。首先在北京有两个同城机房其物理距离在 50-100 公里左右网路延迟在 1ms 左右。同时还有一个异地机房做灾备物理距离一般是 1000 公里左右比如合肥网络延时是 10ms。
同城两个机房业务做双活部署同时接受业务流量。数据库在两个机房采用 3 2 的部署形式机房间采用强同步的方式来保障在发生机房级的故障之后数据库能进行故障切换而且保障数据的 RPO 为 0。
为保证单机房故障后的零数据丢失我们采用分组强同步的方式将 id1、id2 各划分一个复制组复制组间采用强同步的方式。每个复制组保证至少有一个副本接收到数据之后才返回成功。这样在容忍少数副本故障的同时也能够保证单个机房故障后的零数据丢失。
异地机房的目标是当北京的两个机房都出现灾难性的事件之后能够降级完成核心业务。它采用异步级联的方式来同步数据首先异步是为了避免阻塞对主地域的数据库写入采用级联方式没有跟主地域机房形成复制组主要一个为了保持灾备机房的数据库的拓扑独立性减少依赖保障在关键时刻可切换另外也是降低跨地域同步的数据量只需要同步一份数据即可。
结合在多家金融客户的实践我们和中国信通院一起发布了金融数据库的容灾技术报告《金融级数据库容灾备份技术报告2021 年》。大家可以在公众号后台回复「金融级数据库容灾备份技术报告」获取。 最后一部分是运维能力。核心系统下移及国产化的背景之下数据库系统呈现两个变化
一是数据库的节点数出现了 50 倍的增长这里面既有技术架构的原因也有数据库预留了一定的性能空间的原因。
二是数据库的种类也变多了。对于银行系统来说之前基本就是选择 Oracle 或 DB2。现在则开始使用多种开源数据库和国产数据库。除此之外为了避免像之前一样被单一厂商绑定银行也会特意选择多家数据库厂商在这种情况下对银行的运维的挑战就更大了。
因此结合百度集团及百度智能云管理大规模数据库节点方面的经验我们将 GaiaDB-X 数据库云管平台进一步泛化形成了具备管理多元数据库能力的统一平台它除了能够管理 GaiaDB-X 自身也能管理其他的开源数据库。通过帮助银行建立企业级的 DBPaaS 管理平台进一步提升了银行的运维效率。 3 金融应用案例介绍
接下来我来分享百度智能云在金融方面的一些典型案例。
首先是百信银行。它的特点是完全去 O是一家完全没有 Oracle 的银行。全行 200 业务系统无论是核心账务系统还是周边系统几乎全部是基于 GaiaDB-X 数据库来构建的至今已经平稳运行五年。
按数据库节点数计算百信银行目前的数据库国产化率达到了 99.93%遥遥领先于行业平均水平。
同时百信银行在容灾和国产化领域也比较领先在 2019 年就完成了全行主要系统的同城双活建设2022 年开始将全行业务逐步迁移到基于鲲鹏的国产云上进而实现了全栈的国产化。
在硬件成本方面我们通过采用通用服务器来替代 IOE 硬件帮助百信银行的单账户平均硬件成本降低了 70% 以上。 下图是人行下面直属的某交易所。因为是涉及到国家金融稳定所以在核心系统上需要逐步摆脱对 Oracle 的依赖并拥有两地三中心的容灾能力。
由于当前的一些数据库都不能满足他们的业务场景需求因此该交易所和百度采用了联合开发的模式共建数据库能力。在两年的合作过程中我们从外围的信息管理系统入手逐步深入到核心交易系统再到离线库数据分析系统进而逐步实现数据库国产化。
此外由于交易所的交易系统对低延时的要求较高同时基于容灾要求又有同城双活的要求如何在跨机房的情况下保障交易延时就成了亟待解决的问题。因此我们共同建设了 Collocate 机制来尽量减少跨机房数据的访问最终将交易延时从 80 毫秒降低到了 15 毫秒。 下图是国内某国有大行客户。他们在最近两年把原有的基于小型机的核心系统下移到了通用服务器中数据库也从 Oracle 替代为了开源单机数据库。
但在这个过程中该行面临两个问题一是数据库节点数增长了 50 倍服务器数量到达了 1000 台左右如何做好数据库的自动化部署、上线变更、版本升级、参数管理、性能诊断等工作。二是如何结合业务的单元化形成业务与数据库的同城双活与异地容灾能力。
借助百度智能云提供的统一数据库管控平台的能力历时两年我们与客户一起实现了新核心系统的全面投产也顺利通过了人行的验收。 以上是今天分享的全部内容。
——————END——————
推荐阅读
云上业务一键性能调优应用程序性能诊断工具 Btune 上线
一文详解静态图和动态图中的自动求导机制
千万级高性能长连接Go服务架构实践
百度搜索Push个性化新的突破
百度智能云千帆 AppBuilder 构建 AI 原生应用开发新范式
