容器化，让数据库如虎添翼

最近看到一篇推文，痛述 MySQL 不能上容器的各种理由，基本是 N 年前的陈词滥调，东拼西凑出的一篇水帖，文末对于数据库是否能上容器，也是模糊不清，没有确切的观点，标题倒是吸引眼球，不明就里的人容易产生一种倾向：数据库不适合容器。在如今这种信息泛滥的年代，好像否定一种事物，比接纳他更容易引起共鸣，小编君也在自问：为什么数据库容器化容易被否定？是他本身的逻辑导致的吗？做为一名数据库从业者，小编君举双手支持数据库容器化！

首先来看看数据库容器化受到的各种质疑：

▌ 1. 如果容器突然崩溃，数据库未正常关闭，可能会损坏数据

荒谬，按照这个逻辑，把容器两字换成物理机，这句子念的也是通畅的吧？当然数据持久化姿势要正确，可以用 PV/PVC 外挂存储或目录的方式，数据 IO 直接透传出容器，数据库本身是有 WAL 日志保护的，只要磁盘不存在损坏，故障重启后的日志前滚回滚，会保证 commit 的你看得见，未 commit 的你看不见。不管是容器，还是物理机，都是这套流程，两者面对的崩溃导致异常的概率基本是一致的，可能物理机崩溃事还更大一点吧？

▌ 2. 容器里共享数据卷组，对物理机硬件损伤也比较大

这个不知从何说起，容器也是一个 OS 进程，他发起的 IO 也和其他原生态进程一样经由内核驱动下发到硬件设备上，写 5TB 的数据下去，既不会使硬盘变重，也不会破空击伤了他，我猜作者是担心多个容器挂载了共享目录，没控制写冲突，导致数据的逻辑损坏。这还是个姿势问题，与容器无关了。

▌ 3. 容器是无状态的，对于数据库这种 IO 密集型应用，会拖垮 IO 性能

从本质来讲，容器是通过 cgroup 做的资源限额，通过命名空间做的用户态隔离，单纯 CPU/内存的使用，跟物理机是没有区别的，IO 层面使用的是 aufs 内部文件系统，这一层的性能确实差劲，当发现容器 IO 跑不起来时，建议你看看是否把某些密集操作，落到了 aufs 上。对于数据库跑容器，都是使用的 PV/PVC 外挂透传，瓶颈不会是容器，无论是吞吐还是 IOPS，都可以无损消耗，所以该质疑不成立。

▌ 4. 容器不安全，担心数据泄漏

小编君承认，容器不如虚拟机安全，他共享 os 内核，一些关键目录隔离性不够，镜像本身的安全性等，似乎到处都是刺。但大家也要理解一点，容器输出的是服务，虚拟机交付的是 os，如果你硬是要把容器当成 os 交付出去，安全肯定是打折扣的。就数据库容器化而言，最终给出的肯定是端口之类的服务暴露，所以这个安全是可控的。也许有人会问：你就没有要进入容器内部去排错的时候吗？ok，排错也是这套系统的管理服务人员，而非终端服务使用者。另外，既然上了容器化，他也有配套的可观测系统，就不要再以管 os 的方式管容器了。

所以从技术层面来看，把数据库塞进容器，会有一些学习和开发成本，但不是什么大的障碍。我们公司的数据库融合平台就是基于容器+K8S 这条技术路线，目前支持主流数据库的全生命周期管理，公有云 Squids 和私有云 QFusion，满足用户线上线下双轨需求，现已经成功上线了多家客户，在这个平台的建设上小编君可以说点感受！

图：Squids 平台架构

