第二週 - 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容器演變歷程與將來發展前景