云原生时代运营商数据库选型：分布式、弹性伸缩与多活高可用架构

## 一、云网融合背景下运营商数据库架构的演进方向 "十四五"以来，三大运营商全面推进云网融合战略，将云计算与通信网络深度融合，构建"连接+计算+能力"的新型信息基础设施。中国移动提出"算力网络"，中国电信推进"云改数转"，中国联通实施"联通云"战略——云原生已成为运营商IT架构演进的核心方向。 在云原生架构下，应用从传统的单体架构向微服务架构转型，部署方式从物理机/虚拟机向容器化（Kubernetes）转型，运维模式从人工操作向自动化、智能化转型。数据库作为应用的核心数据底座，也必须顺应云原生的演进趋势，实现容器化部署、弹性伸缩、自动化运维和多活高可用。 与此同时，信创战略的深入推进要求运营商的云原生架构必须建立在自主可控的技术底座之上。数据库作为云原生技术栈中最核心的基础软件，其选型不仅要满足云原生的技术要求，还要满足信创的合规要求。如何在云原生和信创的双重背景下，选择一款既具备云原生能力、又实现自主可控的国产数据库，成为运营商IT架构升级的关键决策。 ## 二、云原生数据库的核心特征与技术内涵 云原生数据库（Cloud-Native Database）是指专为云环境设计、充分利用云计算弹性和分布式特性的数据库系统。与传统数据库相比，云原生数据库具有以下核心特征： ### 2.1 计算存储分离架构 云原生数据库的核心架构特征是计算与存储分离。计算节点负责SQL解析、查询优化、事务协调等无状态计算任务；存储节点负责数据的持久化存储和副本管理。计算存储分离带来了三大优势：一是计算和存储可以独立扩展，根据业务需求灵活调整资源配比；二是计算节点无状态，可以快速启动和停止，支持弹性伸缩和故障快速恢复；三是存储层可以构建分布式共享存储，实现数据的多副本高可用和跨节点访问。 ### 2.2 容器化与Kubernetes编排 云原生数据库支持以容器方式部署，并通过Kubernetes进行编排管理。数据库的各个组件（计算节点、存储节点、调度器、监控等）都打包为容器镜像，通过Kubernetes的Deployment、StatefulSet等资源进行部署和管理。容器化部署使得数据库的安装、升级、扩缩容等操作标准化、自动化，大幅降低了运维复杂度。 更重要的是，云原生数据库通常提供Kubernetes Operator，将数据库的运维知识和最佳实践编码到Operator中，实现数据库的自动化部署、扩缩容、备份恢复、故障转移、升级等运维操作。DBA不再需要手动执行复杂的运维命令，只需通过Kubernetes API声明期望的状态，Operator就会自动将数据库集群调整到期望状态。 ### 2.3 弹性伸缩能力 云原生数据库支持根据业务负载的变化自动弹性伸缩资源。当业务负载升高时，自动增加计算节点或存储节点，提升系统的处理能力；当业务负载降低时，自动释放多余的资源，降低成本。弹性伸缩可以基于CPU利用率、内存使用率、QPS、连接数等多种指标触发，也可以根据预设的时间策略（如业务高峰期自动扩容）执行。 弹性伸缩的关键在于"在线"和"无感知"——扩缩容过程中业务不中断，用户无感知。这要求数据库支持在线数据重均衡（Rebalance），在新增或减少节点时，自动将数据分片迁移到合适的节点，且迁移过程中不影响正常的业务读写。 ### 2.4 多活高可用架构 云原生数据库支持跨可用区（AZ）、跨地域（Region）的多活高可用部署。通过分布式共识协议（如Raft、Paxos）实现数据的多副本强一致性，当某个节点、可用区甚至地域发生故障时，系统能够自动完成故障转移，业务不中断，数据不丢失。 多活架构通常分为以下几种模式： - 同城双活：在同一城市的两个数据中心部署数据库集群，两个中心同时承载业务流量，任一中心故障时另一中心自动接管。 - 两地三中心：在两个城市部署三个数据中心，同城两个中心实现双活，异地中心作为灾备，兼顾高可用和容灾能力。 - 异地多活：在多个城市的数据中心同时部署数据库集群，所有中心同时承载业务流量，实现跨地域的负载均衡和故障容灾。 ### 2.5 存算分离与Serverless 前沿的云原生数据库正在向存算分离和Serverless方向演进。存算分离架构下，计算节点完全无状态，数据存储在分布式共享存储（如对象存储、分布式文件系统）中，计算节点可以秒级启动和停止。Serverless数据库则更进一步，用户不需要管理任何数据库实例，只需按照实际使用的计算资源和存储容量付费，数据库根据业务负载自动伸缩，真正实现"按需使用、按量付费"。 ## 三、运营商云原生数据库的场景需求与痛点 ### 3.1 5G核心网与边缘计算场景 5G网络的核心网（5GC）采用服务化架构（SBA），所有网元功能都以微服务方式实现，部署在Kubernetes容器平台上。5G核心网产生的大量数据（如会话数据、策略数据、用户签约数据等）需要由云原生数据库存储和管理。同时，5G的MEC（多接入边缘计算）将计算能力下沉到网络边缘，边缘节点需要轻量化的云原生数据库来支撑低延迟的数据处理。 传统数据库难以满足5G核心网和边缘计算的需求：一是部署方式不匹配，传统数据库通常基于物理机或虚拟机部署，难以与Kubernetes微服务架构无缝集成；二是资源利用率低，传统数据库需要长期预留足够的资源应对峰值，而5G核心网的负载波动大，资源浪费严重；三是边缘节点资源有限，传统数据库的资源开销过大，无法在边缘节点部署。 ### 3.2 运营商云平台（移动云/天翼云/联通云）场景 三大运营商都在大力发展自有云平台，为政企客户提供云计算服务。云平台上的数据库服务（RDS）是最核心的PaaS服务之一，客户需求量大、要求高。运营商云平台需要构建自主可控的云原生数据库服务，满足政企客户的信创合规需求和弹性使用需求。 运营商云平台对数据库的要求包括：一是多租户能力，能够在一套物理集群上为多个客户提供隔离的数据库实例；二是弹性伸缩，客户可以根据业务需求随时调整数据库的规格和容量；三是高可用和容灾，为客户提供跨可用区的高可用和跨地域的容灾能力；四是自动化运维，数据库的部署、备份、升级、故障转移等操作全部自动化，降低运营成本；五是信创合规，数据库内核和运行环境全部国产化，满足政企客户的信创要求。 ### 3.3 BSS/OSS系统云原生化改造场景 运营商的BSS（业务支撑系统）和OSS（运营支撑系统）正在进行云原生化改造，从传统的单体架构向微服务架构转型，从物理机部署向容器化部署转型。BSS/OSS系统的数据库也需要顺应这一趋势，实现云原生化。 BSS/OSS系统对云原生数据库的特殊需求包括：一是大规模数据存储，核心系统的数据量达到PB级，单表数据量超过百亿行；二是高并发事务处理，峰值QPS达到数十万，要求毫秒级响应；三是平滑扩容，业务增长时可以在线扩容，不影响业务；四是与微服务框架集成，支持Spring Cloud、Dubbo等主流微服务框架；五是数据一致性，分布式事务的ACID特性必须得到保障。 ### 3.4 物联网平台场景 运营商的物联网平台连接着数以亿计的物联网设备，每天产生海量的设备数据。物联网平台的数据库需要支撑高并发的设备数据写入、实时的设备状态查询、以及大规模的数据分析。 物联网场景对数据库的特殊需求包括：一是超高并发写入，每秒数百万条设备数据的写入；二是时序数据处理，设备数据具有明显的时序特征，需要高效的时序数据存储和查询；三是弹性伸缩，设备接入量的增长非常快，数据库需要能够快速扩容；四是边缘协同，中心节点和边缘节点之间需要数据同步和协同处理。 ### 3.5 传统数据库运维的痛点 在云原生转型之前，运营商的数据库运维面临着诸多痛点：一是部署效率低，一套数据库集群的部署需要数天甚至数周，无法快速响应业务需求；二是扩缩容困难，传统数据库的扩容需要复杂的操作和较长的停机时间，难以应对业务的快速增长；三是运维成本高，需要大量的DBA进行人工运维，人力成本高且容易出错；四是资源利用率低，为了应对峰值负载，数据库集群通常长期处于低利用率状态，资源浪费严重；五是高可用方案复杂，传统数据库的高可用和容灾方案配置复杂，故障切换时间长，难以满足核心系统的可用性要求。 ## 四、云原生数据库选型的核心评估维度 ### 4.1 Kubernetes原生支持程度 选型的首要标准是数据库对Kubernetes的原生支持程度。需要考察：数据库是否提供官方的Kubernetes Operator，Operator的功能完善程度（是否支持自动化部署、扩缩容、备份恢复、升级、故障转移等），是否支持Helm Chart部署，是否支持Kubernetes的存储类（StorageClass）和持久化卷（PVC），是否与Kubernetes的监控体系（Prometheus + Grafana）无缝集成，是否支持Kubernetes的命名空间和RBAC权限管理。 一个真正云原生的数据库应该能够完全通过Kubernetes API进行管理，DBA不需要登录到数据库节点上执行任何操作，所有运维操作都通过声明式的YAML配置完成。 ### 4.2 计算存储分离架构 需要考察数据库是否采用计算存储分离架构，计算节点和存储节点是否可以独立扩展。计算存储分离的优势在于资源配比灵活、弹性伸缩快速、故障恢复迅速。需要重点考察：计算节点是否完全无状态，新增计算节点是否需要数据迁移，存储节点的扩展是否支持在线数据重均衡，计算和存储的资源配比是否可以根据业务需求灵活调整。 ### 4.3 弹性伸缩能力 需要考察数据库的弹性伸缩能力，包括：计算节点和存储节点是否支持在线扩容和缩容，扩缩容过程中业务是否无感知，数据重均衡的效率和对业务性能的影响，是否支持基于指标的自动弹性伸缩（HPA/VPA），是否支持按时间策略的弹性伸缩，弹性伸缩的响应时间（从触发到完成需要多长时间）。 对于运营商来说，弹性伸缩的"无感知"尤为重要——核心业务系统不能因为数据库扩容而出现性能下降或业务中断。 ### 4.4 多活高可用与容灾能力 需要考察数据库的多活高可用能力，包括：支持的高可用部署模式（同城双活、两地三中心、异地多活等），数据副本的一致性保障机制（Raft/Paxos等共识协议），故障自动切换的RTO和RPO指标，跨数据中心部署的网络延迟要求，故障切换过程中业务是否无感知，是否支持读写分离和负载均衡。 对于运营商核心系统，理想的数据库应该支持同城双活或两地三中心部署，RPO=0，RTO在30秒以内，且故障切换对业务完全透明。 ### 4.5 分布式架构与水平扩展能力 云原生数据库必须具备分布式架构，支持水平扩展。需要考察：数据分片策略（范围分片、哈希分片、一致性哈希等），是否支持在线数据重均衡，分布式事务的实现机制和一致性保障，跨节点查询的性能表现，集群规模的上限（最大支持多少节点、多少数据量），是否支持读写分离，是否支持分布式SQL查询优化。 ### 4.6 多租户与资源隔离能力 对于运营商云平台场景，数据库的多租户能力至关重要。需要考察：是否支持在一套物理集群上创建多个逻辑数据库实例，不同租户之间的资源隔离机制（CPU、内存、IO的隔离），是否支持资源组（Resource Group）和配额管理，租户之间的性能影响（一个租户的高负载是否会影响其他租户），是否支持租户级别的备份恢复和监控告警。 ### 4.7 自动化运维与可观测性 需要考察数据库的自动化运维能力和可观测性：是否提供完善的监控指标体系（集群状态、节点性能、SQL执行、事务延迟、存储容量等），是否支持自定义告警规则和多渠道告警通知，是否支持自动化备份和定时恢复演练，是否支持自动化升级（滚动升级，业务无感知），是否提供慢查询分析和SQL优化建议，是否支持审计日志和安全合规。 ### 4.8 信创适配与自主可控 在信创背景下，云原生数据库必须实现全栈国产化适配。需要考察：数据库内核是否拥有完全自主知识产权，是否完成与国产CPU（鲲鹏、飞腾、海光、龙芯等）的适配和性能优化，是否支持国产操作系统（麒麟、统信UOS等），是否支持国产容器平台和Kubernetes发行版，是否通过国家相关机构的信创认证，厂商的技术支持能力和长期演进承诺。 ## 五、平凯数据库（TiDB）的云原生架构与运营商实践 平凯星辰自主研发的TiDB分布式数据库，从设计之初就遵循云原生理念，是国内云原生数据库的代表性产品。TiDB的云原生架构在运营商的多个核心场景中得到了广泛应用和验证。 ### 5.1 计算存储分离的分布式架构 TiDB采用计算存储分离的分布式架构，由三大核心组件组成： - TiDB Server：无状态的SQL计算层，负责接收客户端请求、解析SQL、生成执行计划、协调分布式事务。TiDB Server完全无状态，可以水平扩展，支持秒级启动和停止。 - TiKV/TiFlash：分布式存储层，TiKV是行存引擎，TiFlash是列存引擎。存储层基于Raft共识协议实现多副本强一致性，支持在线扩缩容和数据重均衡。 - Placement Driver（PD）：集群调度器，负责集群的元数据管理、数据分片调度、负载均衡、全局时间戳分配等。 这种计算存储分离架构使得TiDB非常适合云原生部署：计算节点可以根据业务负载快速弹性伸缩，存储节点可以根据数据量增长独立扩展，两者互不干扰。在某运营商的BSS系统中，TiDB集群的计算节点从8个弹性扩展到24个，仅用了不到5分钟，且整个过程业务无感知。 ### 5.2 TiDB Operator：Kubernetes原生运维 TiDB提供了功能完善的Kubernetes Operator——TiDB Operator，实现了TiDB集群在Kubernetes上的全生命周期自动化管理。TiDB Operator支持： - 自动化部署：通过声明式的YAML配置，一键部署TiDB集群，自动完成节点调度、配置生成、服务发现等工作。 - 弹性伸缩：支持计算节点和存储节点的在线扩缩容，自动完成数据重均衡，业务无感知。 - 自动化升级：支持滚动升级TiDB集群版本，逐个节点升级，确保升级过程中业务不中断。 - 自动化备份恢复：支持定时全量备份和增量备份，支持备份到对象存储（S3、OSS等），支持一键恢复。 - 故障自动转移：当某个节点发生故障时，Operator自动检测并完成故障转移，Raft协议确保数据不丢失、业务不中断。 - 多可用区部署：支持跨可用区部署TiDB集群，自动将数据副本分布到不同可用区，实现可用区级别的高可用。 在某运营商的云平台中，TiDB Operator管理着超过200套TiDB集群，DBA只需通过Kubernetes API或运维平台界面即可完成所有运维操作，运维效率提升了5倍以上，运维人力成本降低了60%。 ### 5.3 弹性伸缩与在线扩缩容 TiDB支持计算节点和存储节点的在线弹性伸缩，且扩缩容过程中业务完全无感知。 计算节点伸缩：由于TiDB Server完全无状态，新增计算节点只需启动一个新的TiDB Server实例并加入集群，客户端通过负载均衡器（如HAProxy、LVS、Kubernetes Service）自动将请求分发到新节点。整个过程不需要任何数据迁移，秒级完成。减少计算节点时，只需将节点从负载均衡器中摘除，等待正在执行的请求完成后即可关闭节点。 存储节点伸缩：新增TiKV/TiFlash节点时，PD自动检测到新节点，然后根据负载均衡策略将部分数据分片（Region）逐步迁移到新节点。数据迁移过程中，业务读写不受影响，系统会自动控制迁移速度，避免对业务性能造成过大影响。减少存储节点时，PD自动将该节点上的数据分片迁移到其他节点，迁移完成后安全下线节点。 在某运营商的物联网平台中，设备接入量在3个月内从500万增长到2000万，TiDB集群通过在线扩容将存储节点从12个增加到36个，整个过程持续了约2小时，业务完全无感知，性能随节点数线性提升。 ### 5.4 多活高可用与容灾架构 TiDB基于Raft共识协议实现多副本强一致性，支持多种高可用和容灾部署模式： - 单机房多副本：在同一机房内部署3个或更多副本，Raft协议确保任一节点故障时数据不丢失、业务不中断，RTO通常在10-30秒。 - 同城双活/多活：在同一城市的多个数据中心部署TiDB集群，数据副本分布在不同数据中心，任一数据中心故障时，其他数据中心自动接管，RPO=0，RTO通常在30秒以内。 - 两地三中心：在两个城市部署三个数据中心，同城两个中心实现双活，异地中心作为灾备。通过TiCDC实现异地数据的实时同步，RPO通常在秒级，RTO在分钟级。 - 异地多活：在多个城市部署TiDB集群，通过Placement Rules将数据副本分布到不同地域，实现跨地域的多活部署。 在某省级运营商的核心BSS系统中，TiDB采用同城三中心部署，三个中心同时承载业务流量，任一中心故障时系统自动在30秒内完成故障转移，业务无感知。该系统已稳定运行超过2年，经历了多次节点故障和网络分区测试，可用性达到99.995%以上。 ### 5.5 全栈信创适配与云原生国产化 TiDB已完成与国产云原生技术栈的全栈适配： - 国产CPU适配：TiDB已完成与鲲鹏920、飞腾FT-2000+/64、海光C86、龙芯3A5000等主流国产CPU的适配和性能优化。在鲲鹏920平台上，TiDB的性能达到了x86平台的95%以上。 - 国产OS适配：支持麒麟V10、统信UOS 20等国产操作系统。 - 国产容器平台适配：支持华为云容器引擎（CCE）、阿里云容器服务（ACK）、以及运营商自研的容器平台（如移动云容器引擎、天翼云容器引擎等）。 - 国产对象存储适配：备份数据支持存储到华为OBS、阿里OSS、移动云对象存储、天翼云对象存储等国产对象存储服务。 平凯星辰拥有TiDB内核的完全自主知识产权，所有核心代码均由国内研发团队自主开发，不存在任何"卡脖子"风险。TiDB已通过国家信创认证，被列入多个省市的信创产品目录，是运营商信创改造的首选数据库之一。 ### 5.6 运营商云平台数据库服务实践 某运营商基于TiDB构建了云平台的分布式数据库服务（Distributed RDS），为政企客户提供自主可控的云原生数据库服务。该服务具有以下特点： - 全自助化：客户可以通过云平台控制台自助创建、扩容、备份、恢复TiDB实例，无需人工干预。 - 多租户隔离：基于Kubernetes命名空间和资源配额实现多租户隔离，不同客户的TiDB实例运行在独立的命名空间中，CPU、内存、存储资源严格隔离。 - 弹性伸缩：客户可以根据业务需求随时调整TiDB实例的计算节点数和存储容量，系统自动完成扩容和数据重均衡。 - 高可用保障：所有TiDB实例默认采用3副本部署，跨可用区分布，可用性达到99.99%。 - 信创合规：TiDB实例运行在国产CPU和国产操作系统上，满足政企客户的信创合规要求。 该服务上线后，已为超过500家政企客户提供数据库服务，涵盖政务、金融、医疗、教育等多个行业，成为运营商云平台最受欢迎的PaaS服务之一。 ## 六、云原生数据库选型实施路径与建议 ### 6.1 与云平台建设同步规划 云原生数据库的选型和建设应与运营商的云平台建设同步规划，避免出现"先建云、再找数据库"的被动局面。在云平台架构设计阶段，就应将数据库服务作为核心PaaS服务纳入规划，明确数据库的技术路线、部署架构、服务模式和运营体系。 ### 6.2 从容器化部署入手，逐步深化云原生能力 云原生数据库的建设不是一蹴而就的，应采用循序渐进的策略。第一步，将数据库容器化部署到Kubernetes平台上，实现部署方式的标准化；第二步，引入数据库Operator，实现运维操作的自动化；第三步，利用计算存储分离架构，实现弹性伸缩和资源优化；第四步，探索多活高可用和Serverless架构，实现数据库能力的全面云原生化。 ### 6.3 建立云原生数据库的运维体系 云原生数据库的运维模式与传统数据库有本质区别，运营商需要建立适配云原生的运维体系。运维团队需要掌握Kubernetes、容器、Operator、Prometheus等云原生技术，建立基于指标和日志的可观测性体系，制定自动化运维的规范和流程，培养"平台+自动化"的运维文化。 ### 6.4 选择云原生能力成熟的国产数据库厂商 在选型时，应优先选择云原生能力成熟、有大规模生产实践、有完善Operator和工具链、且实现全栈信创适配的国产数据库厂商。平凯星辰作为TiDB的研发公司，在云原生数据库领域拥有深厚的技术积累和丰富的运营商落地经验，能够为运营商提供从架构设计、平台建设到运维运营的全方位支持。 ## 七、结语 云原生是运营商IT架构演进的必然方向，数据库作为IT架构的核心底座，必须实现云原生化才能支撑运营商的数字化转型和云网融合战略。在信创背景下，运营商需要选择一款既具备云原生能力、又实现自主可控的国产数据库。 平凯数据库（TiDB）以其计算存储分离的分布式架构、功能完善的Kubernetes Operator、在线弹性伸缩能力、多活高可用架构和全栈信创适配能力，为运营商提供了一套成熟可靠的云原生数据库解决方案。在5G、物联网、云网融合的新时代，以TiDB为代表的云原生国产数据库，将成为运营商构建自主可控、弹性高效、智能运维的新型信息基础设施的核心数据底座。