Container 、Injection

Container：

　　Linux容器做为一类操做系统层面的虚拟化技术成果，旨在立足于单一Linux主机交付多套隔离性Linux环境。与虚拟机不一样，容器系统并不须要运行特定的访客操做系统。相反，容器共享同一套主机操做系统内核，同时利用访客操做系统的系统库以交付必要的系统功能。因为无需借助于专门的操做系统，所以容器在启动速度上要远远优于虚拟机。

　　容器可以利用Namespaces、Apparmor、SELinux配置、chroot以及CGroups等Linux内核功能，从而交付一套相似于虚拟机的隔离性环境。Linux安全模块可以确保来自容器的主机设备与内核访问行为受到妥善管理，从而避免入侵活动的发生。除此以外，容器还可以经过其主机操做系统运行多种不一样Linux发行版——只要各种操做系统拥有一样的底层CPU架构要求。整体而言，容器技术提供了一种立足于各种Linux发行版的容器镜像建立方式，同时利用API进行容器生命周期管理，经过客户端工具实现与该API的交互，进而提供快照以及不一样容器主机之间容器实例迁移等能力。

容器技术发展历程：

1979年 — chroot

容器技术的概念能够追溯到1979年的UNIX chroot。这是一套“UNIX操做系统”系统，旨在将其root目录及其它子目录变动至文件系统内的新位置，且只接受特定进程的访问。这项功能的设计目的在于为每一个进程提供一套隔离化磁盘空间。1982年其被添加至BSD当中。

2000年 — FreeBSD Jails

FreeBSD Jails是由Derrick T. Woolworth于2000年在FreeBSD研发协会中构建而成的早期容器技术之一。这是一套“操做系统”系统，与chroot的定位相似，不过其中包含有其它进程沙箱机制以对文件系统、用户及网络等资源进行隔离。经过这种方式，它可以为每一个Jail、定制化软件安装包乃至配置方案等提供一个对应的IP地址。

2001年 — Linux VServer

Linux VServer属于另外一种jail机制，其可以被用于保护计算机系统之上各分区资源的安全(包括文件系统、CPU时间、网络地址以及内存等)。每一个分区被称为一套安全背景(security context)，而其中的虚拟化系统则被称为一套虚拟私有服务器。

2004年 — Solaris容器

Solaris容器诞生之时面向x86与SPARC系统架构，其最初亮相于2004年2月的Solaris 10 Build 51 beta当中，随后于2005年正式登录Solaris 10的完整版本。Solaris容器至关于将系统资源控制与由分区提供的边界加以结合。各分区立足于单一操做系统实例以内以彻底隔离的虚拟服务器形式运行。

2005年 — OpenVZ

OpenVZ与Solaris容器很是类似，且使用安装有补丁的Linux内核以实现虚拟化、隔离能力、资源管理以及检查点交付。每套OpenVZ容器拥有一套隔离化文件系统、用户与用户群组、一套进程树、网络、设备以及IPC对象。

2006年 — Process容器

Process容器于2006年由谷歌公司推出，旨在对一整套进程集合中的资源使用量(包括CPU、内存、磁盘I/O以及网络等等)加以限制、分配与隔离。此后其被改名为Control Groups(即控制组)，从而避免其中的“容器”字眼与Linux内核2.6.24中的另外一术语出现冲突。这代表了谷歌公司率先重视容器技术的敏锐眼光以及为其作出的突出贡献。

2007年 — Control Groups

正如上文所说起，Control Groups也就是谷歌实现的cgroups，其于2007年被添加至Linux内核当中。

2008年 — LXC

LXC指代的是Linux Containers，其也是第一套完整的Linux容器管理实现方案。其功能经过cgroups以及Linux namespaces实现。LXC经过liblxc库进行交付，并提供可与Python三、Python二、Lua、Go、Ruby以及Haskell等语言相对接的API。相较于其它容器技术，LXC可以在无需任何额外补丁的前提下运行在原版Linux内核之上。目前LXC项目由Canonical有限公司负责赞助及托管。

2011年 — Warden

