Container&injection(容器與注入思想)

container

爲了更好理解JAVA容器，查詢了容器的概念以及容器的誕生緣由和歷史：

　　容器技術是怎麼一個概念呢？其實，IT裏的容器技術是英文單詞Linux Container的直譯。container這個單詞有集裝箱、容器的含義（主要偏集裝箱意思）。不過，在中文環境下，我們要交流要傳授，若是翻譯成「集裝箱技術」 就有點拗口，因此結合中國人的吐字習慣和文化背景，更喜歡用容器這個詞。不過，若是要形象的理解Linux Container技術的話，仍是得念成集裝箱會比較好。咱們知道，海邊碼頭裏的集裝箱是運載貨物用的，它是一種按規格標準化的鋼製箱子。集裝箱的特點，在於其格式劃一，並能夠層層重疊，因此能夠大量放置在特別設計的遠洋輪船中（早期航運是沒有集裝箱概念的，那時候貨物雜亂無章的放，很影響出貨和運輸效率）。有了集裝箱，那麼這就更加快捷方便的爲生產商提供廉價的運輸服務。

　　所以，IT世界裏借鑑了這一理念。早期，你們都認爲硬件抽象層基於hypervisor的虛擬化方式能夠最大程度上提供虛擬化管理的靈活性。各類不一樣操做系統的虛擬機都能經過hypervisor（KVM、XEN等）來衍生、運行、銷燬。然而，隨着時間推移，用戶發現hypervisor這種方式麻煩愈來愈多。爲何？由於對於hypervisor環境來講，每一個虛擬機都須要運行一個完整的操做系統以及其中安裝好的大量應用程序。但實際生產開發環境裏，咱們更關注的是本身部署的應用程序，若是每次部署發佈我都得搞一個完整操做系統和附帶的依賴環境，那麼這讓任務和性能變得很重和很低下。

　　基於上述狀況，人們就在想，有沒有其餘什麼方式能讓人更加的關注應用程序自己，底層多餘的操做系統和環境我能夠共享和複用？換句話來講，那就是我部署一個服務運行好後，我再想移植到另一個地方，我能夠不用再安裝一套操做系統和依賴環境。這就像集裝箱運載同樣，我把貨物一輛蘭博基尼跑車（比如開發好的應用APP），打包放到一容器集裝箱裏，它經過貨輪能夠垂手可得的從上海碼頭（CentOS7.2環境）運送到紐約碼頭（Ubuntu14.04環境）。並且運輸期間，個人蘭博基尼（APP）沒有受到任何的損壞（文件沒有丟失），在另一個碼頭卸貨後，依然能夠完美風騷的賽跑（啓動正常）。

　　Linux Container容器技術的誕生（2008年）就解決了IT世界裏「集裝箱運輸」的問題。Linux Container（簡稱LXC）它是一種內核輕量級的操做系統層虛擬化技術。Linux Container主要由Namespace和Cgroup兩大機制來保證明現。那麼Namespace和Cgroup是什麼呢？剛纔咱們上面提到了集裝箱，集裝箱的做用固然是能夠對貨物進行打包隔離了，不讓A公司的貨跟B公司的貨混在一塊兒，否則卸貨就分不清楚了。那麼Namespace也是同樣的做用，作隔離。光有隔離還沒用，咱們還須要對貨物進行資源的管理。一樣的，航運碼頭也有這樣的管理機制：貨物用什麼樣規格大小的集裝箱，貨物用多少個集裝箱，貨物哪些優先運走，遇到極端天氣怎麼暫停運輸服務怎麼改航道等等... 通用的，與此對應的Cgroup就負責資源管理控制做用，好比進程組使用CPU/MEM的限制，進程組的優先級控制，進程組的掛起和恢復等等。

　　

什麼是java容器？

　　類似的，docker容器中若是裝的是app，java容器中裝載的就是組件 ，而容器以外的程序須要和這些組件交互必須經過容器 。

　　舉個例子，IE發送了一個請求給容器，容器經過調用其中的一個組件進行相關處理以後將結果反饋給IE，這種與客戶端軟件交互的組件就叫作servlet

那什麼是組件呢？

　　組件其實就是一個應用程序塊 。可是它們不是完整的應用程序，不能單獨運行 。就有如一輛汽車，車門是一個組件，車燈也是一個組件 。可是光有車燈車門沒有用，它們不能跑上公路 。在java中這些組件就叫作javabean，有點像微軟之前的com組件 。

　　要特別說明的是，因爲任何一個java文件編譯之後都是以類的形式存在 。因此javabean確定也是一個類，這是毫無疑問的。

 

 

injection

　　 Java的依賴注入：依賴注入，出自spring的IOC和DI，是Spring的兩大特性之一（另外一個AOP面向切面編程）

 　　之前對象使咱們手動實例化，好比：Service層調用Dao層，須要Dao d = new Dao；可是這樣會致使兩個層之間的耦合性大大加強。而spring的IOC，反轉控制，會在咱們須要實例對象的時候，由spring容器爲咱們提供，並經過DI依賴注入來實現目標對象的得到，完成解耦操做。

　　能夠經過setter方法注入、構造注入、註解注入。　　依賴注入是Spring的思想,在使用Spring進行開發時，能夠將對象交給spring進行管理，在初始化時spring建立一批對象，當你須要用的時候只要從spring的容器中獲取對象，而不用本身去new，固然在對象建立的時候能夠注入另外一個對象。好比A,B兩個對象都由spring管理，A中持有對B的引用，那麼spring在生成A對象的時候就已經吧B對象的一個實例給到A了，當你在A中用到B的時候直接使用就能夠了。

 

以上摘自網站或參考網站：https://blog.csdn.net/u010325193/article/details/80195168  https://cloud.tencent.com/developer/article/1116709?fromSource=waitui

 

通過對容器的理解，我的對將來容器的見解和發展趨勢作如下估測：

　　容器技術感受目前來講已經很強大了，能夠作不少事情，應該也將會愈來愈完善，功能也可能會更加智能化

　　因爲學識淺薄，我的認爲技術發展是不會趨於飽和化的。所以容器技術會發展成智能工做的移動生產車間？（可能理解不夠？有什麼不對的地方見諒以及指出錯誤）