商业银行基于容器云的分布式数据库架构设计与创新实践

导读

本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台，重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。

通过引入 TiDB Operator 自动化管理与容器化技术，银行能够实现多个业务系统的高可用、弹性扩展与自动化运维，极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案，展示了 TiDB 在金融行业数字化转型中的应用前景。

某商业银行新一代业务金融云建设，以某国有大行新一代业务解决方案为建设蓝本，目标是利用新架构满足业务快速迭代的要求，提供较强的业务处理能力和灵活扩展能力，加快数字化转型和业务创新等，同时满足降本增效要求。其中，选定 TiDB 分布式数据库集群的上云应用系统合计超过 100 个，涉及核心、金融服务、渠道管理/整合、中间业务、个人贷款、对公贷款、组件服务、公共业务管理、数据分析等多个银行重要业务领域，系统重要等级高，需要具备两地三中心部署、同城双活能力，且同城和异地 RPO、RTO 满足系统对应的高可用和灾备要求。按原私有部署模式（OP)，该项目常规需要物理机 300-600 台，考虑客户自身运营规模，系统建设迫切需要建立成本低、使用便捷的 TiDB 云化平台支持服务体系，全面减低 TiDB 部署、测试、运维等成本。

目前业内主流的 OP（私有）TiDB 部署方案，基于独立物理服务器，存在以下问题：

• 数据库使用成本高：每一个业务应用都需要一套独立的数据库，部署时需要 3-6 台物理服务器；部署过程无法白屏化一键操作，仍需要人工复核和定位部署过程中出现的各类问题；

• 单独为业务系统建设数据库，不符合成本效益，同时形成多个数据孤岛；同时带来资源利用率低问题：每个业务对应的数据库集群利用率不同，无法合理利用同一套硬件资源，造成明显的资源浪费；

• 业务上线、变更速度慢：通常采用物理机部署的形式来为某个业务应用提供数据服务。基础架构团队每次都需要部署物理机，如果考虑容灾备份的需求，工作量极大，资源交付速度很慢，通常是以“天”为单位；上线后如果需要数据库扩容、调整架构等，面临相同问题

• 运维管理难度高：依赖管理员经验、手工命令，无法满足运工作标准化和自动化要求

该银行通过 TiDB Operator 自动化部署能力和 K8s 成熟的容器集群调度管理能力和 TiDB 数据库的高可用能力，构建 TiDB 云化平台。

整体目标是建立满足某商业银行自身业务发展的 IT 系统及架构，实现金融数字化转型，具体系统建设目标为：

• TiDB +TiDB Operator 适配 K8s 联邦集群，提供金融级高可用云平台数据底座支撑能力；具备同城及两地三中心高可用能力；

• 基于 TiDB Operator ，构建 TiDB 集群运维管理功能，提供包括部署、扩缩容、备份恢复、参数变更、监控告警等云 TiDB 产品的全生命周期管理；

• TiDB 云平台具备在各种物理资源上融合部署能力，大幅节约整体使用成本。

TiDB 是平凯星辰公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性，适合高可用、强一致要求较高、数据规模较大等各种应用场景。TiDB Operator 是 K8s 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或自托管的 K8s 集群上。

基于上述要求，TiDB 云化建设整体架构如下：

整体设计特点如下：

• 系统底座构建在支持跨 Region(跨可用区同地区) 的 K8s 集群服务上；

• 为更好满足金融业要求，在 TiDB-Operator 基础上，增强 Pod 独立生命周期管理，提升在线扩容能力；新增 IP 固定等特性；

• DBASS 管控平台面向云用户、运营人员、运维人员、开发人员，提供 TiDB 云平台可视化管理、运维、监控、相关开发及测试任务；

• 提供整合、统一接口服务的 TiDB 资源池，可按需供给各类规格的 TiDB 逻辑集群，依靠 K8s 自身服务调度编排能力和 TiDB 产品真正分布式事务能力、在线扩缩容能力，实现多业务隔离，提高资源利用率。

