Docker的優缺點

Docker 主要解決環境配置問題，它是一種虛擬化技術，對程式進行隔離，被隔離的程式獨立於宿主作業系統和其它隔離的程式。

由於不同的機器有不同的作業系統，以及不同的庫和元件，在將一個應用部署到多臺機器上需要進行大量的環境配置操作。

Docker 主要解決環境配置問題，它是一種虛擬化技術，對程式進行隔離，被隔離的程式獨立於宿主作業系統和其它隔離的程式。使用 Docker 可以不修改應用程式程式碼，不需要開發人員學習特定環境下的技術，就能夠將現有的應用程式部署在其它機器上。

虛擬機器也是一種虛擬化技術，它與 Docker 最大的區別在於它是透過模擬硬體，並在硬體上安裝作業系統來實現。

啟動虛擬機器需要先啟動虛擬機器的作業系統，再啟動應用，這個過程非常慢；

而啟動 Docker 相當於啟動宿主作業系統上的一個程式。

虛擬機器是一個完整的作業系統，需要佔用大量的磁碟、記憶體和 CPU 資源，一臺機器只能開啟幾十個的虛擬機器。

而 Docker 只是一個程式，只需要將應用以及相關的元件打包，在執行時佔用很少的資源，一臺機器可以開啟成千上萬個 Docker。

映象是一種靜態的結構，可以看成物件導向裡面的類，而容器是映象的一個例項。

映象包含著容器執行時所需要的程式碼以及其它元件，它是一種分層結構，每一層都是隻讀的（read-only layers）。構建映象時，會一層一層構建，前一層是後一層的基礎。映象的這種分層儲存結構很適合映象的複用以及定製。

構建容器時，透過在映象的基礎上新增一個可寫層（writable layer），用來儲存著容器執行過程中的修改。

你一定還有印象，在我們最開始學習程式設計的時候，搭建環境這一步往往會耗費我們好幾個小時的時間，而且其中一個小問題可能需要找很久才能夠解決。你還會得到關於環境搭建方面的團隊其他成員的求助。而有了容器之後，這些都變得非常容易，你的開發環境就只是一個或者幾個容器映象的地址，最多再需要一個控制部署流程的執行 。或者進一步將你的環境映象以及映象 放入一個git專案，釋出到雲端，需要的時候將它拉到本地就可以了。

# git clone 
# sh ./my-build-boot.sh

目前我們團隊目前基本都是用這種方案搭建本地開發環境，而且整理成內部技術文件，慢慢沉澱成團隊的財富了。

當我們收到一個bug反饋的時候，很多時候心裡面的第一反應一定是“我本地是好的啊”！這種情況的發生就在於環境的不一致，我們在開發過程中的除錯往往不能保證其他環境的問題，但是我們卻要為此買單，這真是一件令人苦惱的事情。有了容器之後，這將很少發生。我們可以透過容器技術將開發環境和測試環境以及生產環境保持版本和依賴上的統一，保證程式碼在一個高度統一的環境上執行。而測試環境的統一，也同樣能解決CI流程對環境的要求。

分散式技術和擴容需求日益增長的今天，如果運維能夠使用容器技術來進行環境的部署，不僅僅在部署時間上節省不少，也能把很多因為人工配置環境產生的失誤降到最低。

不管是開發還是生產，往往我們一臺機器上可能需要跑多個服務，而服務各自需要的依賴配置不盡相同，假如說兩個應用需要使用同一個依賴，或者兩個應用需要的依賴之間會有一些衝突，這個時候就很容易出現問題了。所以同一臺伺服器上不同應用提供的不同服務，最好還是將其隔離起來。而容器在這方面有天生的優勢，每一個容器就是一個隔離的環境，你對容器內部提供服務的要求，容器可以自依賴的全部提供。這種高內聚的表現可以實現快速的分離有問題的服務，在一些複雜系統中能實現快速排錯和及時處理。(當然需要說明的是，這個隔離性只是相對於伺服器比較的，虛機技術要擁有更好的隔離性)

