已阅读
免备案cdn数据库不适合上容器云？
针对数据库是否适合容器化这个问题，不同的人可能会给出不同的答案，在回答此问题之前我们先看下容器化部署数据库和常规数据库部署上的一些比较。
容器化VS非容器化
数据安全这个话题较大，可以细分很多的小方向，在此我们只从数据丢失这个角度分下数据库容器化后引入的问题。
和数据库打过交道的同学应该都知道，公司线上的数据库一般都需要进行定期的数据备份，区别的话无非就是根据业务的轻重缓急设置不同的数据备份方式、备份频率和备份数量。常见的数据库的数据备份方式有全量备份和增量备份。
顾名思义，全量备份即每次都进行一次完整的数据备份，即便是相较前一次的全量备份数据没有丝毫的增加也要再进行一次完整的数据备份，此种方式的特点是可靠性较好，每一个数据备份都是备份所在时间点的完整数据，当然此种方式的缺点也是显而易见的，即备份周期较长(相比增量备份的数据量大)，且备份数据占用的磁盘存储也较大；增量备份即在第一次备份时进行一次全量的备份，后续在进行备份时只备份相较前一次备份时变化的数据，增量备份的优点是备份周期短，且备份数据占用的磁盘空间较少。
备份周期并非越小越好，需要结合业务的属性进行选择，如公司OA系统使用的数据库可以一周备份一次，毕竟OA 这种系统并会经常进行大量数据的写入。再一种情况，比如公司的重要的线上业务一般需要较高的备份频率，一般以天或者小时作为备份周期的时间单位，比如一天备份一次、或者1小时备份一次。有些更重要的业务系统，出现数据丢失时会带来比较大的损失，此种情况一般会采用更高的数据备份频率，比如银行的数据库备份多以分钟或者秒作为数据库的备份周期单位。
和备份周期的设置类似，备份数据保留的数量也并非越多越好，也需要根据具体的业务场景来设置备份数据的保留数量。比如一般的线上业务可以每天备份一次，最多保留7份备份数据。推荐阅读：《免费cdn加速面向医疗保健的云计算的基本指南》
以上我们说的是我们在将数据库容器化之前为防止数据库数据丢失通常进行的配置，从现实角度来看即使我们设置了上面提到的各种配置也仍然不能保证不丢失数据。
从上面的经验来看，容器化后即使我们通过容器的volume 将数据存储在容器所在宿主机上也不能保证数据不丢失。况且Docker 的volume 是围绕联合文件系统的镜像层来进行的持久化存储设计，这种设计目前在数据库存储方面仍缺乏保证。
除了上面的问题，还有一种情况也会为数据库的数据安全性带来问题，众所周知在容器的世界里某个容器的崩溃、重建是常态，这种情况对于业务实例来说也许不会有多大的影响，但同样的场景换为数据库可能会出现问题，比如运行着数据库的容器崩溃可能会导致容器内的数据库不能正确关闭，从而可能造成数据的损坏。
在非容器化的场景中，为了避免避免和其他组件的资源竞争，数据库这种核心组件我们一般都是单独部署的，要么单独部署到一台或者几台的虚拟机上，要么单独部署到一台或者几台的物理机上，一般需要和其它的线上组件分开部署，比如后端的一些业务实例等，防止其它异常组件拖垮数据库，毕竟数据库挂了线上业务一般也就歇菜了，这种情况下企业一般也是宁愿多花点钱来保证线上业务的正常运行。
数据库的单独部署只是第一步，实际环境中一般还需要给数据库组件配置好一些的硬件资源，具体需要在哪些方面进行升配也需要结合具体额业务场景和数据库的类型来看。比如关系型数据库，一般对I/O要求较高，这个时候一般需要为数据库配置较好的存储设备，比如磁盘选用优质的全固态盘。在一种比如缓存数据库，为提高查询效率缓存数据库一般会将数据存储在内存中，如果存在较多的高频访问数据，此时一般需要为数据库配置较高的内存。
考虑到上面的两种情况，我们在进行数据库的容器化过程中为了避免数据库实例和其他的业务实例产生资源竞争，我们需要为数据库容器配置大量额外的资源，一般可能需要设置超过实际用量一倍的资源，比如我们实际需要8GB内存，可能需要为实例分配16GB内存，多出的这8GB的内存资源一般并不会被完全使用。
简单说来就是Docker并未对容器中运行数据库这种场景做专门的优化。我们先看下Docker 官方对Docker的定义：
Docker Containerization Unlocks the Potential for Dev and Ops，Freedom of choice, agile operations and integrated container security for legacy and cloud-native applications。
具体说来就是：
了解Docker 的同学应该都知道，Docker 通过namespace(命名空间)对各种资源进行了隔离，这些隔离包括：主机和域名隔离、进程编号隔离、用户和用户组隔离、文件系统隔离、网络设备隔离、网络栈隔离、端口号隔离、信号量消息队列和共享内存的隔离等。
默认情况下只有同一个namespace下的进程之间是可以相互联系的，无法感受到外部进程的存在，Docker通过这种方式营造出一种独立的系统环境，从而实现隔离。
这种隔离性虽然保证了不同容器中进程的冲突等问题，但是这些额外引入的隔离级别也会增加资源的开销。并且这种隔离性只是为业务的应用量身打造的，并未专门针对数据库做做额外的优化。
当前环境下借助云平台已经成为常态，我们知道云计算简化了虚拟机管理、替换上的复杂性，因此在需要添加新的虚拟机计算节点时直接登录上云平台，控制台界面上鼠标操作几个步骤即可准备完毕几台新的计算节点，为我们节省了很多的购买已经设备和测试硬件设备的时间和精力，可谓方便至极。当然这个也是我们需要向云厂商付费的原因之一。
我们再说回容器云，用过云厂商容器云产品的同学应该会知道，云厂商提供的容器产品相比原生的容器往往会有一些限制，这个时候如果我们不想直接使用云厂商提供的容器云产品，转而使用云厂商提供的其他的计算产品自己部署容器环境，比如使用虚拟机或者使用物理机，这种情况下上文中我们讲到的云厂商为我们提供的便利性就不存在了，当然我们可以在容器所在宿主上对数据库容器实例的资源使用进行限制，这种方式的确可以，但相比直接使用虚拟机或者物理机部署数据库实例这种容器化部署的方式更加复杂。
以上我们在7个方面列举了下数据库不适合进行容器化的原因，很多方面仅仅只是进行了粗略的描述，尤其是在关键的有状态部署和无状态部署方面，由于此部分涉及对比的方面较多，在此下面我们专门单独拿出来看下。
总结
