第二周 - JavaShuo

第二周

git：

分布式版本控制系统。Git(读音为/gɪt/。)是一个开源的分布式版本控制系统，能够有效、高速地处理从很小到很是大的项目版本管理。 [1] Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件

svn：

SVN是Subversion的简称，是一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上不少版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多我的共同开发同一个项目，共用资源的目的。

maven：

Maven项目对象模型(POM)，能够经过一小段描述信息来管理项目的构建，报告和文档的项目管理工具软件。

Maven 除了以程序构建能力为特点以外，还提供高级项目管理工具。因为 Maven 的缺省构建规则有较高的可重用性，因此经常用两三行 Maven 构建脚本就能够构建简单的项目。因为 Maven 的面向项目的方法，许多 Apache Jakarta 项目发文时使用 Maven，并且公司项目采用 Maven 的比例在持续增加。

Maven这个单词来自于意第绪语（犹太语），意为知识的积累，最初在Jakata Turbine项目中用来简化构建过程。当时有一些项目（有各自Ant build文件），仅有细微的差异，而JAR文件都由 CVS来维护。因而但愿有一种标准化的方式构建项目，一个清晰的方式定义项目的组成，一个容易的方式发布项目的信息，以及一种简单的方式在多个项目中共享JARs。

Gradle：

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，抛弃了基于XML的各类繁琐配置。

面向Java应用为主。当前其支持的语言限于Java、Groovy、Kotlin和Scala，计划将来将支持更多的语言。

———— 来源：百度百科

Java中容器和注入的分析、历史与将来：

1、java中的容器html

java EE中的注入，使咱们定义的对象可以获取对资源和其余依赖项的引用，而不须要直接实例化它们。经过使用将字段标记为注入点的注释之一来装饰字段或方法，能够在类中声明所需的资源和其余依赖项。而后容器在运行时提供所需的实例。注入实现了将代码和代码的依赖项的分离。注入分为资源注入和依赖注入两种。java

资源注入：git

经过资源注入，能够将JNDI名称空间中可用的任何资源注入任何容器管理的对象，例如servlet，企业bean或托管bean。例如，可使用资源注入来注入JNDI名称空间中可用的数据源，链接器或自定义资源。github

用于引用注入实例的类型一般是一个接口，它能够将代码与资源的实现分离。sql

例如，如下代码注入一个数据源对象，该对象提供与GlassFish Server附带的默认Apache Derby数据库的链接：数据库

public class MyServlet extends HttpServlet {
    @Resource(name="java:comp/DefaultDataSource")
    private javax.sql.DataSource dsc;
    ...
}

除了前面示例中的基于字段的注入以外，还可使用基于方法的注入注入资源：浏览器

public class MyServlet extends HttpServlet {
    private javax.sql.DataSource dsc;
    ...
    @Resource(name="java:comp/DefaultDataSource")
    public void setDsc(java.sql.DataSource ds) {
        dsc = ds;
    }
}

要使用基于方法的注入，setter方法必须遵循属性名称的JavaBeans约定：方法名称必须以set，以void返回类型开头，而且只有一个参数。安全

的@Resource注释是在javax.annotation包装和在JSR 250（通用注解用于Java平台）被定义。资源注入按名称解析，所以它不是类型安全的：资源对象的类型在编译时是未知的，所以若是对象的类型及其引用不匹配，则可能会出现运行时错误。服务器

依赖注入:网络

依赖注入能够将常规Java类转换为托管对象，并将它们注入任何其余托管对象。使用依赖注入，编写的代码能够声明对任何托管对象的依赖性。容器在运行时自动在注入点提供这些依赖项的实例，而且还能够管理这些实例的生命周期。

Java EE中的依赖注入定义了范围，这些范围肯定容器实例化和注入的对象的生命周期。例如，仅响应单个客户端请求（例如货币转换器）的托管对象与在会话中处理多个客户端请求（例如购物车）所需的托管对象具备不一样的范围。

能够经过将范围分配给常规类来定义稍后能够注入的托管对象（也称为托管bean）：

@javax.enterprise.context.RequestScoped
public class CurrencyConverter { ... }

使用javax.inject.Inject注释注入托管bean; 例如：

public class MyServlet extends HttpServlet {
    @Inject CurrencyConverter cc;
    ...
}

