Container的历史：
2000 年的时候 FreeBSD 开发了一个类似于 chroot 的容器技术 Jails，这是最早期，也是功能最多的容器技术。Jails 英译过来是监狱的意思，这个“监狱”（用沙盒更为准确）包含了文件系统、用户、网络、进程等的隔离。
2001 Linux 也发布自己的容器技术 Linux VServer，2004 Solaris 也发布了 Solaris Containers，两者都将资源进行划分，形成一个个 zones，又叫做虚拟服务器。
2005 年推出 OpenVZ，它通过对 Linux 内核进行补丁来提供虚拟化的支持，每个 OpenVZ 容器完整支持了文件系统、用户及用户组、进程、网络、设备和 IPC 对象的隔离。
2007 年 Google 实现了 Control Groups( cgroups )，并加入到 Linux 内核中，这是划时代的，为后期容器的资源配额提供了技术保障。
2008 年基于 cgroups 和 linux namespace 推出了第一个最为完善的 Linux 容器 LXC。
2013 年推出到现在为止最为流行和使用最广泛的容器 Docker，相比其他早期的容器技术，Docker 引入了一整套容器管理的生态系统，包括分层的镜像模型，容器注册库，友好的 Rest API。
2014 年 CoreOS 也推出了一个类似于 Docker 的容器 Rocket，CoreOS 一个更加轻量级的 Linux 操作系统，在安全性上比 Docker 更严格。
2016 年微软也在 Windows 上提供了容器的支持，Docker 可以以原生方式运行在 Windows 上，而不是需要使用 Linux 虚拟机。
为什么需要容器
其一，这是技术演进的一种创新结果，其二，这是人们追求高效生产活动的一种工具。
随着软件开发的发展，相比于早期的集中式应用部署方式，现在的应用基本都是采用分布式的部署方式，一个应用可能包含多种服务或多个模块，因此多种服务可能部署在多种环境中，如虚拟服务器、公有云、私有云等，由于多种服务之间存在一些依赖关系，所以可能存在应用在运行过程中的动态迁移问题，那这时如何保证不同服务在不同环境中都能平滑的适配，不需要根据环境的不同而去进行相应的定制，就显得尤为重要。
injection：
在软件工程中，依赖注入是一种技术，其中一个对象（或静态方法）提供另一个对象的依赖关系。依赖项是可以使用的对象（服务）。注入是将依赖项传递给将使用它的依赖对象（客户端）。该服务是客户所在端的一部分。将服务传递给客户端，而不是允许客户端构建或找到服务，是模式的基本要求。
Dependency Injection （DI） 就是在类之间的互相引用，都采用Interface来代替。后台有Container，每个Interface包含一个Object，实际上这是一个Singleton的概念，所以在使用Singleton的时候，要避免使用DI，虽然DI支持非Singleton，但是感觉逻辑上不太符合常理。
优点：
A. 减少依赖关系通过Interface互相联系，这样两个组件之间关联少一些。
B. 更加方便重复使用只要是Interface相同，组件可以在不同的场合中重复使用。
C. 更容易测试Test 的代码不需要和使用代码有任何关联，设置好Container，然后组件就自动生成。与正常运行，完全相同的测试环境，不需要考虑构造函数等等。
D. 更容易阅读，需看Interface即可，一旦测试封装结束后，不需要读里面的代码。
E. 减少Dependency Carry就是如果在最底层的引用某个变量，需要从最顶层一点点传递下来，如果用DI，就可以跳过中间部分。这个说得是Singleton，如果顶层的变量有一些特定的值，无法从Container中生成的话，就没必要了。