京东到家MySQL容器化，为何首选Docker而非K8S？

DBAplus社群 · 公众号 · 数据库 · 2020-11-26 07:15

正文

1）容器化的优缺点

容器化只能解决容器可以解决的问题：

优点：

规格标准统一/标准化： 比如说，MySQL怎样实现单机多实例呢？最常见的做法是，单机启用多个MySQL实例，需要考虑端口不一样的问题。但是对于云端的产品来说，很多的端口都是统一的，比方说默认的3306。当然会有一些公司不太需要特别去统一端口，它们的端口可以随便按照一定的规则往下加，就能解决单机多实例的端口规划的问题；

管理灵活可控/资源隔离： 对于MySQL来说，用比较原生的方式很难做到资源隔离。在高规格的机器上部署很多实例时，里面比较繁忙的实例很可能会完全拖垮在业务上白天相对使用率比较低的实例。从这方面考虑，容器化就能够很好地解决资源隔离的问题，但对底层架构来说是一个变化着的挑战；

资源动态分配： 在用原装的产品的时候这一点可能体会较少，但如果我们完全掌握了容器和资源，就可以解决这个问题。比如，业务线原本需要16核，但是在高负载的秒杀或者促销场景下，CPU完全100%，这时可以快速对资源进行动态分配，扩张到32核甚至48核。对于很多常见的云端产品来说，在没有进行容器化的时候进行这种操作比较难。按照我们之前的经验，需要提前做好资源规划，或者做临时扩容，但难题是需要做场景服务。

缺点：

随着技术发展，做技术选型也要适配公司业务发展和扩张变化，我们需要不断思考可能会遇到的问题和随时进行业务迭代。

2）Docker

考虑到以上的问题，我们觉得容器化改造很有必要性，并且它能满足我们当时的一些需求。

因为我们的Docker针对MySQL运用，当时也需要考虑在Docker里需要注意哪些问题，所以我们在这几个方面做了相对于应用来说不太一样的适配，以宿主机为概述：

①配置选择

②镜像管理

最开始有一些比较老的MySQL版本，大版本加上小版本总共八个版本，这时候使用Docker可以根据需求定制化镜像，最终我们统一改成了5.6、5.7这两个版本。

③部署流程

对于应用来说，数据库的部署对于K8s的需求来说并没有那么强烈，底层可能是一个库或者几个库，而应用的机器是几十或者几百个。最主要的区别是，应用是一个无创产物，研发人员来思考它的开启和关闭不会考虑太多问题，但对数据库来说就不是这样的：

网络模式需要根据自身条件取舍，由于我是DBA出身，而且团队对网络这一部分也不太熟悉，在当时的条件下经过了测试后发现没有什么问题就选用了套索模式。

3）为什么没选择k8s

常见的程序应用扩容非常简单，直接用镜像靠拢机器，加上分发、授权的现象就可以直接用，可是 数据库服务弹性伸缩需求不强。 数据库要做弹性扩容常见的方式就是改进配置容器去重启服务，但是对于需要伸缩云端产品的时候，也是类似的思路，想改高配置的话也需要流程去重启服务，但是对我们业务线来说不可接受。但是Docker在一定程度上解决了这个问题，因为刚刚也说到Docker可以进行CPU的扩容，但对我们大部分的研发线来说也不是日常的需求；

3、部署考虑

4、部署流程

基于到家业务场景下的部署和流程

这套自动化的流程需要自己把控，现在到家这一套流程保证在5分钟之内完成，可以给研发提供一个生产交付。

5、管理拓扑

我们刚买的机器和宿主机的规格还是比较匹配的，配置是128核、256g、xxx（18:56）这个样子。