容器之前的回滾機制，一般需要基於上個版本的應用重新部署，且替換掉目前的問題版本。在最初的時代，可能是一套完整的開發到部署的流程，而執行這一套流程往往需要很長的時間。在基於git的環境中，可能是回退某個歷史提交，然後重新部署。這些跟容器技術相比都不夠快，而且可能會引起新的問題（因為是基於新版本的修改）。而容器技術天生帶有回滾屬性，因為每個歷史容器或者映象都會有儲存，而替換一個容器或者某個歷史映象是非常快速和簡單的。

這可能是一個最明顯和有用的優點了，在容器出現之前，我們往往構築一個應用就需要一臺新的伺服器或者一臺虛機。伺服器的購置成本和運維成本都很高，而虛機需要佔用很多不必要的資源。相比之下，容器技術就小巧輕便的多，只需要給一個容器內部構建應用需要的依賴就可以了，這也是容器技術發展迅速的最主要原因。

隨著容器技術的不斷普及和發展，隨之而來的容器管理和編排技術也同樣得到發展。諸如Docker Swarm，Kubernetes, Mesos等編排工具也在不斷的迭代更新，這讓容器技術在生產環境中擁有了更多的可能性和更大的發揮空間。而隨著大環境的發展，docker等容器的使用和學習的成本也是愈發降低，成為更多開發者和企業的選擇。

說了這麼多的優點，容器也有一些問題是沒有解決的。上一代方案基本就是基於虛機技術的雲方案，能有效增加伺服器的使用效率，達到節省成本的目的，而容器技術在此基礎上更進一步地最佳化了資源的使用率。但是仍然有一些問題，是我們在選擇服務資源架構場景中需要考慮的：

基於hypervisor的虛機技術，在隔離性上比容器技術要更好，它們的系統硬體資源完全是虛擬化的，當一臺虛機出現系統級別的問題，往往不會蔓延到同一宿主機上的其他虛機。但是容器就不一樣了，容器之間共享同一個作業系統核心以及其他元件，所以在收到攻擊之類的情況發生時，更容易透過底層作業系統影響到其他容器。當然，這個問題可以透過在虛機中部署容器來解決，可是這樣又會引出新的問題，比如成本的增加以及下面要提到的問題：效能。

不管是虛機還是容器，都是運用不同的技術，對應用本身進行了一定程度的封裝和隔離，在降低應用和應用之間以及應用和環境之間的耦合性上做了很多努力，但是隨機而來的，就會產生更多的網路連線轉發以及資料互動，這在低併發系統上表現不會太明顯，而且往往不會成為一個應用的瓶頸（可能會分散於不同的虛機或者伺服器上），但是當同一虛機或者伺服器下面的容器需要更高併發量支撐的時候，也就是併發問題成為應用瓶頸的時候，容器會將這個問題放大，所以，並不是所有的應用場景都是適用於容器技術的。

容器的誕生並不是為OS抽象服務的，這是它和虛機最大的區別，這樣的基因意味著容器天生是為應用環境做更多的努力，容器的伸縮也是基於容器的這一disposable特性，而與之相對的，需要持久化儲存方案恰恰相反。這一點docker容器提供的解決方案是利用volume介面形成資料的對映和轉移，以實現資料持久化的目的。但是這樣同樣也會造成一部分資源的浪費和更多互動的發生，不管是對映到宿主機上還是到網路磁碟，都是退而求其次的解決方案。

隨著硬體技術和網路技術的迭代發展，容器技術的缺點會變得越來越不那麼明顯，而且隨著容器技術的發展和普及，對應的解決方案也會越來越多。所以總體來看，docker等容器技術會朝著更加普及的趨勢走近我們技術領域。也希望每一位熱愛技術的小夥伴們能更加了解這些新技術，讓它們能夠更好的為我們服務。

原文地址：