分享

国有大型银行基于GoldenDB的核心应用系统分布式全栈改造方案

Jay 发表于 2023-7-22 00:31:35 [显示全部楼层] 只看大图 回帖奖励 阅读模式 关闭右栏 0 511
国内某国有大行,原有核心系统均在大机上运行,数据库采用DB2。在业务层面分布式改造的成果基础之上,建行启动最难的部分--数据库的分布式改造,推进主机完全下移。项目基于GoldenDB进行实施改造,建设目标如下:
1)为以大型银行Z系列主机为代表的核心应用系统实现分布式改造提供基础的开发和运行平台全面提升分布式平台能力,解决架构转型中遇到的基础性技术问题;
2)实现大行核心应用的多中心多活部署加快对国产数据库对软硬件的兼容适配能力,解决应用的平滑迁移难题,为以核心银行为代表的应用系统实现分布式改造提供基础的开发和运行平台;
3)  实现多中心多活部署能力,提供数据高可靠保障。
截止2022年12月,该国有大行采用GoldenDB分布式数据库在个贷、代收付业务完成全国投产,对私核心完成西北区域10省的投产,承载8亿用户,目前对私核心达4000+TPS,个贷达2万+TPS,系统投产至今运行稳定。本次项目实现了两地4AZ多地多活部署(未来扩展到4地)、性能容量线性扩展,解决了应用从主机平滑迁移到分布式数据库的难题,满足建行未来业务发展需求,是国内首个大型银行Z系列主机为代表的核心应用系统多地多活分布式改造的成功商用实践案例,为其他大中型银行提供参考借鉴的依据。
项目背景
该国有大行部署在主机上的几个大系统,都经过了改造,取得了不错的效果。但是行内目前还存在大量的部署在小机上的子系统。这些系统的迁移存在如下问题:
  • 这些系统分属不同的事业群,替换成国产数据库,需要投入较多的人力熟悉数据库的安装部署、运维管理,如何减少资源投入成为问题;
  • 分布式数据库的部署对资源占用相比原有小机更大,在全行多套数据库进行替换的时候,是使用一套分布式数据库承载多套业务系统,还是使用多套数据库分别承载对应业务,这个问题也需要考虑。不同的应用系统对于数据库的升级、切换,有着不一样的要求,数据库方面如何保障这些操作的隔离性?
分布式数据库方案整体上更加复杂,节点网元相比集中式数据库更多,需要观察、监控的指标很多,原有的运维系统如何快速对接上新的国产数据库?
项目目标
业务目标:完成行内170套小机下移系统从集中式Oracle数据库迁移到国产分布式数据库上。
技术目标:解决行内使用新技术栈数据库进行统一部署,快速供给的问题;解决多套业务子系统的数据库既要统一运维又要相关运维操作逻辑隔离的问题;解决新数据库如何与行内现有运维系统对接的问题。
业务目标
实现原部署在小机上的业务迁移及数据库分布式改造。
实现业务平滑迁移,提升业务服务能力。
技术目标
1.构筑两地三中心云化部署集群,统一管理、统一供给,达到数据库即服务;
2.一套分布式数据库提供全行多套业务系统的数据库服务;多套数据库之间资源隔离,状态隔离,支持各自独立进行容灾切换;
3.提供的统一运维能力,融入数据中心的运维体系,由原有面向界面,面向后台的运维,转为构建面向接口的运维能力。
4.通过创新性的改造主备副本的同步/异步复制机制,保证本地与同城RPO=0,RTO<1分钟,数据不丢失,实现银行数据的安全性;
5.数据库集群统一管理,通过计算集群、数据分片主备机制/分组机制,自定义切换策略,在组件级故障、机房级故障、城市级故障时,实现系统高可靠;
6.Oracle数据库到GoldenDB的平滑迁移和替换;
7.对迁移场景进行分类,制定对应的规则,提供标准的操作流程,标识出流程的范围、各步骤的输入输出,提供完善的迁移平台。
解决方案
GoldenDB分布式数据库的架构分为了业务数据处理模块和内部数据处理模块两大部门。其中,业务数据处理模块包含了Manager模块进行DDL的管理以及各组件的切换管理,CN模块块进行分布式SQL执行优化,DN模块进行数据的持久化,GTM模块进行分布式事务的并发控制;内部数据处理模块包含了Insight、OMM和ZK三个模块,其中Insight与OMM负责服务器与组件级别的信息采集、监控告警,ZK模块负责为GTM与Manager提供选主能力。
数据架构
ec396625f3694c47822fe45425bc4a7e.png.jpg
  • 分布式数据库GoldenDB部署在underlay;
  • 应用以及数据库相关上下档工具部署在overlay;
  • 应用、工具与数据库的交互,通过underlya与overlay的交互,应用和工具看到的都是CN节点的映射IP。
  • 应用获取到的数据,会通过APP返回给前端业务;
  • 工具获取到的数据会写入COS或者HDFS集群,通过COS集群与HDFS集群交换数据。
部署架构
单租户部署架构如下:
894a00e535d74d2899cd31433be5c784.png.jpg
典型的单分片租户生产灾备部署如上图所示。
本地部署推荐如下:
1.计算节点成对部署,至少2台,保障高可用;
2.数据节点按照本地3副本部署,根据实际业务容量和压力计算分片数量,单分片的时候占用3台服务器;
3.管理节点和GTM可以合并部署,按照本地3副本部署,占用3台服务器。
跨地域部署推荐如下:
1.异地使用独立的集群部署;
2.计算节点成对部署,至少2台,保障高可用;
3.数据节点按照一主一备部署;
4.异地的管理节点和GTM 与本地对等部署,占用3台服务器。
多租户部署架构如下:
7a119c73cfd1448f88b0993cdf8e7eca.png.jpg
典型的多租户生产灾备部署如上图所示。
本地部署推荐如下:
1.每个租户计算节点成对部署,至少2台,保障高可用;
2.每个租户数据节点按照本地同城3副本部署,根据实际业务容量和压力计算分片数量,单分片的时候占用3台服务器;
  • 多个租户GTM可以合并部署,也可以每个租户GTM按照本地副本部署,占用3台服务器。
  • 管理节点独立部署。
跨地域部署推荐如下:
1.异地使用独立的集群部署;
2.计算节点成对部署,至少2台,保障高可用;
3.数据节点按照一主一备部署;
4.异地的管理节点和GTM 与本地对等部署,占用3台服务器。
步骤的输入输出,提供完善的迁移平台。

版权说明:论坛帖子主题均由合作第三方提供并上传,若内容存在侵权,请进行举报

没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

联系在线客服