项目背景

唯品会是中国领先的品牌特卖电商平台，以独特的"限时特卖"模式服务数亿消费者，在大促期间对基础设施的弹性和稳定性要求极高。随着业务规模不断扩大，基础架构团队逐步积累了 Kafka、Elasticsearch、MySQL、MariaDB 等多种数据库引擎，并在 Kubernetes 上构建了数千集群、3000 个以上实例的生产环境。

如何在精干的团队配置下，高效管理如此庞大且异构的数据库体系，成为唯品会基础架构团队亟需破解的核心课题。

面临的挑战

技术栈割裂，运维成本高昂。 Kafka、Elasticsearch、MySQL 的运维工具、配置文件、监控指标截然不同，DBA 团队需要维护多套脚本和自动化系统，新引擎接入周期长、学习曲线陡峭。

Kubernetes 原生能力不足以支撑有状态应用。 StatefulSet 难以完美处理数据库的复杂拓扑，声明式 API 对传统 DBA 不够直观，"重启指定实例"、"主备切换"等精细操作实施困难。

大规模生产的可控性焦虑。 在超大规模实例下，全自动滚动升级存在"雪崩"风险，生产环境需要精确控制升级节奏，并与私有 DNS、CMDB 等周边系统联动。同时，大量运行在物理机上的核心数据库无法承受"停机上云"的代价，存量迁移路径必须平滑可控。

为什么选择 KubeBlocks

经过与自研 Operator 方案的对比评估，唯品会选择了 KubeBlocks。核心原因在于三个维度的显著优势：

多引擎统一 API。 KubeBlocks 通过 Cluster / Component 统一 API 屏蔽了不同引擎的差异，一个团队即可管理所有数据库引擎，无需为每种引擎单独维护一套运维体系。

Addon 机制大幅降低接入成本。 相比自研 Operator 需要 2-3 个月的开发周期，基于 KubeBlocks Addon 规范接入新引擎只需 1-2 周，无需学习 Go 语言，只需编写声明式 YAML 配置即可完成接入，且支持灵活注入 Sidecar、自定义初始化逻辑和参数列表。

OpsRequest 开箱即用。 水平扩缩容、垂直扩缩容、版本升级、启停集群、故障重建等 Day-2 运维操作均有标准封装，自建平台可直接将这些操作转换为 API 调用，显著降低误操作风险。

建设方案

多引擎落地实践。 Kafka 直接使用官方 Addon 部署，结合私有容器网络方案和私有 DNS，将 Pod IP 直接通过 DNS 解析交付业务。Elasticsearch 基于 Addon 规范自研了唯品会定制版，支持更多功能配置和生产规模集群；版本升级只需更新 ComponentVersion，配合 Upgrade OpsRequest 实现可控升级。

存量 MySQL/MariaDB 的混合架构平滑迁移。 针对大量运行在物理机上的核心复制集，唯品会创新性地采用"物理机 + 容器混合复制集"方案：不做全量迁移，而是让容器 Slave 加入物理机主从复制集，读流量逐步切至容器，主从选举继续由外部 MHA 负责，KubeBlocks 专注生命周期管理。这种渐进式路径对上层业务完全透明，彻底规避了停机迁移风险。

基于 OnDelete 策略的可控滚动升级。 面对超大规模实例，唯品会放弃默认的自动滚动策略，采用 OnDelete 配置，由自研运维平台编排每个 Pod 的升级顺序：先摘除 DNS 流量、等待归零，再删除 Pod，新 Pod 就绪并通过健康检查后注册 DNS，再推进下一个节点。任意环节发现异常可立即暂停，实现整个滚动过程的自主可控。

项目收益

经过在唯品会大规模生产环境的验证，KubeBlocks 展现了出色的稳定性和扩展性。Kafka、Elasticsearch、MySQL、MariaDB 四种引擎均已稳定运行，由同一个基础架构团队统一维护。

多引擎统一管理使学习成本大幅降低，OpsRequest 封装将误操作风险降至最低。本地存储故障场景下，RebuildInstance 能力将故障恢复时间从小时级缩短至分钟级，并可将实例精确迁移至指定节点，实现主机运维期间业务不中断。启停集群（Stop/Start）机制在大促期间通过批量停止非核心集群，瞬间为核心交易链路释放资源，实现精准的峰值资源调度。

唯品会也将持续参与 KubeBlocks 社区建设，贡献定制 Addon 并反馈生产实践，推动数据库云原生技术共同演进。