像拼搭积木一样同时管理30+数据库引擎

随着业务不断发展，系统数据量的不断攀升，对于数据的存储和读取会面临各种各样的挑战。由于每种数据库都有各自的优点，可以解决特定的问题，所以一个复杂的系统往往都采用了多种多样的数据库引擎。业务上的性能问题是解决了，但是又迎来了新的挑战：如何更高效的管理和使用这些不同的数据库引擎。关于这个问题，前几天听了一个ArchSummit的演讲，觉得讲得挺好的，下面把他们的文字稿推荐给大家。如果您也正面临类似的问题，也许可以给你带来一些启发。

无论是公共云还是私有云，企业的用云选择从来就不是简单的选择，而是基于自身的合规要求，数据安全，成本控制和定制化需求等因素综合做出来的理性判断。而随着K8s 的发展，私有云跟公共云之间的技术差在收窄，云厂商主要的技术壁垒都在于如何把几百万台虚拟机运维好，用规模优势来降低成本，但是这样的技术在 K8s 面前就像马奇诺防线一样被绕过了，公共云和私有云今天都得站在怎么把容器技术做好，怎么把 K8s 生态做好这同一条起跑线上。

此外，大家如今都在基于K8s 去开发 PaaS 系统。而K8s 作为构建 PaaS 的基础，其全景图里还缺最后一块“拼图”——dbPaaS。加上数据库的使用场景也越来越复杂，使用数据库产品的企业和组织，通常都不会只使用一款数据库。比如使用MySQL+Redis+MongoDB支撑在线业务，使用Kafka+ClickHouse或者ElasticSearch支持分析业务，部分用户还会使用自研的数据和存储产品，比如自研的NewSQL或者分析引擎，多种数据库的管理对用户是一种比较大的技术挑战和成本支出。

然而不管是开源还是商业产品，都没有看到业界一个被广泛采用、有统治力的、成为事实标准的 dbPaaS，能做到一套系统一个逻辑适配到多种数据库引擎上去，减轻用户多数据库应用在多云、混合云管理模式下的负担，这是我们希望解决的痛点，也是我们的核心创新。

我过去在阿里云管理 RDS的产研，最深有体会的一件事情是数据库的类目太多了，版本也太多了，每一种数据库的运维操作都也很复杂。与之对应的痛苦就是人手不够，挺多事情都是可以靠堆人去做的。

企业在构建 dbPaaS 的时候，方法通常是对于每一种要支持的数据库，就搞一个独立的小团队，写一套独立的代码，甚至连运维人员都是独立的。这就导致了烟囱式架构，这种做法人效低，因为支撑每根烟囱的人力都是一个小池子，人员很难在烟囱之间流动，因此用烟囱式架构去支持dbPaaS这种长尾市场的业务，是一个错误的选择。拉长时间看，人员变动引起故障的概率在烟囱式架构里更高。还有更多的问题，比如资源不能做到跨引擎共享和混部，会增加部署一套dbPaaS的起步成本。

因为吸收了云厂商建设RDS的问题，所以我在创业的时候，选择了一个新的思路，用一种新的方法去实现 dbPaaS。各种各样的数据库都会发布自己的容器，容器本身就是一个标准的东西，那能不能像搭积木一样的，在 K8s 上把它们给组装起来部署提供服务，然后把它们的运维操作，也以一种标准地去组装？于是，我们就推出了自己的一个开源项目，叫 KubeBlocks。Kube 就是 Kubernetes 的前缀， Blocks 就是积木。这个项目的想法就是像搭积木一样的在 K8s 上管理好数据库。

乐高积木能够拼搭成各种各样的蓝图，其本质在于乐高是高度标准化的。它的凸起、凹槽、厚度、面积，都是有标准的。如果想让数据库像乐高积木一样的能够搭起来，也要提出一个标准，然后把各种各样的数据库容器适配到这个标准上。

在计算机科学当中，有几个比较著名的标准，比如说 POSIX，POSIX是对文件系统操作接口的抽象。K8s 里面有容器运行时标准 CRI，容器存储标准 CSI，容器网络标准 CNI，等等。通过这些标准，各种各样的容器网络、存储、分布式存储的项目都可以对接到 K8s 生态中去。除了标准和抽象之外，还有一个我们值得借鉴的方法叫分层，比如说OSI的 7层网络协议和TCP/IP 4层协议。通过分层，各家厂商的网络产品软硬件、各种协议，都能找到合适的一个层次，通过层与层之间的标准接口，适配起来组成一个完整的系统。

