共计 2586 个字符，预计需要花费 7 分钟才能阅读完成。
原文链接如下：
https://www.toutiao.com/i6805…
近几年来，Docker 在企业环境的利用端具备很大的后劲，在这一点上我想大家是引人注目的，无状态的服务采纳容器化曾经是一种大趋势，那么问题来了，作为系统核心的数据库是否须要容器化？
针对数据库是否适宜容器化这个问题，不同的人可能会给出不同的答案，在答复此问题之前咱们先看下容器化部署数据库和惯例数据库部署上的一些比拟。
Docker 不适宜部署数据库的 7 大起因
1、数据安全问题
不要将数据贮存在容器中，这也是 Docker 官网容器应用技巧中的一条。容器随时能够进行、或者删除。当容器被 rm 掉，容器里的数据将会失落。为了防止数据失落，用户能够应用数据卷挂载来存储数据。然而容器的 Volumes 设计是围绕 Union FS 镜像层提供长久存储，数据安全不足保障。如果容器忽然解体，数据库未失常敞开，可能会损坏数据。另外，容器里共享数据卷组，对物理机硬件伤害也比拟大。
即便你要把 Docker 数据放在主机来存储，它仍然不能保障不丢数据。Docker volumes 的设计围绕 Union FS 镜像层提供长久存储，但它依然不足保障。
应用以后的存储驱动程序，Docker 依然存在不牢靠的危险。如果容器解体并数据库未正确敞开，则可能会损坏数据。
2、性能问题
大家都晓得，MySQL 属于关系型数据库，对 IO 要求较高。当一台物理机跑多个时，IO 就会累加，导致 IO 瓶颈，大大降低 MySQL 的读写性能。
在一次 Docker 利用的十大难点专场上，某国有银行的一位架构师也曾提出过：“数据库的性能瓶颈个别呈现在 IO 下面，如果按 Docker 的思路，那么多个 docker 最终 IO 申请又会呈现在存储下面。当初互联网的数据库多是 share nothing 的架构，可能这也是不思考迁徙到 Docker 的一个因素吧”。
针对性能问题有些同学可能也有绝对应的计划来解决：
(1) 数据库程序与数据拆散
如果应用 Docker 跑 MySQL，数据库程序与数据须要进行拆散，将数据寄存到共享存储，程序放到容器里。如果容器有异样或 MySQL 服务异样，主动启动一个全新的容器。另外，倡议不要把数据寄存到宿主机里，宿主机和容器共享卷组，对宿主机损坏的影响比拟大。
(2) 跑轻量级或分布式数据库
Docker 里部署轻量级或分布式数据库，Docker 自身就举荐服务挂掉，主动启动新容器，而不是持续重启容器服务。
(3) 合理布局利用
对于 IO 要求比拟高的利用或者服务，将数据库部署在物理机或者 KVM 中比拟适合。目前 TX 云的 TDSQL 和阿里的 Oceanbase 都是间接部署在物理机器，而非 Docker。
3、网络问题
要了解 Docker 网络，您必须对网络虚拟化有深刻的理解。也必须筹备应酬好意外状况。你可能须要在没有反对或没有额定工具的状况下，进行 bug 修复。
咱们晓得：数据库须要专用的和长久的吞吐量，以实现更高的负载。咱们还晓得容器是虚拟机管理程序和主机虚拟机背地的一个隔离层。然而网络对于数据库复制是至关重要的，其中须要主从数据库间 24/7 的稳固连贯。未解决的 Docker 网络问题在 1.9 版本仍然没有失去解决。
把这些问题放在一起，容器化使数据库容器很难治理。我晓得你是一个顶级的工程师，什么问题都能够失去解决。然而，你须要花多少工夫解决 Docker 网络问题？将数据库放在专用环境不会更好吗？节省时间来专一于真正重要的业务指标。
4、状态
在 Docker 中打包无状态服务是很酷的，能够实现编排容器并解决单点故障问题。然而数据库呢？将数据库放在同一个环境中，它将会是有状态的，并使系统故障的范畴更大。下次您的应用程序实例或应用程序解体，可能会影响数据库。
知识点在 Docker 中程度伸缩只能用于无状态计算服务，而不是数据库。
Docker 疾速扩大的一个重要特色就是无状态，具备数据状态的都不适宜间接放在 Docker 外面，如果 Docker 中装置数据库，存储服务须要独自提供。
目前，TX 云的 TDSQL(金融分布式数据库) 和阿里云的 Oceanbase(分布式数据库系统) 都间接运行中在物理机器上，并非应用便于管理的 Docker 上。
5、资源隔离
资源隔离方面，Docker 的确不如虚拟机 KVM，Docker 是利用 Cgroup 实现资源限度的，只能限度资源耗费的最大值，而不能断绝其余程序占用本人的资源。如果其余利用过渡占用物理机资源，将会影响容器里 MySQL 的读写效率。
须要的隔离级别越多，取得的资源开销就越多。相比专用环境而言，容易程度伸缩是 Docker 的一大劣势。然而在 Docker 中程度伸缩只能用于无状态计算服务，数据库并不实用。
咱们没有看到任何针对数据库的隔离性能，那为什么咱们应该把它放在容器中呢？
6、云平台的不适用性
大部分人通过共有云开始我的项目。云简化了虚拟机操作和替换的复杂性，因而不须要在夜间或周末没有人工作工夫来测试新的硬件环境。当咱们能够迅速启动一个实例的时候，为什么咱们须要放心这个实例运行的环境？
这就是为什么咱们向云提供商领取很多费用的起因。当咱们为实例搁置数据库容器时，下面说的这些便利性就不存在了。因为数据不匹配，新实例不会与现有的实例兼容，如果要限度实例应用单机服务，应该让 DB 应用非容器化环境，咱们仅仅须要为计算服务层保留弹性扩大的能力。
7、运行数据库的环境需要
常看到 DBMS 容器和其余服务运行在同一主机上。然而这些服务对硬件要求是十分不同的。
数据库（特地是关系型数据库）对 IO 的要求较高。个别数据库引擎为了防止并发资源竞争而应用专用环境。如果将你的数据库放在容器中，那么将节约你的我的项目的资源。因为你须要为该实例配置大量额定的资源。在私有云，当你须要 34G 内存时，你启动的实例却必须开 64G 内存。在实践中，这些资源并未齐全应用。
怎么解决？您能够分层设计，并应用固定资源来启动不同档次的多个实例。程度伸缩总是比垂直伸缩更好。
总结
针对下面问题是不是说数据库肯定不要部署在容器里吗？
答案是：并不是
咱们能够把数据失落不敏感的业务（搜寻、埋点）就能够数据化，利用数据库分片来来减少实例数，从而减少吞吐量。
docker 适宜跑轻量级或分布式数据库，当 docker 服务挂掉，会主动启动新容器，而不是持续重启容器服务。
数据库利用中间件和容器化零碎可能主动伸缩、容灾、切换、自带多个节点，也是能够进行容器化的。
