--- title: 商业银行基于容器云的分布式数据库架构设计与创新实践 date: '2024-12-05T19:31:53+08:00' status: publish permalink: /blog/design-and-innovative-practice-of-distributed-database-architecture-based-on-container-cloud author: 'Huini Cao' excerpt: '本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台，重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。' type: post id: 8356 category: - 案例实践 tag: - k8s - TiDB - 分布式数据库 post_format: [] profile: - 崔佳宁 --- 导读 -- 本文介绍了某商业银行基于 TiDB 和 Kubernetes(简称 K8s) 构建的云化分布式数据库平台，重点解决了传统私有部署模式下的高成本、低资源利用率及运维复杂等问题。 通过引入 TiDB Operator 自动化管理与容器化技术，银行能够实现多个业务系统的高可用、弹性扩展与自动化运维，极大提高了运营效率与资源利用率。本文还详细阐述了平台架构设计、面临的技术挑战及创新解决方案，展示了 TiDB 在金融行业数字化转型中的应用前景。 项目背景 ---- 某商业银行新一代业务金融云建设，以某国有大行新一代业务解决方案为建设蓝本，目标是利用新架构满足业务快速迭代的要求，提供较强的业务处理能力和灵活扩展能力，加快数字化转型和业务创新等，同时满足降本增效要求。 **其中，选定** **TiDB** **分布式数据库集群的上云应用系统合计超过 100 个，涉及核心、金融服务、渠道管理/整合、中间业务、个人贷款、对公贷款、组件服务、公共业务管理、数据分析等多个银行重要业务领域** ，系统重要等级高，需要具备两地三中心部署、同城双活能力，且同城和异地 RPO、RTO 满足系统对应的高可用和灾备要求。按原私有部署模式（OP)，该项目常规需要物理机 300-600 台，考虑客户自身运营规模，系统建设迫切需要建立成本低、使用便捷的 TiDB 云化平台支持服务体系，全面减低 TiDB 部署、测试、运维等成本。 目前业内主流的 OP（私有）TiDB 部署方案，基于独立物理服务器，存在以下问题： ![存在问题](https://img1.pingcap.com/files/2024/12/20241209080453998.png)- **数据库使用成本高** ：每一个业务应用都需要一套独立的数据库，部署时需要 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 云化建设整体架构如下： ![TiDB 云化建设整体架构](https://img1.pingcap.com/files/2024/12/20241209080610837.png)整体设计特点如下： - 系统底座构建在支持跨 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 集群采用联邦集群技术](https://img1.pingcap.com/files/2024/12/20241209080700334.png)如图，K8s 集群采用联邦集群技术，可在单个数据中心部署 3 套 K8s 集群解决 K8s 单集群单点故障；主集群上是一个启用了多集群功能的 K8s 集群，可以使用它提供的控制平面统一管理。成员集群是没有中央控制平面的普通 K8s 集群。集群管理员可通过主集群访问控制平面，管理所有成员集群，例如查看和编辑成员集群上面的资源；单个成员集群只能访问和看到自身资源。 ### 2.TiDB 高可用部署 根据业务重要程度，该商业银行对应用项目有 A/B/C 三种分类，具体如下： - **A 类：** 账务处理、网银、核心交易接口平台、高等级联机交易等系统；SLA 服务可用性不低于 99.95%； - **B 类：** 对业务恢复时间要求不高的联机交易系统等；重要等级较高的内部管理系统、内部分析系统等；SLA 服务可用性不低于 99.3%； - **C 类：** 面向内部人员、内部客户使用的内部系统；全年故障时间不超 24 小时，业务中断时间不超 10 分钟 其中，重要等级为 B/C 类的应用项目，可采用 **单中心方案** ，如下图所示： ![单中心方案](https://img1.pingcap.com/files/2024/12/20241209080728266.png)部署说明： - 该部署模式可提供单中心高可用能力； - 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 类系统，可采用 **同城双中心（不需要提供异地灾备）** ，如下图所示： ![同城双中心（不需要提供异地灾备）](https://img1.pingcap.com/files/2024/12/20241209080856879.png)部署说明: - 该部署模式可提供同城双中心（无 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，负责生产->灾备集群数据同步，可选择部署在目标端或源端。 高可用方案能力总结如下： ![高可用方案能力总结](https://img1.pingcap.com/files/2024/12/20241209081012814.png)### 3.多业务隔离能力 在 TiDB 云化平台上，首先需要保障 **K8s 原生的命名空间（NameSpace）和资源配额 (ResourceQuota) 能力** ，保证不同业务的 TiDB 服务 Pod 能有效资源隔离，不会相互干扰；其次，需要保障 **基于 K8s 原生 Pod 调度能力，** 节点选择(NodeSelector)、污点容忍度（Tolerations）、亲和/反亲和（Affinity/AntiAffinity），可按需在不同 K8s 节点上调度各类 Pod，完美解决 TiDB 各类计算、存储服务的混合部署时互相干扰的难题。 ![多业务隔离能力](https://img1.pingcap.com/files/2024/12/20241209081045301.png)如上图所示，在云化 TiDB 平台上，运维人员只需要为上线业务选择合适的 Pod 规格和 Pod 个数后，可以一键部署集群，而无需关心 K8s 具体的资源分配、Pod 编排调度细节。 ### 4. 存储 数据库应用为重 IO 应用，磁盘负载很重，因此，如何保障数据库容器的磁盘 IO 和吞吐量，成为了容器数据库方案设计的重中之重；系统设计时有 2 种方案供选择： - **使用开源云原生存储（GlusterFS/CephFS)：** 该方案过度依赖网络，和数据库服务抢占网络资源。 - **使用本地存储 LocalPV：** 数据冗余保护能力不足，运维较为复杂，但性能高，可满足数据库场景需求。 考虑到 TiDB 产品的存储服务 TiKV 会自动维护多副本（默认为三副本），架构如下： ![存储](https://img1.pingcap.com/files/2024/12/20241209081120636.png)如上图，TIKV 主要特点如下： - Multi-Raft 架构 - 以 Region 为粒度复制副本； - 奇数份数据副本打散分布在存储节点集群； - 相同的数据不会在同一个节点上。 因 TIKV 天然支持高可用和自动故障转移，解决了本地存储方案中数据无法冗余的缺点，同时继承该方案能为数据库容器提供足够的磁盘 IO 和吞吐优点，兼顾数据高可用性和存储成本优化，因此经大量验证测试后，选择使用本地存储方案（localPV）来实现 TiDB 云化持久化。 ### 5.运维便捷 ![运维便捷](https://img1.pingcap.com/files/2024/12/20241209081146522.png)TiDB 云化平台基础架构，围绕 TiDB 服务适配设计定制开发，运维优势体现在： - 分钟级部署 TiDB，支持单中心、同城双中心、两地三中心等多种模式；保证应用程序在开发、测试和生产环境中运行一致； - 运维全可视化操作，简单直观，有效减少人为运维失误； - 无缝对接行内现有容器化 TiDB 集群、TiDB 远程容灾、TiDB 镜像管理平台、TiDB 数据库管理等平台。 系统收益 ---- 基于 K8s+TiDB+TiDB-Operator 构筑的云化 TiDB 平台于 24 年 5 月一次性上线了 100+ 业务应用系统，运行平稳。该项目主要收益如下： - 验证了分布式数据库 +容器云的创新方案，一套 TiDB 集群支持多个业务，简化技术栈； - 充分利用 K8s 和 TiDB 架构特点，实现了金融业务在容器平台的高可用； - 解决运维自动化能力建设的瓶颈、规模化运维效率低下问题，实现自动化运维，为将来智能化运维奠定坚实基础； - 较 OP 部署模式，数据库部署硬件资源节约 80% 以上；解决了传统部署模式下总体拥有成本高、资源利用率不高、部署密度低等问题； - 解决了传统虚拟化部署产生的基础环境不稳定、不支持资源弹性伸缩以及 Pod 是否高效稳定运行有状态类应用等问题。