微服務為什么一定要用docker

      網友投稿 802 2025-03-31

      引言


      早在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之間聊天內容是這樣的

      開發:"你去測試環境上,按照開發環境一樣,再去搭三套一樣的測試環境!"

      測試:"我….."

      幾個小時過去了…

      微服務為什么一定要用docker

      測試:"你幫我看看,為什么啟動報錯,是不是漏配了什么參數?"

      開發:"我…."

      于是接下來幾個小時就這么愉快的和測試mm一起聊天中過去了??!嗯,我相信有些公司是為了解決開發的單身問題,才不使用docker,用心良苦!

      然而,和運維GG之間聊天一般是這樣的

      運維:"開發這群腦殘,發布的新war包,又把生產搞掛了!"

      開發:"這幫運維傻叉么,我本地好好的,怎么一上生產就不行了!"

      于是接下來的幾個小時,就在和運維之間的撕逼中過去了!嗯,最終苦的是用戶??!

      現在:自從用上docker容器后,可以實現開發、測試和生產環境的統一化和標準化。鏡像作為標準的交付件,可在開發、測試和生產環境上以容器來運行,最終實現三套環境上的應用以及運行所依賴內容的完全一致。

      在現在微服務的架構中,一個應用拆成幾十個微服務,每個微服務都對應有開發、測試、生產三套環境需要搭建。自己算算,如果采用傳統的部署方式,有多少環境需要部署。曾聽聞某公司在新建一個項目的時候,要花整整一個禮拜來搭建環境,簡直是慘不忍睹!

      什么,你和我說,你們用上了docker,卻還存在這些問題?

      筆者曾見過某些公司是這么用docker的。確實虛擬化出容器了,然后在容器上建立ssh server。接下來就厲害了,部署方式完全沒變,直接連上容器,一切部署照舊!對此,我也是一言難盡??!你們這是給領導搭的docker么?

      輕量和高效

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

      現在:

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

      筆者注:筆者一直覺得這個特性只是一個障眼法。

      比如,你說容器啟動速度快?難道你工作中吃飽了撐著沒事干,一直重啟虛擬機么?

      你說虛擬機消耗資源多?絕大部分公司的服務器資源利用率應該都不到 50%,大量的CPU、內存、本地磁盤都是常年浪費的,所以 VM 的額外開銷不過是浪費了原本就在浪費的資源罷了。所以筆者認為,對于傳統應用來說,使用和不使用Docker可能并不能直接給企業帶來好處,相反使用中遇到了問題肯定會給企業帶來麻煩,對于傳統企業來說,不要盲目跟風,VM虛擬機其實夠用了!。

      總結

      在技術演進中,docker只是趨勢,并不是結果。相信在未來,一定有更高大上的部署架構出現!

      本文轉載自公眾號【java學習之道】。

      微服務

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。

      上一篇:excel2003文本框插入教程
      下一篇:【AI理論深度解讀華為云一站式AI 開發平臺 ModelArts 技術架構
      相關文章
      亚洲人成电影在线观看青青| 国产亚洲精品xxx| 337p日本欧洲亚洲大胆色噜噜| 亚洲乱码国产一区三区| 久久久无码精品亚洲日韩软件 | 亚洲XX00视频| 18禁亚洲深夜福利人口| 亚洲AV男人的天堂在线观看| www.亚洲日本| 亚洲最大无码中文字幕| 亚洲精品人成网在线播放影院| 亚洲五月丁香综合视频| 亚洲男人天堂2018av| 亚洲国产欧美一区二区三区| 亚洲av无码一区二区三区人妖| 亚洲爆乳AAA无码专区| 国产成人精品日本亚洲语音| 国产精品亚洲一区二区无码| 天堂亚洲免费视频| 亚洲中久无码不卡永久在线观看| 国产精品亚洲精品日韩已方| 国产亚洲精品无码拍拍拍色欲| 亚洲乳大丰满中文字幕| 亚洲AV福利天堂一区二区三| 亚洲一二成人精品区| 亚洲免费闲人蜜桃| 亚洲一卡一卡二新区无人区| 亚洲大码熟女在线观看| 亚洲精品成人片在线观看| 亚洲中文字幕无码中文字在线 | 亚洲成A人片777777| 日韩精品一区二区亚洲AV观看| 亚洲午夜在线一区| 亚洲人成电影网站免费| 精品久久久久亚洲| 国产亚洲精午夜久久久久久| 亚洲AV永久青草无码精品| 亚洲精品在线电影| 亚洲中文字幕一二三四区| 国产区图片区小说区亚洲区| 久久久久久亚洲精品不卡|