ByteDoc 3.0：MongoDB 云原生实践

动手点关注 干货不迷路 👆

背景

本文分享的是 Bytedoc 3.0 关于集群交付方面的内容以及一些云原生的实践：如何将 Bytedoc 3.0 与云原生的能力结合起来，交付用户一个开箱即用的集群，与软件层的能力相匹配，最大化展示 Bytedoc 3.0 具备的“弹性”能力。

面临的问题

数据库服务的使用者有两方：用户（业务）和 DBA（运维），运维能力不断增强，才能给用户更好的服务体验。

用户需求

运维需求

目标与思路

目标

为了解决上述问题，Bytedoc 3.0 软件层已经实现了相关的能力，我们需要在交付层提供类似的能力，以匹配整体的“弹性”能力：

目标 1：数据库能快速扩展/恢复从库，秒级扩展数据库的读能力。扩容从库实例自动化程度要高，扩容速度尽可能快；

目标 2：计算资源能够按需扩展。对计算密集型业务，能快速扩展计算资源，而且能分配更多的资源供用户使用，匹配实际负载；

目标 3：提升计算/存储资源利用率，降低业务使用成本。

目标 4：更标准的交付能力与更高的交付质量，给用户提供更好的数据库服务。

实现思路

我们通过“Kubernetes 云原生”化来实现我们的目标：

Kubernetes 是业界通用的，用于自动部署，扩展和管理容器化应用程序的开源编排系统。简单地说，它能够系统化地打包、运行、管理你的服务，在这里是 Bytedoc 数据库服务。这使得我们能够结合已有的运维经验和业界通用服务交付/管理解决方案，提供更好的、更高质量的数据库服务，以发挥 Bytedoc 3.0 十足的"弹性"能力

在 ByteDoc 1.0 时期，大多数数据库服务实例是直接部署到虚拟机上的，资源的分配受限于虚拟机规格的划分，无法灵活地、按需要分配机器资源，导致大部分的机器资源空闲出来，无法得到有效利用；同时，因为计算与存储的资源绑定，在 1.0 的自研部署平台中，实现容器化部署十分困难，虚拟机部署的方案就一直保留下来。

直到 ByteDoc 3.0 的出现，将数据下沉存储层，交付服务时，更多关注计算层方面的资源分配，使得容器化部署模式可行。结合 Kubernetes 对容器部署与管理的解决方案，我们将容器大部分自动化管理操作交由给 Kubernetes 控制器管理，专注于 ByteDoc 3.0 服务编排过程，如集群部署、从库扩容等，以充分发挥 3.0 的"弹性"能力。

云原生实践

服务云原生化，实际上是一个“迁移”的过程，将原有服务打包、运行、管理能力，以 Kubernetes 提供的解决方案为标准，重现出来。

在 Kubernetes 中，我们把 ByteDoc 3.0 集群定义为一种定制资源（CustomResource）。提供数据库服务，实际上就是创建了一种资源；和 K8s 内置的工作负载资源一样，定制资源也需要一个控制器来进行管理，通常把这类控制器称作 Operator。

所以，ByteDoc 3.0 云原生实践的关键是构建 ByteDoc Operator。

Kubernetes 基本概念

容器化部署

前面说到，Kubernetes 是一个容器编排系统，主要的职责是管理容器生命周期，所以实际的应用程序应该提前打包成一个容器镜像，以便于交付给 K8s 来使用。

Pod

https://kubernetes.io/zh/docs/concepts/workloads/pods/

我们打包好的容器最后会运行在 Pod 中，由 Pod 管理起来。

Pod 是 K8s 中内置的最基本的资源之一，也是最小部署的计算单元，可以类比于一些共享机器资源的容器组。

如果一个 Pod （内的容器）因异常导致退出，通常情况下，这个 Pod 会被删除销毁，高级 workload 会新建一个全新的 Pod 来代替它，而不是“重启”该 Pod。

高级 workload

通常情况下，我们构建的 Operator 不会去直接创建 Pod；而是使用 K8s 提供的高级 workload 资源，他们会帮我们把 Pod 创建出来，并提供一些基本