文中有部分内容参考网易云架构师刘超老师的相关文章。

1 前言

自从学了docker之后，对于docker的应用场景一直不是很明白，到底为什么需要容器？
为什么容器技术这么受欢迎？它的使用场景到底在哪里？翻阅了一些资料之后，我得到了下面的结论。

2 容器使用场景

首先，需要了解到云计算是为了解决计算、网络、存储这三种资源的弹性问题。如果想详细了解这个方向的内容，可以参看这篇博客。

什么是云计算？

云计算解决了计算机基础设施计算、网络、存储这几个方面的弹性问题，但是它遗留了两个问题。

• 应用的扩展问题。例如我开发一个电商应用，平时的时候10台机器能扛的住，双十一的时候需要100台才能抗的住。那怎么办？云计算平台可以实现一点90台新机器就出来了，但是机器是空的啊，上面什么应用都没安装，还需要人工登到每台机器上去一台一台的部署，非常麻烦。

• 迁移性问题。软件往往是需要不断的在不同的环境里面安装的，例如开发人员自己会安装一套，测试人员会安装一套，线上环境也会安装一套。然而软件的安装是非常复杂的，牵扯到权限问题，配置问题，文件路径问题等，一不小心就会出错，出错了软件的行为就不对了，你上网买东西，用银行支付都可能出错，造成大麻烦。

  在云计算环境下，人们想出了两种方法解决问题。一是通过自动化脚本，然而不同的环境千差万别，一个脚本往往在一个环境上运行正确，到另一个环境就不正确了。二是通过虚拟机镜像，然而虚拟机镜像太大了，动不动就几十个G，拷贝和下载都太费时间。

于是乎，大牛们考虑是否存在着更加轻量级的虚拟化方式，更容易去迁移，也更容易扩展应用层业务的虚拟化方法。有人根据集装箱的设计思想来设计了更轻量级的虚拟化技术。
在集装箱出来之前，货物搬运需要来回的卸货装货，如下图所示，并且物品与物品之间的隔离性很差，如果船上的货物有水果、有铁桶等，那么水果很容易被其他硬的东西挤坏。

因此，为了解决这个问题，有人提出了集装箱技术。其一是为了能够更好的进行迁移，省去了中间来回搬货卸货的问题；其二是为了进行隔离，让不同的物品之间分隔开，互不影响。
借鉴与传统运输业的解决方案，有人提出使用类似集装箱的方式封装应用和应用运行的环境（应用运行所需要的依赖关系），也就是将任何应用及其依赖打包成一个轻量级、可移植、自包含的容器。

容器技术有很多种，docker只是其中一种，只不过docker的流行度较高。

要实现类似于集装箱的这种封装技术，需要两大技术，其一是Namespace，在不同Namespace中的应用可以有独立的网络资源、用户空间、进程号等；其二是Cgroups，可以把cpu、内存等资源进行隔离让容器使用，可以实现对容器资源的限制，限制容器能够使用的cpu和内存资源，避免单个容器出错，耗尽所有系统资源。

3.对比容器和虚拟机

3.1 轻量的原因

首先要知道一点，容器是比虚拟机更加轻量级的虚拟化技术，而它轻量的原因主要是以下两方面。

• 撇下os。容器里面是不安装操作系统的，因为一个操作系统就很大了，并且os的运行也是非常占用系统资源的，容器与宿主机共用一个内核，容器之间的迁移不带内核。
• 撇下应用运行产生的本地数据。这些数据如果在容器里面，容器会变得很大，影响容器在不同环境之间的迁移。不同的环境指的是开发、测试、运维上线这几种环境的不同。这些数据在不同的环境是没有意义的，因此这些数据一般放在容器之外的设备上。

3.2 容器局限性

由上面两点我们知道了容器轻量的主要原因，同时，我们也可以得知容器的局限性。
其一，由于所有容器都是与宿主机共用内核的，容器与容器之间的隔离性就会差很多；其二，容器里面是不存放数据的，容器里面的数据会随着容器的生命周期而消失，如果想要持久化的存储，必须要依靠外部的存储设备。

3.3 容器优势

• 1.虚拟机启动会先启动OS,而启动OS需要耗费一定的时间以及系统资源，容器由于其共享内核的特性，不用启动OS,因此，可以实现秒启动，并且可以节省大量的系统资源。
• 2.虚拟机安装应用的时候，需要重新把应用运行的环境部署一遍；而容器可以直接把应用运行环境给打包。也就是说容器具有更好的迁移性。
• 3.由于容器可以将应用以及它所运行的环境依赖打包成镜像，故容器是可以直接做应用层扩展的。

4 容器化带来的挑战

在IT世界里，经常使用粒度这个概念，而且一般的出现形式都是以粗粒度、或者细粒度这两种形式出现的。
在我看来，对客户暴露了太多细节的相对来说就是细粒度的。用户可以只用一个操作就完成数据的存取,这就是粗粒度的.粒度应该是相对与该类的使用者来说的,如果存取只需要有限的操作,而没有暴露太多的底层实现则是粗粒度的,相反你把每个属性暴露给用户让它都可以对之进行操作则是细粒度的.

由于容器的粒度非常细，所以在管理上就会有一定的困难，人工管理是非常难以实现的，因此容器层面的平台管理主要就是依靠自动化来实现的。

自发现：容器与容器之间的相互配置还能像虚拟机一样，记住 IP地址然后互相配置吗？这么多容器，一旦一台虚拟机挂了重启，IP改变，你怎么记得住应该改哪些配置，列表长度至少万行级别的啊。所以容器之间的配置通过名称来的，无论容器跑到哪台机器上，名称不变，就能访问到。

自修复：容器挂了，或是进程宕机了，能像虚拟机那样登陆上去查看一下进程状态，如果不正常可以重启一下么？那你要登陆万台 Docker了。所以容器的进程挂了，容器就自动挂掉了，然后自动重启。

弹性自伸缩 Auto Scaling：当容器的性能不足的时候，需要手动伸缩、手动部署么？当然也要自动来。