Container

一：什么是Container？Container的做用？

容器是一个标准的软件单元，它将代码及其全部依赖关系打包，以便应用程序从一个计算环境快速可靠地运行到另外一个计算环境.container的主要做用是将软件打包成标准化单元用于开发，装运和部署。下面以当下比较受欢迎的Docker容器为例说明container的做用构成以及和虚拟软件的区别。

Container所处的位置：

Container能够运行在不一样的操做系统之上

容器与虚拟机的区别

容器和虚拟机具备相似的资源隔离和分配优点，但功能不一样，由于容器虚拟化操做系统而不是硬件。容器更便携，更高效。

 

container：

容器是应用层的抽象，它将代码和依赖关系打包在一块儿。多个容器能够在同一台机器上运行，并与其余容器共享操做系统内核，每一个容器在用户空间中做为独立进程运行。容器占用的空间比VM少（容器映像的大小一般为几十MB），能够处理更多的应用程序，而且须要更少的VM和操做系统

VM:

虚拟机（VM）是物理硬件的抽象，将一台服务器转变为多台服务器。管理程序容许多台VM在单台机器上运行。每一个VM都包含操做系统的完整副本，应用程序，必要的二进制文件和库 - 占用数十GB。虚拟机也可能很慢启动。

 

Container的历史：

1979年：Unix V7     

在1979年Unix V7 的开发过程当中，引入了chroot系统调用，将进程的根目录及其子进程更改成文件系统中的新位置。这一进步是开始的进程隔离：隔离每一个进程的文件访问。Chroot 于1982年加入BSD。 

2000：FreeBSD Jails

 

FreeBSD Jails容许管理员将FreeBSD计算机系统划分为几个独立的小型系统 - 称为“jails” - 可以为每一个系统和配置分配IP地址

2001：Linux VServer

与FreeBSD Jails同样，Linux VServer是一种能够对计算机系统上的资源（文件系统，网络地址，内存）进行分区的监狱机制。

2004年：Solaris Containers

2004年，第一个公开测试版 Solaris容器  被释放 吨ħ 在  联合机系统的资源控制，并经过区域，这是可以利用像从ZFS快照和克隆特征提供边界分离

2005年：Open VZ（Open Virtuzzo）

这是Linux 的操做系统级虚拟化技术，它使用修补的Linux内核进行虚拟化，隔离，资源管理和检查点.

2006年：流程容器

Process Containers（由Google于2006年推出）旨在限制，计算和隔离一组进程的资源使用（CPU，内存，磁盘I / O，网络）。一年后它被重命名为“控制组（cgroups）”，最终合并到Linux内核2.6.24。

2008年：LXC

LXC（LinuX容器）是Linux容器管理器的第一个，最完整的实现。它是在2008年使用cgroups和Linux命名空间实现的，它能够在单个Linux内核上运行，无需任何补丁。

2013年：LMCTFY

（LMCTFY）在2013年开始做为谷歌容器堆栈的开源版本，提供Linux应用程序容器。应用程序能够“容器识别”，建立和管理本身的子容器。在谷歌开始向libcontainer（如今是Open Container Foundation的一部分）提供核心LMCTFY概念后，LMCTFY的积极部署于2015年中止。

2013年：Docker 

当Docker于2013年问世时，容器爆炸式增加。Docker和容器使用的增加并不是巧合，这并不是巧合  。 正如Warden所作的那样，Docker在其初始阶段也使用了LXC，后来用本身的库libcontainer替换了该容器管理器。但毫无疑问，Docker经过为集装箱管理提供整个生态系统而脱颖而出

二：Injection/Dependency injection

在软件工程中，依赖注入是一种技术，其中一个对象（或静态方法）提供另外一个对象的依赖关系。依赖项是可使用的对象（服务）。注入是将依赖项传递给将使用它的依赖对象（客户端）。该服务是客户所在端的一部分。将服务传递给客户端，而不是容许客户端构建或找到服务，是模式的基本要求。

依赖注入的目的是将对象解耦到不须要更改客户端代码的程度，由于它所依赖的对象须要更改成不一样的对象。这容许遵循开放/封闭原则。

依赖注入是更普遍的控制反转技术的一种形式。与其余形式的控制反转同样，依赖注入支持依赖性反转原则。客户端将其依赖关系的责任委托给外部代码（注入器）。客户端不容许调用注入器代码; ^[2]它是构建服务并调用客户端注入它们的注入代码。这意味着客户端代码不须要知道注入代码，如何构建服务，甚至不知道它正在使用哪些实际服务; 客户端只须要知道服务的内在接口，由于它们定义了客户端如何使用服务。这分离了使用和构造的责任。

客户端接受依赖注入有三种经常使用方法：setter - ，interface - 和基于构造函数的注入。Setter和构造函数注入主要取决于它们什么时候可使用。接口注入的不一样之处在于依赖关系有机会控制其自身的注入。每一个都要求单独的构造代码（注入器）负责将客户端及其依赖关系引入彼此。

为何要使用依赖注入：

• 依赖注入容许客户端灵活地进行配置。只修改了客户端的行为。客户端能够对支持客户指望的内部接口的任何事情采起行动。
• 依赖注入可用于将系统的配置详细信息外部化为配置文件，从而容许在不从新编译的状况下从新配置系统。能够针对须要不一样组件实现的不一样状况编写单独的配置。这包括但不限于测试。
• 由于依赖注入不须要对代码行为进行任何更改，因此它能够做为重构应用于遗留代码。结果是客户端更加独立，而且使用存根或模拟对象模拟其余未测试的对象，更容易单独进行单元测试。这种易测性一般是使用依赖注入时注意到的第一个好处。
• 依赖注入容许客户端删除它须要使用的具体实现的全部知识。这有助于将客户端与设计更改和缺陷的影响隔离开来。它提升了可重用性，可测试性和可维护性。
  
• 减小应用程序对象中的样板代码，由于初始化或设置依赖项的全部工做都由提供程序组件处理。
  
• 依赖注入容许并发或独立开发。两个开发人员能够独立开发彼此使用的类，而只须要知道类将经过的接口。插件一般由第三方商店开发，甚至从不与建立使用插件的产品的开发人员交谈。
• 依赖注入减小了类与其依赖关系之间的耦合。

参考：

https://www.cnblogs.com/yuanchao-blog/p/10502844.html