最近几年原生 K8s 技术演进发展迅速，新功能特性层出不穷愈加丰富，从技术可行性评估，容器技术早已具备支持有状态应用的能力，但是 K8s 对数据库等有状态的应用的支持，因数据库应用的特殊性，需进行一定的适配开发，以使数据库容器化的整体架构方案和技术优势和价值达到最优。

在此背景下，基于 K8s+Operator 构筑数据库容器化方案落地过程中，将会面临以下几方面技术难度：

1. K8s 灾备能力：从近期著名云厂商多起史诗级故障来看，冗余的 K8s 集群可用性远远大于单一 K8s 集群，需要有效使用多 K8s 集群技术；

2. TiDB 高可用部署：TiDB 数据库需要保障 K8s 集群下数据一致和高可用；

3. 多业务隔离能力：需要满足该银行业务体量，支持小库归集、多业务隔离部署和资源隔离能力要求；

4.存储：容器针对无状态应用的分布式存储，并不适用于数据库应用场景；需要针对数据库容器，提供一种既满足数据冗余，又能满足 DB IO 性能要求的存储方案；

5.运维便捷性：原生 K8s 主要面向的是 CI/CD 应用场景，对数据库的运维场景支撑并不完善。方案需要有效降低运维成本，无缝对接行内现有数据库运维生态体系及工具。

1. K8s 灾备能力

随着 K8s 技术越来越成熟，企业以 K8s 为基础构建基础设施层的场景越来越多，虽然单个 K8s 集群的容量不断增加（例如：K8s v1.24 版本，单集群最多可支持 5000 个节点和 15 万个 Pod），但实际生产场景中，将所有业务都部署在一个集群会导致单点故障，当单个集群出现故障时，无法进行故障转移，将造成业务故障。

通过引入联邦集群技术，构建多个不同地域、不同形态的容器集群组成，不仅能够解决上述单点故障题，还能够实现多集群统一管理和一致性观测等。

方案示意如下：

如图，K8s 集群采用联邦集群技术，可在单个数据中心部署 3 套 K8s 集群解决 K8s 单集群单点故障；主集群上是一个启用了多集群功能的 K8s 集群，可以使用它提供的控制平面统一管理。成员集群是没有中央控制平面的普通 K8s 集群。集群管理员可通过主集群访问控制平面，管理所有成员集群，例如查看和编辑成员集群上面的资源；单个成员集群只能访问和看到自身资源。

2. TiDB 高可用部署

根据业务重要程度，该商业银行对应用项目有 A/B/C 三种分类，具体如下：

• A 类：账务处理、网银、核心交易接口平台、高等级联机交易等系统；SLA 服务可用性不低于 99.95%；

• B 类：对业务恢复时间要求不高的联机交易系统等；重要等级较高的内部管理系统、内部分析系统等；SLA 服务可用性不低于 99.3%；

• C 类：面向内部人员、内部客户使用的内部系统；全年故障时间不超 24 小时，业务中断时间不超 10 分钟

其中，重要等级为 B/C 类的应用项目，可采用单中心方案，如下图所示：

部署说明：

• 该部署模式可提供单中心高可用能力；

• K8s 兼容集群包含 3 个物理集群；均在生产 IDC；

• 应用通过负载均衡连接 TiDB 集群；

• TiDB server 无状态节点，部署在其中 2 个集群对应节点上；

• PD 部署 3 节点，每个集群一个，通过 RAFT 保证 PD 高可用；

• TiKV 通过 Raft 协议保持数据的一致性（至少默认三副本）,部署 3 节点，每个集群一个；

• TiFlash 根据业务需求选用，至少两副本保证高可用；

• 监控服务（Ngmonior）、TiDB 集中监控服务（TiDB-dashboard)、管理节点（MGT)均单 Pod 部署在一个集群,依靠 K8s 自身机制实现高可用；

• 执行备份、恢复等任务，根据各集群负载情况动态选择一个负载较小的 cluster 生成 JOB 型 Pod 执行。

重要等级为 A 类的应用项目，可采用同城双中心+异地灾备部署方案；部分高等级 B 类系统，可采用同城双中心（不需要提供异地灾备），如下图所示：

部署说明:

• 该部署模式可提供同城双中心（无 TICDC）和异地灾备高可用能力（部署 TICDC）；

