演讲者 丁顺 中国移动云高级系统架构师
预期开发资源节省
有效代码行数减少
在深入讨论技术细节之前，我先介绍一下中国移动云的 DBaaS 系统，这个系统管理着我们所有的云数据库。中国移动云的 DBaaS 系统拥有全面的产品线，涵盖了事务型数据库、分析型和搜索型数据库、NoSQL 数据库等。我们不仅为一些最受欢迎的开源数据库和第三方数据库提供数据库服务，还开发了自研数据库引擎并在其基础上提供服务。目前，我们服务超过 3.5 万个客户，涵盖政府、通信、金融、医疗、教育等 9 大主要行业。
我们的 15 个一级区域和 31 个二级区域运行着超过 13 万个数据库集群实例。除了数据库配置，我们还建立了一个强大的生态系统，帮助客户更高效地管理他们的数据库。我们构建了许多高效的管理工具和系统，如数据迁移、数据库管理控制台，以及具有 AIOps 能力的工具。中国移动云 DBaaS 平台以云原生的方式运行，这意味着我们大部分的数据库实例都运行在 K8s 集群内。
管理如此大规模的数据库实例是一项具有挑战性的任务。虽然我们已经建立了一个可以管理不同类型数据库实例的 DBaaS 系统，但我们仍面临着维护这一 DBaaS 系统的挑战。目前，我们的 DBaaS 系统大致分为 API 层和 Operator 层，其中 Operator 层是核心部分。
我们的第一个挑战来自于我们为不同的数据库引擎开发了不同的 Operator。但这些 Operator 之间差异很大，比如开发人员无法快速从为引擎 A 开发的 Operator 切换到为引擎 B 开发 Operator，导致了开发资源无法灵活分配。
此外，开发 Operator 对开发人员的要求很高。他们不仅需要了解数据库引擎本身的原理，还需要熟悉整个 Operator 框架。虽然已有一些现成的框架可复用，但这些框架对开发人员仍然有很高的要求，也很难迅速将有生产力的开发人员投入团队。
更重要的是，我们正在开发自己的数据库引擎，并希望能快速为其构建一个 DBaaS 系统。然而，由于前面提到的诸多挑战，我们无法快速为新的数据库引擎开发 DBaaS 系统。为此，我们需要成立一个既了解我们数据库引擎又了解 Operator 框架的高技能开发团队。然后，这些开发人员必须从头开始编写一个新的 Operator。由于这个数据库引擎是我们内部自主研发的引擎，所以我们无法在市面上找到现成的 Operator。重新编写意味着需要做大量冗余工作。即使这一引擎的某些逻辑与其他数据库引擎的 Operator 非常相似，但我们仍旧无法有效地复用。
因此，我们一直在找寻应对这些挑战的解决方案，如何使不同 Operator 具有类似的接口？如何降低对 DBaaS 系统开发人员的要求？如何快速集成新的数据库引擎？
于是我们发现了 KubeBlocks 项目，它能够很好地解决我们的问题。KubeBlocks 是一个专门为数据库工作负载设计的通用 Operator 框架。开发人员为不同的数据库引擎编写 addon，以集成到 KubeBlocks 系统中。这个项目吸引了我们几个特点：
首先，它是一个通用的 Operator 框架。这意味着只需要运行一个 Operator，即可支持不同类型的数据库引擎。开发人员只需维护一个 Operator 和一套 CRD。这使得在 Operator 层共享知识变得容易，可以灵活地分配到不同的数据库引擎团队中。
其次，该框架使用低代码开发模型。不同数据库引擎的集成通过编写不同的 addon 来实现，而不是从头开始编写专用的 Operator。所用的 addon 只是包含 KubeBlocks 框架中 CR 对象的 Helm charts。开发 addon 时，我们只需要编写所需 CR 对象的 YAML 文件以及一些功能脚本。后面我们会详细介绍这些内容。Addon 中的 CR 对象是以声明性方式定义的。就像其他 Kubernetes 对象一样，开发人员只需描述期望的数据库集群运行状态，KubeBlocks 框架将进行调谐。这种低代码开发模型降低了为新数据库引擎开发 DBaaS 系统的门槛。开发人员只需了解数据库引擎的工作原理，就可以开始开发。
最后，较少的代码意味着潜在的 bug 较少，新数据库引擎的集成速度也加快了。这很好地满足了我们的需求。
更重要的是，KubeBlocks 是一个专门为数据库工作负载设计的通用框架。它有效地覆盖了 Kubernetes 上数据库的所有基本管理操作。例如，KubeBlocks 提供了生命周期管理、备份恢复、配置管理、高可用等功能。此外，KubeBlocks 还提供了可扩展机制，允许特定数据库引擎管理操作无缝地集成到整体框架中。
经过详细调研，我们决定尝试使用 KubeBlocks。当时，有一个内部开发的数据库引擎需要集成到 DBaaS 系统中，这里我们使用 H-DB 代指该引擎。这是验证 KubeBlocks 在 DBaaS 系统中集成使用的绝佳机会。
首先，我简要介绍一下我们的 H-DB。它是一个自研的云原生分布式数据库引擎，实现了存算分离。通常，为如此复杂的数据库系统编写 Operator 是巨大的挑战，想要快速实现集成更是难上加难。但借助 KubeBlocks，我们可以以低代码的方式实现这一目标。
以下是我们构建 KubeBlocks addon 的过程：
设计集群拓扑，并搭建 addon 框架。通常，初始 addon 只包含一个粗略的 ClusterDefinition 框架和一个非常基本的 ClusterVersion，后者指定了所有组件容器的镜像。在我们的案例中，H-DB 集群中有两个组件：计算节点和数据节点。因此，我们定义了一个包含这两个组件的集群定义（Cluster Definition）对象。在 ClusterVersion 中配置了每个组件的镜像，并暂时在 ClusterDefinition 中设置了一个虚拟的启动命令。然后，我们编写一个简单的 Cluster CR 对象进行测试，以确保所有 addon 可以成功安装，Pods 能够成功启动。
完善 ClusterDefinition，在 ConfigMap 中设置正确的配置参数，并编写脚本以引导集群启动。我们调整配置和脚本，确保集群能够正常运行。这一步很重要，因为这意味着第一个可用的 addon 已经完成。
支持备份和恢复功能。我们需要编写备份和恢复的功能脚本，并将其集成到 KubeBlocks 的 ActionSet CR 对象中。我们可以创建一个备份 OpsRequest 和一个恢复 OpsRequest 来测试这些功能。
编写 ConfigConstraint，控制哪些参数可以被修改，是否可以动态配置，以及重新加载（reload）命令。这些配置使 addon 能够修改数据库引擎中的部分配置参数。
启用高可用性和角色检测，在我们的数据库集群中添加一些观测边车（sidecar），这些边车将收集数据库实例的指标和日志。
最后，我们可以添加更多的 Cluster 版本，以适配不同的内核版本。
至此，我们成功为 H-DB 开发了一个完整的 KubeBlocks addon。通过使用 KubeBlocks，我们在仅两个月内、仅用一个人完成了 H-DB 的第一个 DBaaS 系统。而且，这个过程可以更快，因为后续的 addon 构建步骤可以并行推进。这是中国移动云和 KubeBlocks 的首个集成案例。
以下是开发 KubeBlocks addon 与开发专用 Operator 的总结对比。这里，我们将 KubeBlocks addon 的开发过程与为类似的数据库引擎编写专用 Operator 的开发过程进行比较。在开发人员资源投入方面，编写 KubeBlocks addon 只需要 2 人月（有效代码行数 2000+），而为类似产品编写专用的 Operator 则需要大约 6 人月（有效代码行数 7000+）。H-DB 的案例是一个很好的起点。它证实了我们可以通过使用 KubeBlocks 来解决目前在 DBaaS 系统中面临的问题。
下一步，我们计划通过 KubeBlocks 进一步集成更多的数据库引擎，进行深入的评估，并尝试升级到 KubeBlocks 的新版本，评估我们感兴趣的一些功能。
在中国移动云，我们的理想目标是建立一个统一的云原生 DBaaS 平台。在这个平台上，我们旨在实现统一的多云架构、API 和 Operator 层的统一接口，支持不同架构的数据库集群，并且数据库实例可以根据需求部署在无服务器的 Kubernetes 集群上。这将形成一个统一的数据库编排和通用管理平台，支持公共云、私有云、专用云、边缘云等不同基础设施。
随着 KubeBlocks 的不断发展和改进，未来我们将考虑基于 KubeBlocks 框架重构我们现有的 DBaaS 系统。从长远来看，对于不同的数据库引擎，我们预计可以节省大约 50% 的开发资源。
演讲发表于 KubeCon China 2024
