微服務爲何必定要用docker

引言

早在2013年的時候，docker就已經發行，然而那會仍是不多人瞭解docker。一直到2014年，Martin Fowler提出了微服務的概念，兩個不相干的技術終於走在了一塊兒，創造了今天的輝煌！
近幾年來，不少互聯網關係開始跟風，構建docker+微服務的架構體系。然而，根據筆者觀察發現，有些童鞋在使用過程當中，只是會用，而根本不瞭解爲何使用docker，反正對他們來講，公司讓用就用！而某些公司呢，雖然用上了docker，然而運維方式並無發生改變，白白浪費了docker的大好性能！
所以，纔有了本文的誕生。本文不會教你怎麼去用什麼docker的api，畢竟官網document很全面，而是去講解docker的優勢，進而說明爲何適合微服務的架構！

正文

這裏必需要先說明物理機、虛擬機、容器三者的優缺點。筆者不想去列一堆的概念，直接借用知乎的一個回答，回答地址爲:
https://www.zhihu.com/question/48174633/answer/229253704
這裏借用一下這位大神的三張圖，他的回答就三張圖！

基本概念

所謂的物理機就是下面這樣的別墅

那麼虛擬機機就是下面這樣的套房

最後就是咱們的容器，就是下面這樣的膠囊公寓

那麼，專業的說法就是，容器是一種輕量級、可移植、自包含的軟件打包技術，使應用程序能夠在幾乎任何地方以相同的方式運行。容器之間是共享同一套操做系統資源的，因爲容器是共享主操做系統的內核，所以就沒法在服務器上運行與主服務器不一樣的操做系統，也就是說不能再Linux的服務器上運行Windows。就如上面哪一個圖同樣，每一個膠囊容器是公用一個廁所，廚房，每一個膠囊內沒法再構建出本身的廁所和廚房！

容器的優點

隔離強

過去:曾記得12年那會，部門要上一個項目。那會，我是這麼幹的。直接去線上服務器，拷貝一個tomcat，而後改端口號，而後部署應用到webapps文件夾下，重啓就好。並且我能夠摸着良心說，如今還有不少傳統企業是這麼作的。
那麼這麼作的缺點？
很明顯，應用之間相互影響。一個應用出現問題，CPU100%了，這個服務器上的其餘應用一塊兒涼涼。一個大型應用拆分爲幾十個微服務，分別交由不一樣的團隊開發，不一樣團隊之間水平良莠不齊。若是還採用這種部署方式，你的應用和某個坑爹團隊的應用部署在了同一臺服務器上，至於結果，我相信你懂的。

如今:用上了docker容器後，將Docker能夠將咱們的應用程序打包封裝到一個容器中，該容器包含了應用程序的代碼、運行環境、依賴庫、配置文件等必需的資源。容器之間達到進程級別的隔離，在容器中的操做，不會影響道宿主機和其餘容器，這樣就不會出現應用之間相互影響的情形！

可移植性

過去:曾幾什麼時候咱們和測試MM之間聊天內容是這樣的

開發:"你去測試環境上，按照開發環境同樣，再去搭三套同樣的測試環境！"
測試:"我....."
幾個小時過去了...
測試:"你幫我看看，爲何啓動報錯，是否是漏配了什麼參數?"
開發:"我...."

因而接下來幾個小時就這麼愉快的和測試mm一塊兒聊天中過去了！！嗯，我相信有些公司是爲了解決開發的單身問題，纔不使用docker,用心良苦!

然而，和運維GG之間聊天通常是這樣的

運維:"開發這羣腦殘，發佈的新war包，又把生產搞掛了！"
開發:"這幫運維傻叉麼，我本地好好的，怎麼一上生產就不行了！"
...

因而接下來的幾個小時，就在和運維之間的撕逼中過去了!嗯，最終苦的是用戶啊！

如今:自從用上docker容器後，能夠實現開發、測試和生產環境的統一化和標準化。鏡像做爲標準的交付件，可在開發、測試和生產環境上以容器來運行，最終實現三套環境上的應用以及運行所依賴內容的徹底一致。
在如今微服務的架構中，一個應用拆成幾十個微服務，每一個微服務都對應有開發、測試、生產三套環境須要搭建。本身算算，若是採用傳統的部署方式，有多少環境須要部署。曾聽聞某公司在新建一個項目的時候，要花整整一個禮拜來搭建環境，簡直是慘不忍睹!

什麼，你和我說，大家用上了docker，卻還存在這些問題？
筆者曾見過某些公司是這麼用docker的。確實虛擬化出容器了，而後在容器上創建ssh server。接下來就厲害了，部署方式徹底沒變，直接連上容器，一切部署照舊！對此，我也是一言難盡啊！大家這是給領導搭的docker麼？

輕量和高效

過去:在2016年的時候，那會在另外一家大廠工做。這家稍微規範一點了，一個應用部署在一個虛擬機上！當時最大的體會就是一個，虛擬機很是重，構建速度慢，且佔用資源多，一臺物理機上只能起十來個虛擬機！

如今:
和虛擬機相比，容器僅須要封裝應用和應用須要的依賴文件，實現輕量的應用運行環境，且擁有比虛擬機更高的硬件資源利用率。在微服務架構中，有些服務負載壓力大，須要以集羣部署，可能要部署幾十臺機器上，對於某些中小型公司來講，使用虛擬機，代價太大。若是用容器，一樣的物理機則能支持上千個容器，對中小型公司來講，省錢！

筆者注：筆者一直以爲這個特性只是一個障眼法。
好比，你說容器啓動速度快？難道你工做中吃飽了撐着沒事幹，一直重啓虛擬機麼？
你說虛擬機消耗資源多？絕大部分公司的服務器資源利用率應該都不到 50%，大量的CPU、內存、本地磁盤都是常年浪費的，因此 虛擬機 的額外開銷不過是浪費了本來就在浪費的資源罷了。因此筆者認爲，對於傳統應用來講，使用和不使用Docker可能並不能直接給企業帶來好處，相反使用中遇到了問題確定會給企業帶來麻煩，對於傳統企業來講，不要盲目跟風，VM虛擬機其實夠用了！。

總結

在技術演進中，docker只是趨勢，並非結果。相信在將來，必定有更高大上的部署架構出現!

歡迎工做一到五年的Java工程師朋友們加入Java架構開發：760940986 羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！