不知什么时候开始，数据库这块也开始聊"CI/CD"了，频繁创库居然成了一个高频次操作，维护开发/测试/生产数据库环境的精准一致性就显得特别重要，中国已经有 240+数据库厂商，要在这种多库多 OS 的排列组合下做到一次打包，多次使用是不容易的，例如 squids.cn 是直接基于公有云 ECS 提供 RDS 服务的，6 大云厂商，各种 os，CPU 还有 arm/x86，机型达 1700 种，本来以为适配工作会非常繁重，是容器化让这个路径大幅缩短，我们将每款数据库的环境依赖，最优配置固化到了一个小盒子里，送到了全球各地。我们有个客户的数据库资源池构建也比较有意思，因为前期预算有限，机器规模一开始很小，那么就会有 Mongo/Redis/MySQL 可能挤到一台机器上的情况，性能是扛得住的，但环境安装很麻烦。要是以后再加一款新库，所有机器还得更新一次。其实他就是需要将数据库和 os 层解耦，容器镜像隔离就非常适合，当时也调研过虚拟化方案，资源损耗比较大，而客户的研发部也在力推应用容器化改造，虚拟化就放弃了。

数据库塞进容器，只是第一步，还得有 HA 保护，备份恢复，升级扩容，性能可观测这些配套设施，就像火箭和火箭发射塔一样，两者结合，才能稳定高效的运行，而很多时候，这些配套设施都留在 DBA 的脑子里，或者某些 shell 脚本里，最近几年小编君明显感觉 DBA 这个行业开始快餐化了，谁都能上去耍一哈子，但精通的不多。不是人不聪明，而是我们的精力很难再聚焦，大家都是快速理解掌握，解决眼前的问题，立马下一站。未来可能都不再会有 DBA 这一职业了，所以将 DBA 的思想，经验转化为代码，并不断地根据场景、需求去调整，是长远之策。我们需要用平台化、云原生的思路去构建数据库运行的环境。

在选择容器化方向后，自然就会引入 K8S，最初团队是非常不适应的，特别是他的网络策略，而数据持久性，高可用，故障切换，备份恢复都需要迎合 K8S 的特点去实现，这个过程很痛苦，否定一个工具有两种可能，这个工具不行，或者你这个人不行，经过艰难的摸索后，我们也逐渐找到了感觉，例如在 K8S 里面有一种控制器模式，你指定了运行两副本，那就一定是两副本，不管是杀掉进程，还是重启关机，只要 K8S 的这一套体系还在，他就不断的调整资源，达到你声明的效果，这种倔强的脾气，就很适合数据库 HA 检测和故障保护，我们只需要将数据库复制，切换，故障检测的业务逻辑封装进去，一套健壮的 HA 机制就可以运行起来，K8S 的 Service 服务暴露，可以为业务访问提供统一入口，即使数据库飘了，也不用应用修改连接串。再比如 K8S 的 label 标签，亲和调度策略，对于池化资源平衡能起到很好的效果，类似的例子还有很多，在资源调度，自动化，故障自愈，健壮性上，K8S 似乎给了我们很多可能。我们发现，一旦理解适应了 K8S 这套体系，你基于他去做数据库平台化建设是非常顺畅的，他解决了很多底层的复杂逻辑，你专注数据库业务就行。所以当我们基于 K8S 完成了 MySQL 这货的全生命周期管理后，后面的什么 SQLServer,Oracle,Redis,Mongo.....全都不是事。

也有人跟我探讨过，他说你这些说的都对，但你说的每一个点，我都可以用非容器化，非 K8S 的方式来实现，换以前小编君会跟他 battle 的，现在年纪大没力气了。我觉得我们只是在容器化，云原生的潮流下，选了顺应趋势的技术路线，目前，受益匪浅！！！

PS： 不喜欢看文字的，可以看一下这两个视频，欢迎和我们多多交流。👏👏

▌ 本文作者：罗春，沃趣科技联合创始人 &产品总架构师

Squids 官网：www.squids.cn

Squids 是多云时代的数据库云服务提供商，基于公有云基础资源，提供云上 RDS，云备份，云迁移，SQL 窗口等企业级数据库服务功能，帮助企业快速构建云上数据库融合生态。