• TiDB 集群分为 AZ1/AZ2;应用系统也分 AZ 部署，通过不同的负载均衡连接不同 AZ 的 TiDB server；

• TiDB server：AZ1 上两集群各部署 1 个；AZ2 上 1 个集群部署 2 个；

• PD/TIKV/监控服务/TiDB 集中监控服务/管理/备份 &&恢复 Pod 部署同上；

• TIKV（默认 3 副本）在 3 个集群上各部署 1 个；

• TiFlash 根据业务需求选用，至少两副本保证高可用；AZ1/AZ2 默认各部署一个；

• 新增 TICDC Pod，负责生产->灾备集群数据同步，可选择部署在目标端或源端。

高可用方案能力总结如下：

3. 多业务隔离能力

在 TiDB 云化平台上，首先需要保障 K8s 原生的命名空间（NameSpace）和资源配额 (ResourceQuota) 能力，保证不同业务的 TiDB 服务 Pod 能有效资源隔离，不会相互干扰；其次，需要保障基于 K8s 原生 Pod 调度能力，节点选择(NodeSelector)、污点容忍度（Tolerations）、亲和/反亲和（Affinity/AntiAffinity），可按需在不同 K8s 节点上调度各类 Pod，完美解决 TiDB 各类计算、存储服务的混合部署时互相干扰的难题。

如上图所示，在云化 TiDB 平台上，运维人员只需要为上线业务选择合适的 Pod 规格和 Pod 个数后，可以一键部署集群，而无需关心 K8s 具体的资源分配、Pod 编排调度细节。

4. 存储

数据库应用为重 IO 应用，磁盘负载很重，因此，如何保障数据库容器的磁盘 IO 和吞吐量，成为了容器数据库方案设计的重中之重；系统设计时有 2 种方案供选择：

• 使用开源云原生存储（GlusterFS/CephFS)：该方案过度依赖网络，和数据库服务抢占网络资源。

• 使用本地存储 LocalPV：数据冗余保护能力不足，运维较为复杂，但性能高，可满足数据库场景需求。

考虑到 TiDB 产品的存储服务 TiKV 会自动维护多副本（默认为三副本），架构如下：

如上图，TIKV 主要特点如下：

• Multi-Raft 架构 - 以 Region 为粒度复制副本；

• 奇数份数据副本打散分布在存储节点集群；

• 相同的数据不会在同一个节点上。

因 TIKV 天然支持高可用和自动故障转移，解决了本地存储方案中数据无法冗余的缺点，同时继承该方案能为数据库容器提供足够的磁盘 IO 和吞吐优点，兼顾数据高可用性和存储成本优化，因此经大量验证测试后，选择使用本地存储方案（localPV）来实现 TiDB 云化持久化。

5. 运维便捷

TiDB 云化平台基础架构，围绕 TiDB 服务适配设计定制开发，运维优势体现在：

• 分钟级部署 TiDB，支持单中心、同城双中心、两地三中心等多种模式；保证应用程序在开发、测试和生产环境中运行一致；

• 运维全可视化操作，简单直观，有效减少人为运维失误；

• 无缝对接行内现有容器化 TiDB 集群、TiDB 远程容灾、TiDB 镜像管理平台、TiDB 数据库管理等平台。

基于 K8s+TiDB+TiDB-Operator 构筑的云化 TiDB 平台于 24 年 5 月一次性上线了 100+ 业务应用系统，运行平稳。该项目主要收益如下：

• 验证了分布式数据库 +容器云的创新方案，一套 TiDB 集群支持多个业务，简化技术栈；

• 充分利用 K8s 和 TiDB 架构特点，实现了金融业务在容器平台的高可用；

• 解决运维自动化能力建设的瓶颈、规模化运维效率低下问题，实现自动化运维，为将来智能化运维奠定坚实基础；

• 较 OP 部署模式，数据库部署硬件资源节约 80% 以上；解决了传统部署模式下总体拥有成本高、资源利用率不高、部署密度低等问题；

• 解决了传统虚拟化部署产生的基础环境不稳定、不支持资源弹性伸缩以及 Pod 是否高效稳定运行有状态类应用等问题。