我们通过抽象和分层这两种方法来定义容器化数据库的标准，设计了 KubeBlocks API，本质上它类似于 POSIX API，是一个标准。我们先看下POSIX API，有了 POSIX API 之后，上层的应用就可以用一个很标准的 API 去操作各种文件，不用管底层的文件系统是什么，是ext4，xfs还是nfs。类似的，KubeBlocks API 是一个描述多个数据库容器之间的关系和拓扑结构，以及每个数据库容器的组成、可以提供的服务以及如何响应各种事件的行为的一个描绘，它是抽象的，跟任何一种具体的数据库是无关的，能够表达各种各样的数据库。此外，在设计这个 API 的时候我们也做了分层。我们分了五层，最底下一层是 K8s 的 API，它代表的 IaaS 的对象，倒数第二层是 Instance，描绘怎么把 IaaS资源组装起来，构成一个单节点的数据库的副本。InstanceSet 就是把多个Instance组装成了一个多副本的数据库。Component 在多副本的基础上，加了更多数据库的行为，比如说成员管理，备份恢复等等。再之上是组装成 Cluster， Cluster 就是一个完整的数据库集群，包含多个组件。我们把不同数据库的能力、特性都映射到这个 5 层当中去，通过抽象和分层提出了一个数据库容器组运行在K8s上的标准。

KubeBlocks 的核心实现就是通过这个抽象的API来管理数据库的生命周期，它不知道操作的数据库是MySQL还是PostgreSQL还是Redis，它只知道操作的是一个 Cluster对象，一个 Component对象，操作的是抽象的对象。通过这种方法就能做到 DBPaaS 最核心的控制软件，跟被操作的数据库引擎无关。它能做到一套代码适配到多种的数据库引擎上去，这是我们最核心的创新，是吸收了阿里云RDS设计、开发、维护经验教训后的创新，全世界范围目前没有第二个dbPaaS采用了这种设计。用户去操作数据库也会通过 Cluster，Component 这种标准 API，不管对数据库做任何运维操作，体验会非常的接近，学习成本会比较低。

比如大家很熟悉的 MySQL 高可用集群架构，会有MySQL Server组件和Proxy组件，还会有Ochestrator 这样的 HA 组件，它可以适配到这五层架构层里面去，不同的组件有不同的副本数、不同的容灾策略等等。

再比如 Redis高可用部署。Redis 主从架构会包含 Redis Server和Sentinel，其中Redis Server 是一主一从两个副本，而Sentinel 是三节点。Redis官方原生的集群架构Redis Cluster 则是一个水平分片的集群架构，比如说有 5 个分片，可以用 5 个 Component 来表达，每个 Component 又是一主一从两个节点。

我们怎么把 30 多种数据库给集成到 KubeBlocks 里面去，也是通过标准的POSIX API。我们再回顾下POSIX API，如果一个文件系统想兼容POSIX标准，让使用 POSIX API 访问文件系统的应用程序都能操作它，就得先实现POSIX 接口。类似的，一个数据库要想接入 KubeBlocks，就得让这个引擎也实现 KubeBlocks 的一组接口，也就是KubeBlocks Addon API。一个数据库实现这个API的工作量大不大？其实不大的，用 YAML 去写这几个API就 OK 了，几千行YAML、脚本、配置代码，熟悉K8s和引擎的同学两个星期就写完了。

给大家举个例子，Redis 是怎么接入到 KubeBlocks 当中？这个例子在 GitHub 上有代码的（https://github.com/apecloud/kubeblocks-addons/tree/main/addons/redis）。为什么举Redis的例子呢？因为它有很多种部署形态，单节点、主从、Sharding、还有 Redis cluster，形态有很多种。按照烟囱式的做法，每种部署形态都会是一个烟囱，一套独立的代码去管理。而在KubeBlocks里，不同的部署形态可以像积木一样去组装，不同的部署形态就是几行YAML的区别。

首先我们要实现一个个“积木块”。“积木块”要把Redis，Sentinel、Redis proxy 这些数据库镜像进行一次包装。对这些 Docker 镜像，我们用 KubeBlocks 的 API，用 YAML给它们增加一些扩展信息，里面会包含配置文件模板、服务和网络的配置、以及存储的配置等，还会扩展一些被事件触发时会执行的脚本（Action），以及版本镜像列表以及不同版本兼容性的描述信息等等。写完 Redis Server 的定义，我们就可以它看作是一个“积木块”。Redis Sentinel 和 Redis proxy 也是类似的，我们用 YAML 把它们都定义成 KubeBlocks 的“积木块”。每个“积木块”都对应着KubeBlocks API五层分层模型里的Component层，也就是说，Component是KubeBlocks里的“积木块”。

定义好这些“积木块”之后，我们在另一个 YAML当中定义它的拓扑结构，告诉 KubeBlocks 系统刚才那些“积木块”该怎么组装，就能组装成一个集群结构。接着，我们在 Cluster API 的里面指定使用哪个拓扑结构，以及配置一些额外信息，如副本数、每个副本的资源、存储容量，暴露的服务端口等一些信息后，一个 Redis 集群就可以生产出来了。除了 YAML API，还可以用 kbcli 的命令，或企业版的 dashboard 去创建数据库。

