如何實作容器服務

轉載：

https://www.cnblogs.com/rjzheng/p/10088885.html

引言

早在2013年的時候，docker就已經發行，然而那會還是很少人了解docker。一直到2014年，Martin Fowler提出了微服務的概念，兩個不相幹的技術終于走在了一起，創造了今天的輝煌！ 近幾年來，很多網際網路關系開始跟風，建構docker+微服務的架構體系。然而，根據筆者觀察發現，有些童鞋在使用過程中，隻是會用，而根本不了解為什麼使用docker，反正對他們來說，公司讓用就用！而某些公司呢，雖然用上了docker，然而運維方式并沒有發生改變，白白浪費了docker的大好性能！ 是以，才有了本文的誕生。

本文不會教你怎麼去用什麼docker的api，畢竟官網document很全面，而是去講解docker的優點，進而說明為什麼适合微服務的架構！

正文

容器是一種輕量級、可移植、自包含的軟體打包技術，使應用程式可以在幾乎任何地方以相同的方式運作。容器之間是共享同一套作業系統資源的，由于容器是共享主作業系統的核心，是以就無法在伺服器上運作與主伺服器不同的作業系統，也就是說不能再Linux的伺服器上運作Windows。

就如上面哪個圖一樣，每個膠囊容器是公用一個廁所，廚房，每個膠囊内無法再建構出自己的廁所和廚房！ 容器的優勢 隔離強

過去:曾記得12年那會，部門要上一個項目。那會，我是這麼幹的。直接去線上伺服器，拷貝一個tomcat，然後改端口号，然後部署應用到webapps檔案夾下，重新開機就好。而且我可以摸着良心說，現在還有很多傳統企業是這麼做的。 那麼這麼做的缺點？ 很明顯，應用之間互相影響。一個應用出現問題，CPU100%了，這個伺服器上的其他應用一起涼涼。一個大型應用拆分為幾十個微服務，分别交由不同的團隊開發，不同團隊之間水準參差不齊。

如果還采用這種部署方式，你的應用和某個坑爹團隊的應用部署在了同一台伺服器上，至于結果，我相信你懂的。

現在:用上了docker容器後，将Docker可以将我們的應用程式打包封裝到一個容器中，該容器包含了應用程式的代碼、運作環境、依賴庫、配置檔案等必需的資源。容器之間達到程序級别的隔離，在容器中的操作，不會影響道主控端和其他容器，這樣就不會出現應用之間互相影響的情形！ 可移植性

過去:曾幾何時我們和測試MM之間聊天内容是這樣的 開發:"你去測試環境上，按照開發環境一樣，再去搭三套一樣的測試環境！" 測試:"我….." 幾個小時過去了… 測試:"你幫我看看，為什麼啟動報錯，是不是漏配了什麼參數?" 開發:"我…." 于是接下來幾個小時就這麼愉快的和測試mm一起聊天中過去了！！嗯，我相信有些公司是為了解決開發的單身問題，才不使用docker,用心良苦! 然而，和運維GG之間聊天一般是這樣的 運維:"開發這群腦殘，釋出的新war包，又把生産搞挂了！" 開發:"這幫運維傻叉麼，我本地好好的，怎麼一上生産就不行了！" … 于是接下來的幾個小時，就在和運維之間的撕逼中過去了!嗯，最終苦的是使用者啊！

現在:自從用上docker容器後，可以實作開發、測試和生産環境的統一化和标準化。鏡像作為标準的傳遞件，可在開發、測試和生産環境上以容器來運作，最終實作三套環境上的應用以及運作所依賴内容的完全一緻。 在現在微服務的架構中，一個應用拆成幾十個微服務，每個微服務都對應有開發、測試、生産三套環境需要搭建。自己算算，如果采用傳統的部署方式，有多少環境需要部署。曾聽聞某公司在建立一個項目的時候，要花整整一個禮拜來搭建環境，簡直是慘不忍睹! 什麼，你和我說，你們用上了docker，卻還存在這些問題？

筆者曾見過某些公司是這麼用docker的。确實虛拟化出容器了，然後在容器上建立ssh server。接下來就厲害了，部署方式完全沒變，直接連上容器，一切部署照舊！對此，我也是一言難盡啊！你們這是給上司搭的docker麼？ 輕量和高效

過去:在2016年的時候，那會在另一家大廠工作。這家稍微規範一點了，一個應用部署在一個虛拟機上！當時最大的體會就是一個，虛拟機非常重，建構速度慢，且占用資源多，一台實體機上隻能起十來個虛拟機！

現在: 和虛拟機相比，容器僅需要封裝應用和應用需要的依賴檔案，實作輕量的應用運作環境，且擁有比虛拟機更高的硬體資源使用率。在微服務架構中，有些服務負載壓力大，需要以叢集部署，可能要部署幾十台機器上，對于某些中小型公司來說，使用虛拟機，代價太大。如果用容器，同樣的實體機則能支援上千個容器，對中小型公司來說，省錢！

%%%%

總結

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

歡迎下方留言探讨。