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

 最近看到一篇推文，痛述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窗口等企业级数据库服务功能，帮助企业快速构建云上数据库融合生态。