wordpress删除不了插件/seo模拟点击工具

导读

本文介绍了某商业银行基于 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 是否高效稳定运行有状态类应用等问题。