引言在云原生浪潮席卷全球的今天各行各业都在加速数字化转型。对于构建云数据库服务DBaaS的团队而言如何在保证高性能、高可用性的同时快速迭代、降低运维复杂度成为了核心挑战。今天我们有幸邀请到移动云大云海山数据库管控系统的架构师丁顺他将与我们分享移动云团队如何利用 KubeBlocks在资源与时间有限的情况下高效构建起其核心 DBaaS 服务的故事。他的经历不仅展现了 KubeBlocks 在实际生产环境中的强大价值也为我们带来了对云原生数据库管理未来发展的深刻洞察。第一部分与移动云 DBaaS 架构师丁顺对话Q1丁顺您好请您简单介绍一下自己和您的工作丁顺大家好我是丁顺目前在移动云担任大云海山数据库管控系统的架构师。我的主要职责是规划和实现移动云自研数据库大云海山数据库的云产品化为用户提供高效、稳定的 DBaaS 服务。Q2移动云在数据库领域扮演怎样的角色丁顺移动云是中国移动旗下的云计算品牌致力于提供全面的云服务。我们是云服务提供商主要深耕于云原生数据库领域在 Kubernetes 之上构建大云海山数据库的 DBaaS 服务以满足不同企业级客户对高性能、高可靠数据库的需求。Q3刚刚您提到了移动云自研的大云海山数据库。能否展开讲讲这是一款怎样的数据库产品丁顺大云海山数据库是移动云自研的数据库是中国移动重点打造的自有品牌。它具备高扩展、高性能、高可用、高安全及低成本等特性并全面适配主流国产芯片和操作系统旨在为业界提供即开即用、安全可靠的数据库服务。值得一提的是今年 8 月大云海山数据库顺利通过了国家安全可靠测评这是国家对其产品能力、企业资质、运维能力、未来发展的认可。Q4能否分享一下当前支撑移动云 DBaaS 平台的基础技术栈丁顺我们的核心技术栈完全基于 Kubernetes 构建。作为云提供商我们利用 Kubernetes 的强大编排和管理能力为大云海山数据库提供稳定、弹性的运行环境。我们目前专注于构建和维护大云海山数据库的 DBaaS 服务确保其在云环境中能够提供业界领先的数据库管理能力。第二部分困境与破局为什么是 KubeBlocksQ1您是如何发现 KubeBlocks 的丁顺当时我们正面临从零开始构建大云海山数据库的 DBaaS 管控系统的巨大挑战时间紧、人力缺。在技术选型调研阶段有同事推荐了 KubeBlocks这为我们打开了一扇新的大门。Q2在接触 KubeBlocks 之前移动云在 Kubernetes 上构建数据库服务时主要面临哪些核心痛点和挑战丁顺痛点非常明显可以总结为内忧和外患。首先是技术上的“烟囱式开发”和 “伪云原生”问题。以往每引入一种新数据库就得从头写 Operator 和 CRD不仅重复造轮子而且质量参差不齐。很多自研 Operator 只是把数据库简单的“搬”上 K8s却没解决共享内存、ulimit 等深层问题导致性能不如人意。其次是项目背景带来的资源挑战。当时我们需要在极短的时间内、用极其有限的人力从零构建出大云海山数据库的 DBaaS 服务。同时我们还希望它不仅是为了解决眼下的问题更要是一个能适配多种引擎的通用管控底座。这对我们当时的团队来说几乎是一个“不可能三角”。Q3这听起来确实极具挑战。那么KubeBlocks 是凭借什么特性打动了您让您觉得它可以解决这些难题丁顺主要是它的“低代码模式”、“通用架构”和“强大的抽象模型”完美契合了我们的需求。第一它把数据库复杂的生命周期管理抽象成了统一的 Operator我们只需要编写配置文件的形式开发 Addon插件就能快速接入新引擎。这直接将 Operator 开发的复杂度降维了极大地缓解了我们人力不足的压力。第二我们在做通用性 DBaaS 管控系统设计的架构选型时其实对比过三种架构方案KubeBlocks 的设计理念即在 Operator 层展现通用能力与我们构想的终极方案不谋而合。它不仅能救火解决上线时间问题又符合我们将来的长期战略构建通用底座。这种高度的契合促使我们最终决定将其作为核心底座。第三大云海山数据库作为一个持续演进的自研数据库产品它的内核架构需要不断迭代以适应新的业务场景。这对底层的 DBaaS 管控系统提出了极高的要求Operator 必须具备极强的灵活性以应对未来架构的升级变化。这也是我们选择 KubeBlocks 的关键原因——其强大的抽象模型能够灵活适配大云海山数据库未来的架构演进为我们持续迭代、提供稳定的云上服务提供了坚实的底座保障。第三部分从 0 到 1 的落地实践与价值Q4目前 KubeBlocks 在移动云的落地情况如何主要应用在哪些场景丁顺我们已经在生产环境全量上线。目前移动云的每个大云海山数据库部署区域Region都部署了一套 KubeBlocks作为大云海山数据库管控系统的核心Operator 层。它不仅支撑了大云海山数据库实例的创建、备份/恢复、扩缩容、高可用管理等核心功能我们也正在利用它的通用性适配更多开源数据库以验证其作为通用底座的能力。Q5在将 KubeBlocks 集成到移动云现有的庞大云管体系中时你们团队做了哪些架构层面的设计丁顺我们把 KubeBlocks 作为原子能力的提供者集成在我们的“大云海山数据库管控平台”内部。我们构建了一套三层管控平台架构最上层是统一的业务服务层负责处理移动云特有的计费、鉴权及容量管理等业务逻辑中间层是管控服务层提供独立于特定业务底座的通用数据库管控能力底层则是Operator 层我们基于 KubeBlocks 框架利用其 Addon 机制来实现不同数据库引擎的组件编排、高可用切换及备份等核心运维能力。这种分层的架构设计既保留了移动云业务的灵活性又充分利用了开源社区的技术红利。这也是我们团队在 DBaaS 架构演进中的一次重要实践。Q6将核心管控层交给 KubeBlocks 后为移动云带来了哪些实质性的改变丁顺最直观的改变就是研发效率的质变。以前我们对于每个产品都需要组建一支团队去开发和维护 Operator现在我们投入比以前更少的人力开发 KubeBlocks Addon就能获得成熟的数据库编排能力。这让我们能把宝贵的研发资源集中在数据库自研内核的优化上而不是消耗在重复的 K8s 运维逻辑中。此外它帮我们实现了运维经验的复用。因为 API 模型是统一的我们为大云海山数据库积累的运维能力可以无缝迁移到其他数据库产品上大大降低了长期的运维成本。Q7在使用过程中遇到过什么挑战或痛点吗丁顺虽然 KubeBlocks 带来了巨大价值但在使用过程中我们也遇到了一些挑战希望能与社区共同探讨Addon 开发调试目前 Addon 开发过程中的问题调试还是个难点有时报错信息不够明确排查难度较大。API 命名相似我们生产环境上线较早从 0.8 版本开始后续的 KubeBlocks 版本中由于前向兼容或其他原因, 某些 API 字段得以保留但是导致了新版本的一些字段和这些历史遗留的字段名称过于相似在使用新版本 KubeBlocks 接口开发 AddOn 时容易混淆例如cluster.spec.componentSpecs.componentDef(新版本) 和cluster.spec.componentSpecs.componentDefRef(老版本) 。我觉得社区有一些其它开发者可能会有同样的困扰。Q8作为一个深耕云原生技术的团队移动云在享用开源红利的同时是否也参与了 KubeBlocks 社区的共建丁顺当然。我们团队始终秉持“源于开源回馈开源”的理念。在适配大云海山数据库的实战过程中我们将在 Addon 开发及大规模生产运维中遇到的深层问题积极整理并反馈给社区。同时我们也贡献了大量 PR涵盖了对 KubeBlocks 框架本身的优化以及对现有开源 Addon 的功能增强。通过与社区的紧密协作我们不仅提升了自身产品的稳定性也共同推动了整个开源生态的成熟。这种技术与生态的“双向奔赴”是我们非常看重的合作模式。第四部分对未来的展望Q1您是否有其他反馈或建议想和社区分享丁顺我有一个大胆的想法有没有可能把 KubeBlocks Addon 的开发相关的流程和最佳实践打包为一个对应的 Claude Skill这样让 Claude Code 这样的 AI agent 具有自动开发、修改和调试 KubeBlocks Addon 的能力那将极大地提升开发效率Q2对于刚开始评估 KubeBlocks 的同行您会给出什么建议丁顺结合我们的经验KubeBlocks 对于希望在 Kubernetes 上构建通用、高性能 DBaaS 平台的团队来说是一个极其有价值的解决方案。它能帮助你大幅缩短开发周期降低运维成本并避免重复造轮子。虽然在刚开始学习 Addon 开发时会有些挑战但其带来的长期收益尤其是对于希望标准化数据库运营的团队来说是巨大的。建议深入研究其设计理念并多参考社区现有的 Addon 案例。结语感谢丁顺的精彩分享移动云利用 KubeBlocks 成功构建大云海山数据库 DBaaS 平台的经验充分证明了 KubeBlocks 在云原生数据库管理领域的强大能力和巨大潜力。同时丁顺提出的挑战和建议也为 KubeBlocks 社区指明了未来的优化方向。KubeBlocks 社区将持续听取用户反馈不断打磨产品致力于为开发者提供更易用、更强大、更成熟的云原生数据库管理解决方案。我们期待与更多像丁顺一样的先行者共同推动云原生数据库生态的发展