银行核心系统分布式改造，架构设计如何为数据库运维加成？

发布时间：2025-11-05 03:08:51 来源：码上建站 作者：IT科技

一、银行运数据库架构建设的核心基本方法和过程

二、某核心系统由大型机系统迁移到分布式架构

三、系统Redis异地容灾架构建设

一、分布数据库架构建设的式改基本方法和过程

1.数据库架构组成

在日常工作中，如果我们说到数据库架构，造架一般来说指的构设是网络、主机、计何据库加成存储及之上运行的为数数据库实例。数据库架构工作指的银行运则是如何去评估和组合这些组件，从而为业务提供符合运营要求的核心数据库服务。

当数据库架构演进到分布式架构，系统如何让应用程序（服务）快速确认数据所在的分布位置，就成为了一个核心的式改问题，而这就是造架数据库访问组件的工作。

对于一个大型组织，运营几千套、几万套数据库实例是很平常的事情，而这也给运营团队的日常管理带来了一定难度的站群服务器挑战。各个公司组织纷纷搭建运营平台，用于告警监控、故障处理、变更、版本发布等，在设计和构建数据库架构的同时建设数据库运营平台已经成为了一种标准操作。

2.可运营及需求的组成

数据库架构首先要匹配组织的业务流程，满足组织的业务需求，是所有从业者的共识。

设计和构建数据库架构的最终目标就是获得一个能够持续、稳定提供服务的数据库集群，从设计之初就充分了解和满足运营需求，是数据库架构设计成功的一个关键要素。

对于强监管行业而言，不满足监管要求，项目就无法上线。因此，监管需求可以说事关监管行业的生死，必须在设计之初就充分考虑。

3.架构设计

“不要重复造轮子”，源码下载在数据库架构设计前，调研业界的技术生态非常重要。同时需要注意，我们所在组织的技术生态也是业界生态非常重要的一部分。

通过调研业界生态，我们能够获取数据库架构所需的模块，再结合项目的实际情况，对所需模块进行组合和完善，就能够获取数据库架构的初稿。

4.架构构建

数据库选型放在架构设计之后的一个重要考量是保证数据库架构设计的客观性。如果在数据库架构设计之前就选定了数据库，架构设计将不可避免地受到数据库功能特性的影响。

在拥有数据库架构设计和完成数据库选型的前提下，我们才能在测试或者开发环境构建数据库架构原型，这是我们下一步工作的基础。

5.架构迭代

1）在完成数据库原型建设之后，可以开始对数据库原型进行测试和验证，验证指标应回到最初的需求、亿华云计算业务目标、运营目标和监管目标。

2）每轮的测试和验证都会生成架构的优化项，结合项目的需求和目标，对数据库架构不断进行迭代，一般在3到5轮迭代之后就可以得到一个相对稳定可靠的数据库架构。

二、某核心系统由大型机系统迁移到分布式架构

1.项目调研

迁移项目第一步是对当前系统的情况进行摸底调查。

系统指标分为很多方面，对于数据库架构而言，首先需要考虑的是性能和容量指标。

该项目具有一个明显的特点——实时在线业务一次仅处理一个客户，账务结算和报表模块一次需要处理很多客户数据。

通常意义上所说的计算和存储分离指的是数据存储在大型机文件中，业务逻辑完全在应用层实现。

项目人员的能力主要集中于JAVA的开发，对于Oracle和MySQL较为熟悉，其他关系型数据库的开发则相对陌生，项目人员的能力对于数据库选型有明显的影响。

2.数据库架构原型设计

1）按照客户对数据进行分片，数据路由在应用层处理，每个分片都由一个数据处理模块和一组数据库实例组成，不同分片之间完全独立，跨分片的聚合计算在业务层处理。

2）站在数据库本身的视角，不同分片之间的数据库实例是完全独立的，不存在任何的数据交互。站在业务的角度，所有的数据库实例则组成了一个统一的数据库集群。

3）该架构的优点是单分片处理逻辑简单，对实时在线业务非常友好；缺点是跨分片处理逻辑复杂，报表和账务结算业务难度高。

3.数据库选型

4.运营平台建设

1）配置管理：为每个数据库实例添加分片属性和业务属性。

2）端到端交付：为了满足数据库实例可以动态地横向扩容和缩容，增加了拉入节点、拉出节点和资源池的功能。

3）监控和故障处理：在原有的数据库监控平台的基础上，增加了业务视角和分片视角，当数据库实例故障时，能够更加精准定位到受影响的客户。

4）数据库变更：为满足24小时不停机的业务要求，增加了业务降级、流量管控、滚动处理和变更日历功能。

5）版本发布：在分布式架构下，为应对成倍上升的复杂度和风险，增加灰度发布、并行发布、分片自适应和版本编排功能。

5.数据库架构迭代

1）为满足监管要求，需要在已有架构上添加容灾架构。

2）使用业界已有的技术，通过binlog将数据实时同步到大数据平台，进行报表分析。

3）使用业界已有的技术，通过binlog将数据实时同步到分片数据库（整体引入），降低账务结算程序的复杂度。

三、Redis异地容灾架构建设

1.需求整理

1）所有的Redis仅作为缓存使用，无数据同步需求。

2）95%以上的Redis为Cluster架构，5%以内的Redis为哨兵架构，本次设计的架构聚焦于Cluster架构。

3）95%以上的Redis Cluster无容量和性能要求，准确来说就是所有的Redis Cluster都可以标准化，只要后续提供扩容/缩容的功能即可。

4）生产Redis Cluster变化较大，异地容灾要求和生产同步上线和下线。

5）最小化DBA和应用开发团队的人力成本。

2.架构实现

1）建设一个K8S集群，用来承载所有的Redis集群。

2）建设Redis集群同步平台，从已有的CMDB读取生产Redis集群的信息，并将创建的异地容灾Redis集群信息更新到CMDB。

3）同步进程根据CMDB生成生产Redis集群集合和异地容灾集合。生产集合减去异地容灾集合，即需要搭建的异地容灾集合，平台将自动创建异地容灾集群，并将信息更新到CMDB。异地容灾集合减去生产集合，即需要下线的异地容灾集合，平台将自动下线异地容灾集群，并将这些集群从CMDB中删除。

4）每天执行上述步骤，即可保证移动容灾集群和生产集群的同步。

5）K8S集群可以自动拉起宕掉的节点，结合Redis集群本身的高可用，即可保证异地容灾集群的高可用。

6）K8S集群本身的告警监控即可满足异地容灾的告警和故障处理需求。

7）设计自助平台，应用开发和运营团队可以进行自助查询、自助修改参数、自助扩容、自助申请域名等操作，最小化DBA和应用开发运营的人力成本。

平安银行 数据库运维团队上海分组负责人

专注于数据库领域20+年的老兵，目前专注于数据库运维和数据库架构。

相关文章