与资源注入相反，依赖注入是类型安全的，由于它按类型解析。要将代码与托管bean的实现分离，可使用接口类型引用注入的实例，并让托管bean实现该接口。

资源注入和依赖注入的区别：

注射机制

能够直接注入JNDI资源

能够直接注入常规类

解决了

类型安全

资源注入

是

没有

资源名称

没有

依赖注入

没有

是

类型

是

java中的容器：

容器是组件与支持该组件的低级平台特定功能之间的接口。在能够执行以前，必须将Web，企业bean或应用程序客户端组件组装到Java EE模块中并部署到其容器中。

组装过程涉及为Java EE应用程序中的每一个组件和Java EE应用程序自己指定容器设置。容器设置定制Java EE服务器提供的底层支持，包括安全性，事务管理，Java命名和目录接口（JNDI）API查找以及远程链接等服务。这儿是一些精彩片断。

Java EE安全模型容许您配置Web组件或企业bean，以便只有受权用户才能访问系统资源。
Java EE事务模型容许您指定组成单个事务的方法之间的关系，以便将一个事务中的全部方法视为一个单元。
JNDI查找服务为企业中的多个命名和目录服务提供统一接口，以便应用程序组件能够访问这些服务。
Java EE远程链接模型管理客户端和企业bean之间的低级通讯。建立企业bean后，客户端会在其上调用方法，就好像它位于同一个虚拟机中同样。

因为Java EE体系结构提供可配置服务，所以同一应用程序中的组件可能会根据它们的部署位置而有所不一样。例如，企业bean能够具备安全设置，容许它在一个生产环境中对数据库数据进行必定级别的访问，在另外一个生产环境中具备另外一级别的数据库访问。

容器还管理不可配置的服务，例如企业bean和servlet生命周期，数据库链接资源池，数据持久性以及对Java EE平台API的访问。

容器类型

部署过程在Java EE容器中安装Java EE应用程序组件。

Java EE服务器和容器

服务器和容器以下：

Java EE服务器：Java EE产品的运行时部分。Java EE服务器提供EJB和Web容器。
EJB容器：管理Java EE应用程序的企业bean的执行。Enterprise Bean及其容器在Java EE服务器上运行。
Web容器：管理Java EE应用程序的Web页面，servlet和一些EJB组件的执行。Web组件及其容器在Java EE服务器上运行。
应用程序客户端容器：管理应用程序客户端组件的执行。应用程序客户端及其容器在客户端上运行。
Applet容器：管理applet的执行。由一个Web浏览器和一个在客户端上运行的Java Plug-in组成。

容器和注入的历史和展望：

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系统相对接)。

容器之发展愿景

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

　　Docker、Rocket以及其它容器平台都没法运行在生产环境中的单一主机之上，这是由于它们都存在着单点故障隐患。尽管一整套容器集合可以运行在单一主机上，然而一旦该主机发生故障，全部运行于其上的容器也将全面瘫痪。谷歌公司在这方面抢先一步，凭借从Borg项目中积累到的经验打造出名为Kubernetes的开源容器集群管理系统。Docker公司也针对这一难题开发出了Docker Swarm解决方案。目前，这些解决方案尚处于早期发展阶段，并且可能还须要数月甚至一年才能真正具有完整的功能集，从而以稳定及普遍的方式被引入容器行业的生产环境当中。

　　微服务则是另外一项突破性技术成果，而不只仅是一套利用容器机制实现自身部署的软件架构。虽然微服务的概念算不上什么新鲜事物，但这种Web服务的轻量化实现机制确实可以提供远超过标准Web服务的启动速度。之因此可以实现这项目标，是由于其将一整套功能单元以打包方式(可能包括单一服务/API方法)整合在一项服务当中，再将服务嵌入一套轻量化Web服务器二进制文件。

　　考虑到以上背景信息，咱们能够预测在将来几年当中，容器技术将逐步取代虚拟机甚至可以在必定程度上完全占据其适用环境。去年，我曾经帮助多家企业立足于POC层级部署基于容器的解决方案。当时他们几乎还都不想把容器引入生产环境。然而这种情况可能随着容器集群管理系统的逐步成熟而快速获得扭转。

资料来源：java EE官网

Linux容器演变历程与将来发展前景