动手点关注 干货不迷路 👆
背景
本文分享的是 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 是一个容器编排系统,主