最近滴滴的故障的问题，相信各大群都有分析，故障点一致指向了K8S ,Docker。 实际上对于Docker本身数据库工程师并不是很熟悉，基于数据库的本身的重要性和承载的业务量等区别，不少大型的应用是不会使用docker 来承载数据库应用的。
在我们讨论DOCKER 对于数据库是否是一个好的基础平台之前，基于数据库工作者先弄清楚，DOCKER 为什么而生，Docker 的初衷是为开发人员和运维团队提出一种简便的应用程序部署的方式和管理的方式，DOCKER的特点是：轻量化，快速部署和扩容扩展，资源的隔离和安全性，简化配置环境和依赖管理。
注意这里docker的初衷是什么，应用程序的部署，什么是应用程序，我们认为应用程序本身是一种无状态的程序代码的集合。Docker要解决的问题，是应用程序快速的扩展和部署的问题，比如我双12 ，我原来就500台的主机在负责应用程序的工作，现在我要2000台，这如果是实体机的模式，这就是一个灾难，而如果应用了docker 的情况，则无需关心主机的环境，直接启动 包含应用程序的docker即可工作和服务。
在部分程序员的眼里，或者一些道听途说的IT manager 的眼里，docker马上成为一个武器，一个削减成本，包含人力成本的武器。之前我们可能需要10-个人来支持应用程序，而现在有了k8s docker ,则只需要5个人，或者2个人就够了，不就是点几下鼠标的问题，有上述想法和看法的人不是少数。
我们这里且不谈上述人等在降低成本和Docker之间的关系的误解，我们只谈数据库和Docker 或K8S 之间的关系的问题。
数据库是什么，数据库是一个有状态的应用程序，是一个用于组织和存储数据库的系统，提供数据的安全性一致性，持久性的一个应用程序产品，同时数据库管理系统（DBMS）是一种软件工具，用于管理数据库。它提供了一系列功能，例如创建、修改和删除数据库、定义数据结构（例如表、字段和关系）、执行查询和事务处理以及对数据进行备份和恢复等。DBMS还提供了安全性控制、数据完整性和一致性保证以及数据并发处理等功能。
基于上述对于数据库的定义，与我们一般的应用程序的工作模式是截然不同的，这里对于数据库和应用程序，可以用两个字来定义，有状态和无状态。
下面我们来看这张图，一个简易的容器的图，我们根据这张图，如果数据库作为应用程序来说，数据库是一个无状态的部分，如果部署的话也是部署到容器，但是数据的部分，日志的部分会落到文件系统，同时内存部分也是加载上去的。
基于对于数据库的了解，数据库在设计之初，是一套严谨的与硬件系统贴合的设计的应用程序集合，对于硬件的使用有自己的一套方法，这在现在的云原生数据库上也得到了验证，云原生数据库都是重新设计贴近自身的云厂商硬件设计的产品。那么这样的将数据库部署在DOCKER的方式是否破坏了原始的数据库应用设计，这就需要进行分析和说明了。
1 数据库部署在DOCKER 中或容器中，数据必然会存储在绑定卷中，而不是容器卷中，而不直接使用IO 无法直接调用IO 就是数据库容器话的，第一宗罪。
DBA 对于数据库的运行中的一些性能的瓶颈都有自己的新的，其中在大部分的数据库系统中，IO的瓶颈是经常可以见到的。这里对于IO 的消耗主要集中在
1 容器与操作系统之间的IO 消耗
2 多个容器在一个操作系统中的IO通道的资源征用
3 CPU 在操作IO 时的分时操作，导致的IO调度的耗时
这三个层面主要的问题在于
1 文件系统性能的影响：当容器需要频繁读写文件时，可能会遇到文件系统性能的瓶颈。特别是在容器内执行大量的IO操作时，可能会导致文件系统的响应时间增加，并对性能产生负面影响。
2 存储驱动的选择：Docker使用存储驱动来管理容器的文件系统。选择不合适的存储驱动可能会影响IO性能。不同的存储驱动具有不同的性能特性，因此对于特定的使用场景，选择适合的存储驱动非常重要。
3 硬件系统无法支撑瞬时的多个容器的数据库高并发的访问磁盘系统，导致性能风险的问题
这里可以举一个例子，第三点，在数据库容器规划中，无法尽善尽美的将数据库在硬件中根据业务逻辑分割开来，在这样的模式下，经常会出现多个数据库容器在一个硬件下的性能不足的问题，但这里需要注意，对于应用可以进行迁移的方式，但对于数据库这样有状态的产品，无法进行随意的动态迁移，因为必然会影响业务，产生连接的中断等问题。
而在实际的生产环境中，基于DOCKER 的数据库产品大多不能将高并发核心业务也都推广到DOCKER 上的一个原因也有基于这个问题的原因。
第二个大问题是什么数据库适合容器化，我们不能否认在一些公司进行了数据库的docker化，但我们需要明白什么数据库，什么业务，适合进行数据库docker化。
这样的系统一般都带有以下的标签，MySQL 数据库，测试系统，周边项目，良好的数据库分库分表设计。
这说明在Docker 上运行的系统，有一些特色，对于一些短暂非重要的项目，或者测试系统，的确可以通过数据库容器化，享受到一波的管理成本的宏利，但基于一些核心的大型的系统，很少有运行在DOCKER上，这也是基于以下的一些因素考虑
1 如PG ,ORACLE ，SQL SERVER 等数据库产品，本身基于一些集中式开发，数据库压力较大，需要的硬件资源较多，导致DOCKER 这些数据库产品上的应用，管理成本非但下不来，反倒是增加了管理成本，性价比不高。同时这些数据库产品在功能上比较丰富，本身的定位也不是数据库容器化的主流。
2 基于硬件压力较大的核心数据库，没有必要进行数据库容器化，让数据库软件更直接的操作系统与硬件进行0距离的贴近部署，才是性能最大化的利用与安全部署的方案。
3 大容量的数据库产品不适宜部署在DOCKER，容器化，当一个数据库本身数百G ，甚至达到TB级别，对于任何的管理人员都是一个需要非常慎重对待的，本身这些数据库有完善的故障转移的机制，并且启动和关闭的方式也都非常的复杂，基于这些，这样的数据库并不适合进行容器化。
所以基于容器化的数据库是有前提的，你的数据库在数量上有接近产传统方案无法管理的数量级，比如上万套 MySQL 产品，并且大部分都是测试，预生产和 周边系统的情况下，的确可以有数据库容器化的必要。
所以基于上述，咱们可以引出第三个数据库容器化的适不适合你企业的问题，也就是你的数据库的数量的问题。
问题 3 数据库容器化是否有性价比
这是一个必要要回答的问题，产出比是一个项目是否要进行的重要指标，不少小企业，基于技术人员的私心和没有IT 管理政策的因素，让一些根本不适合进行数据库docker化的企业数据库Docker 化，并且不以为耻，反以为荣。
基于容器化的数据库产品，在人力上相对于单纯的数据库管理部分，要付出的人力资源成本更多。
首先Docker，K8S 是一个专项技术，并不是数据库管理人员可以胜任的，同时胜任数据库和K8S的数据库管理人员的薪资对比普通的DBA管理人员薪资要更高，同时在处理单纯的数据库故障和基于docker 上的数据库故障处理的方法有所差异，传统的监控和部分分析故障的方式，并不适合基于docker 上数据库的分析方法，所有原有的监控系统等都需要进行改造。所以不考虑一些列由传统数据库，专项容器化数据库上的产生的成本的纯技术思维都应该在反思，你是否需要容器化数据库并值得为其付出相关的成本。
当然除此之外，还有我们熟知的一些其他的问题，需要在数据库容器化中解决。
1 数据丢失与安全问题，容器在崩溃时，数据库未正常关闭，导致数据损坏，当然这个问题可以由数据库的高可用来弥补，但是基于DOCKER的数据库必须有完善的数据库高可用的措施和设置。
2 容器的特性，Docker在设计之初推荐的服务挂掉后，自动启动新的容器，而不是重启容器服务的方式，这点对于数据库层面是否适合，同时数据库的配置文件等，在容器数据库中能进行动态配置是否可以，也是需要考虑的问题。
3 网络问题： 容器与宿主机之间是是通过网桥链接的，数据要经过网桥进行转发和处理，这会导致网络的延迟和吞吐量的下降，同时容器中不支持传统网络中的一些功能，如多波，广播等，同时IP地址管理的复杂性，同时参杂容器之间的网络的访问的限制，导致高可用部署时的一些问题。
4 伸缩处理的特性在数据库层面无法进行应用，Docker的快速扩展是一个使用他的重要特性但是在有状态的数据库层面，无法进行这个特性。Docker 本身的一些优势在数据库应用无法体现和使用。
5 资源隔离的问题，在上面的已经阐述了这个问题，DOCKER 的确在资源的隔离性上基本上没有，数据库之间的互相性能影响必然存在，也将是数据库容器化的难题之一。
基于以上的种种问题，在一般的企业，数据库实例不足上千套，并且数据库中包含了大量的PG， ORACLE , SQL SERVER 等企业，DOCKER 化数据库,容器化数据库，劳民伤财，和当前的 “降本增笑”，开猿DOWN机，有异曲同工之妙。
