为什么会出现容器的注入？
容器：顾名思义，装东西的器物。
至于spring中bean，aop，ioc等一些都只是实现的方式；具体容器哪些值得我们借鉴，我个人觉得是封装的思想。将你一个独立的系统功能放到一个容器之中，可以当做一个大的接口被别人使用，也可以更好的规范标准。
云计算解决了计算机基础设施计算、网络、存储这几个方面的弹性问题，但是它遗留了两个问题。
应用的扩展问题
迁移性问题
在云计算环境下，人们想出了两种方法解决问题。一是通过自动化脚本，然而不同的环境千差万别，一个脚本往往在一个环境上运行正确，到另一个环境就不正确了。二是通过虚拟机镜像，然而虚拟机镜像太大了，动不动就几十个G，拷贝和下载都太费时间。
于是乎，大牛们考虑是否存在着更加轻量级的虚拟化方式，更容易去迁移，也更容易扩展应用层业务的虚拟化方法。有人根据集装箱的设计思想来设计了更轻量级的虚拟化技术。
在集装箱出来之前，货物搬运需要来回的卸货装货，如下图所示，并且物品与物品之间的隔离性很差，如果船上的货物有水果、有铁桶等，那么水果很容易被其他硬的东西挤坏。
因此，为了解决这个问题，有人提出了集装箱技术。其一是为了能够更好的进行迁移，省去了中间来回搬货卸货的问题；其二是为了进行隔离，让不同的物品之间分隔开，互不影响。
借鉴与传统运输业的解决方案，有人提出使用类似集装箱的方式封装应用和应用运行的环境（应用运行所需要的依赖关系），也就是将任何应用及其依赖打包成一个轻量级、可移植、自包含的容器。
容器技术有很多种，docker只是其中一种，只不过docker的流行度较高。
要实现类似于集装箱的这种封装技术，需要两大技术，其一是Namespace，在不同Namespace中的应用可以有独立的网络资源、用户空间、进程号等；其二是Cgroups，可以把cpu、内存等资源进行隔离让容器使用，可以实现对容器资源的限制，限制容器能够使用的cpu和内存资源，避免单个容器出错，耗尽所有系统资源。
container设计的思想
经典的两个知识点：1、控制反转；2、依赖注入。
一、控制反转
每个对象自身对于逻辑的执行能力，被其所依赖的对象反向控制了，这也就是控制反转的本质含义。
软件之父为了解决与业务逻辑完好的解耦，从而又能实现一个额外的编程元素容器来帮助进行对象的生命周期管理！提出了容器的构建规则：
1、容器应该被设计成一个全局的，统一的编程元素；
2、在最大程度上降低容器对业务逻辑的入侵；
3、容器应该提供简单而全面的对象操作接口。
二、依赖注入
只提供普通的Java方法让容器去决定依赖关系。容器全权负责的组件的装配，它会把符合依赖关系的对象通过JavaBean属性或者构造函数传递给需要的对象。通过
JavaBean属性注射依赖关系的做法称为设值方法注入(Setter Injection)；将依赖关系作为构造函数参数传入的做法称为构造器注入（Constructor Injection）。
在这里要提示一下，本次我所说的容器是container（由一系列对象的操作接口构成，其中应该至少包含获取对象实列以及管理对象之间的依赖关系这两类操作方法），而不是collection（用于表述一组对象的集合）！
原文：https://blog.csdn.net/liliang_11676/article/details/78753291
https://blog.csdn.net/gui951753/article/details/81504318