开发一个 Addon 的成本就是 写YAML 加上一些脚本，配置文件的模板，以及监控的模板等等，不需要写Go代码、Java代码，大概就是写几千行的非代码文件就能接进来，比从头写一个管控烟囱的开发成本要低多了。目前我们已经集成了 35 种引擎，有OLTP 的，有OLAP 的，有开源的，也有国产数据库，有分布式，还有向量的，甚至还有存储系统 Minio。

关于数据库的容器化，我常常遇到两个问题。第一个就是容器化会不会影响数据库的性能？第二个是 K8s 适不适合管理有状态服务？首先回答第一个问题。容器化不会影响数据库的性能。容器本身其实就是 Linux 操作系统当中的一个普通的进程，只是这个进程设置了 namespace，设置了group，使得它能够完成一些叫做“隔离”的障眼法。重要的事情说三遍，容器不是虚拟化，容器不是虚拟化，容器不是虚拟化。

上图大概画了 4 种常见的隔离方案，有虚拟化的，有 gVisor、有容器，在这四种虚拟化的方案当中，前面三种 VM、 microVM、gVisor 都有一层虚拟化层，这层虚拟化层有的放在 hypervisor 里面，有的放在用户态，唯独容器 runC 是没有虚拟化这层的，它就是一个普通的进程。所以性能上来说，在容器基础上做优化，它的底子其实是最好的。为什么要隔离呢？因为现在 CPU 的核数太多了。前两天有一个新闻说明年 AMD、英特尔还有 ARM 的核数都要达到200 核了，大家都在往一个服务器上塞更多的核，这样密度更高能效更好，但这么多核数单体应用和单体数据库都无法消费，大家用的最多的数据库一般都是 8C、16C，这时候一定是要用隔离技术，而在隔离技术里容器的性能是最好的。

基于容器，我们做了一些优化，把容器做到跟物理机上面的性能一样。最显著的，我们优化容器存储、容器网络、以及数据库的一些参数，可以达到在物理机上同样的甚至更好的性能。比如说 PostgreSQL 的吞吐，我们对 PG 容器做了一些优化之后，吞吐的峰值和公共云上 RDS一个水平，而且在低并发量下比 RDS 的吞吐更高，在高并发量下吞吐会更稳。用容器跑 Redis 的用户经常担心，延迟会不会增长，如果不优化肯定有影响，所以我们把容器网络换成 eBPF 之后，就跟物理网络的延迟一样低了。

第二个问题是 K8s 适不适合管理有状态的服务？首先 K8s 原生用来管理有状态服务的控制器，叫 StatefulSet。StatefulSet 确实不太好用，它有挺多限制，比如不支持 PVC 存储在线扩容的，另外变更 Pod 的时候，必须要严格按顺序去变更，这使得我没办法去指定一个 Pod 下线，它也不支持异构的各种各样的 Pod 配置。所以我们在 KubeBlocks 当中把 StatefulSet 换成了我们自己写的 InstanceSet，解决掉了StatefulSet 的各种问题。

另一方面，很多人误以为 在K8s 里面必须要依赖 Pod 的迁移以及 PVC 跨机重新挂载这些K8s原生的机制去解决高可用、高可靠的问题，而在线下环境往往没有分布式存储，如果 Node 挂了，PVC 没办法迁移，会导致在线下部署的时候数据库的可用性、可靠性受损。所以我们在 KubeBlocks 里面的做法是不依赖于K8s的检测和重调度，而是使用数据库本身的高可用和多副本技术去解决一个节点挂掉之后服务怎么恢复的问题，把数据库的稳定性和K8s的稳定性解耦开。

我们接触到了很多的企业，发现在 K8s 上去构建 dbPaaS是业界正在进行的趋势。公共云厂商，如阿里云的 RDS 全线产品都是跑在 K8s 上的，腾讯云的 TDSQL 是跑在 K8s 上的，移动云电子云的 RDS 跑在K8s 上…… 海外的数据库的初创公司，像 TiDB，Cockroach、Neon、PlanteScale 也都是把自己的数据库的 dBPaaS 架在 K8s 上。

国内的互联网公司，如阿里、字节、快手也是如此。银行领域，像工行、招行，也走得很靠前。行业上最近也在牵头在做数据库容器化的标准。

总之，在 K8s 上建数据库已经成为趋势。越来越多的企业选择将自己的数据库部署在 K8s 之上,这种方式可以充分发挥容器技术的优势,提高数据库的敏捷性、可靠性和可运维性。这种趋势在未来几年内有望进一步扩大和深化。

欢迎读者们跟我们一起探讨容器化数据库技术。

诚邀各位体验 KubeBlocks，也欢迎您成为产品的使用者和项目的贡献者。跟我们一起构建云原生数据基础设施吧

• 官网: www.kubeblocks.io
• GitHub: https://github.com/apecloud/kubeblocks
• Get started: https://kubeblocks.io/docs/preview/user_docs/try-out-on-playground/try-kubeblocks-on-your-laptop

关注小猿姐，一起学习更多云原生技术干货

每个开发者都想知道的云原生和数据库技术