Warden由CloudFoundry公司于2011年所创建，其利用LXC做为初始阶段，随后又将其替换为自家实现方案。与LXC不一样，Warden并不会与Linux紧密耦合。相反，其可以运行在任意可以提供多种隔离环境方式的操做系统之上。Warden之后台进程方式运行并提供API以实现容器管理。感兴趣的朋友能够点击此处与此处了解更多与Warden相关的细节信息(英文原文)。

2013年 — LMCTFY

Lmctfy表明的是“Let Me Contain That For You(帮你实现容器化)”。它其实属于谷歌容器技术堆栈的开源版本，负责提供Linux应用程序容器。谷歌公司在该项目的起步阶段宣称其可以提供值得信赖的性能表现、高资源利用率、共享资源机制、充裕的发展空间以及趋近于零的额外资源消耗。Kubernetes目前所使用的cAdvisor工具最初就来源于lmctfy项目。2013年10月lmctfy的首个版本正式推出，谷歌公司在2015年决定将lmctfy的核心概念与抽象机制转化为libcontainer。在失去了主干以后，现在lmctfy已经失去一切积极的发展势头。

Libcontainer项目最初由Docker公司创建，现在已经被纳入开放容器基金会的管辖范畴。

2013年 — Docker

截至2016年1月，Docker是目前最具人气且应用最为普遍的容器管理系统。Docker项目最初是由一家名为dotCloud的平台即服务厂商所打造，其后该公司改名为Docker。与Warden相似，Docker一样在起步阶段使用LXC，然后利用本身的libcontainer库将其替换下来。与其它容器平台不一样，Docker引入了一整套与容器管理相关的生态系统。其中包括一套高效的分层式容器镜像模型、一套全局及本地容器注册表、一个精简化REST API以及一套命令行界面等等。在后期发展阶段，Docker公司还构建起一套名为Docker Swarm的容器集群管理解决方案。

2014年 — Rocket

Rocket最初由CoreOS开发而成，专门用于解决部分Docker当中存在的缺陷。CoreOS方面也提到，他们当初的开发目标是在安全性与生产要求知足能力上超越Docker。更重要的是，其基于App Container规范并使其成为一项更为开放的标准。除了Rocket以外，CoreOS还开发出了多种其它与容器相关的产品，且已经被Docker与Kubernetes所使用：CoreOS操做系统、etcd以及flannel。

2016年 — Windows容器

微软公司也已经于2015年采起初步举措，但愿将容器支持能力添加到微软Windows Server操做系统当中，而这项旨在帮助Windows应用实现容器化的项目被称为Windows容器(Windows Containers)。其即将随微软的Windows Server 2016一同推出。在这硕方案当中，Docker可以以原生方式在Windows平台上运行容器，而无需运行虚拟机或者多层Docker(早期Docker须要利用Linux虚拟机才能与Windows系统相对接)。

　　截至目前(2016年1月)，整个技术行业已经愈来愈多地将软件应用程序部署基础由虚拟机转移向容器。之因此出现这种趋势，一大重要缘由在于容器可以提供远优于虚拟机的灵活性与使用成本。谷歌公司多年来一直在利用Borg and Omega容器集群管理平台等容器技术以实现各种谷歌应用的规模化运行。更重要的是，谷歌公司还经过实现cgroups以及参与libcontainer项目等方式为容器技术的发展作出了突出贡献。谷歌方面在过去几年当中已经利用容器技术实现了可观的性能提高、资源利用率改善以及总体执行效率优化。就在最近，微软公司这位从未将任何操做系统层级虚拟化机制引入Windows平台的软件巨头亦快速在Windows Server上实现了原生容器支持能力。

------------------------------

转自http://cloud.51cto.com/art/201602/505113.htm

什么是容器？为何须要它们：

　　容器是针对如下问题的解决方案：在切换运行环境后，如何保证软件可以可靠地运行？这种切换多是从程序员的笔记本电脑到测试环境、从某个测试阶段部署到线上，也多是从数据中心的某台物理机到私有云或者公有云上的某台虚拟机。

　　使用虚拟化技术时，能够被分发的文件包是一台虚拟机，它包含了整个操做系统和应用。一台运行着三个虚拟机的物理服务器，须要有一个管理虚拟机软件的中间层，以及运行在这个中间层之上的三个独立操做系统。相较之下，一台运行着三个容器应用的服务器，只须要一个操做系统，而每一个容器均可以和别的容器共享同一个操做系统内核。操做系统中被容器共享的部分是只读的，若是须要写入，每一个容器均可以挂载独立的服务。这也就是说，容器比虚拟机要轻量级不少，它消耗的资源相较于虚拟机也少得多。

　　一个容器的文件大小可能只有几十M，可是一个拥有完整操做系统的虚拟机却多是几个G。正由于这一点，对于一个独立服务器来讲，它能承载的容器的数量比虚拟机的数量多得多。另外一个主要的优势是，虚拟机可能要耗费好几分钟的时间，才能启动操做系统、开始运行应用；然而容器中应用的启动几乎能够瞬间完成。这意味着，若是须要部署更多的容器，它们的实例化能够很快完成；若是不须要这些容器了，也能够很快将它们从宿主服务器上释放掉。第三个优势是，容器化更好地顾及到了模块化。一个复杂的应用能够被细分红小的模块（好比数据库、应用前端等等），而不是将它运行在某一个容器中。这种方式一般被称为“微服务”。使用这种方法构建的应用更容易被管理，由于每一个模块都相对简单，并且须要更新某些模块时，不须要从新构建整个应用。由于容器很是轻量级，单独模块（或微服务）只有在它们被须要时才会被实例化，而后几乎瞬间就变得可用了。

--------------------------------

转自https://baijiahao.baidu.com/s?id=1609932946964681808&wfr=spider&for=pc

Injection：

构造器依赖注入：

public class SomeBean { private final Service service; @Inject public SomeBean(Service service){ this.service = service; } }
 当CDI容器在初始化一个SomeBean类型的bean实例时，它将会查找该类的默认构造器（无参构造器）并用它来建立bean实例。可是有一个例外状况，就是当咱们还有一个使用
@Inject 进行了注解的构造器时，这种状况下，容器会改用有注解的构造器而不是无参构造器，而且把经过构造器参数传入的依赖资源注入到bean实例中来。

字段依赖注入：

public class SomeBean { @Inject private Service service; }

这种状况下，当容器初始化一个 SomeBean类型的bean时，它会把一个正确的Service实例注入给该字段，即便该字段是一个私有字段，而且不须要有任何setter方法。

初始化方法依赖注入：

public class SomeBean { private Service service; @Inject public void setService(Service service) { this.service = service; } }
这种状况下，当容器初始化一个 SomeBean类型的bean时，它会调用全部由@Inject注解了的方法，而且经过方法参数的方式把依赖注入进来。

 @Any 修饰符

　　为了提供彻底松耦合的应用，咱们一般把接口注入到受管理的资源中。当咱们有多个实现了给定接口的bean时该怎么办呢？咱们能够同时使用@Any修饰符和CDI的

Instance接口，来把全部该接口的实现bean都注入进一个受管理的bean中：

The @Any qualifier

public class SomeBean { @Inject public void listServiceImplementations( @Any Instance<Service> serviceList) { for(Service service : serviceList){ System.out.println(service.getClass().getCanonicalName()); } }
　　@Any 修饰符告诉容器，任何可供使用的依赖都适用于该注入点，因此容器会把他们都注入进来。 若是咱们有接口的多个实现而咱们只注入其中的一个 - 而且没有作
任何排除工做 - 那么容器将会抱怨而且没法成功的初始化组件。咱们将会在其余教程中介绍依赖排除问题。

注入到生产者方法中

　　生产者方法的参数也能够经由CDI容器进行注入。请查看Java EE CDI Producer methods tutorial.

CDI 代理

　　若是咱们不涉及CDI代理机制，那么本教程将是不完整的。当咱们把一个在不一样于@Dependent范围下建立出来的bean注入到另一个托管资源时，CDI容器不会注入一个被注入bean的直接引用。

CDI 代理 示例

public class Service$Proxy$_$$_WeldClientProxy extends Service { @Override public void doWork() { Service instance = // ... resolve bean instance instance.doWork(); } }
-------------------------
转自https://www.oschina.net/translate/java-ee-cdi-dependency-injection-inject-tutorial