摘要：并不是因為它是閃亮的新事物或者它是一些虛構(gòu)的最佳實踐，而是因為像亞馬遜或者已經(jīng)在這上面投入了年的心血，他們告訴了我們?nèi)绾螛?gòu)建真正有規(guī)模的系統(tǒng)。截止目前，我們已經(jīng)部署了由亞馬遜等提供的重量級虛擬化服務(wù)器。

周一時候數(shù)人云與大家分享了一篇關(guān)于Docker的反方言論——《一份Docker的反方辯論——我還是用Heroku好了》，一周之后，同樣的作者，又為Docker正名，寫了一篇正方言論。Docker的未來在何處？且看下文分解——

之前我寫了一篇《It’s the Future》的文章，點評了容器生態(tài)系統(tǒng)，順帶嘲弄了下Docker、Google、CoreOS和一系列其他技術(shù)。許多Docker愛好者非常喜歡結(jié)尾那個玩笑，但是也有很多人喜歡那句“我告訴你們它們都是渣渣”。

不難理解為什么人們會認為容器生態(tài)系統(tǒng)是“渣渣”，尤其是從我上篇的角度來看。畢竟，匆忙的一瞥很難弄清楚Docker到底是什么。容器化有點像虛擬化，但是并不完全一樣。它有一個類似Chef的Dockerfile，但是是和一個和分層相關(guān)的文件系統(tǒng)結(jié)合的。它和AWS 、Heroku 、 VMware 和Vagrant一樣解決類似的問題，但是又有些不同。它有27個彼此有競爭關(guān)系的工具，很難說上來它們具體干嘛用，名字也都非常有意思——比如machine、 swarm 、 flannel 、 weave 、 etcd 、 rkt 、 kubernetes 、 compose 和 flocker等等。它一定程度上和新興的微服務(wù)有關(guān)聯(lián)，但是要去考慮如何讓單一服務(wù)首先跑起來又顯得很蠢。

如果仔細看過了Docker和容器，仍然認為它是渣渣，那么也可以理解——除非它不是。

好吧，它確實不是，它是我們搭建應(yīng)用的未來。

許多看了《It’s the Future》的人覺得文章寫的非常準(zhǔn)確，并沒有諷刺和夸張，然后質(zhì)疑了容器這個事物，為什么呢？

Docker和其容器生態(tài)系統(tǒng)（之后簡稱“Docker”）正在改變應(yīng)用開發(fā)世界的一些基礎(chǔ)，比如虛擬化、面向服務(wù)的架構(gòu)和操作系統(tǒng)，然后把它們以不同的目標(biāo)和優(yōu)勢重新交付。但同時，也觸怒了開發(fā)者社區(qū)的一些人——守舊而討厭新事物的頑固派。

軟件行業(yè)可能與想象中不同，其實充滿了抵制進步的人們——就如同當(dāng)米開朗琪羅完成了他的創(chuàng)作，那群走進西斯廷教堂的人們卻開始聲稱他們已經(jīng)有了很好的上帝畫作，他們更喜歡天花板是純白的，米開朗琪羅的壁畫一點都不美好。

同時，大部分的軟件行業(yè)像高中學(xué)生一樣做著決策：他們著迷地搜索著他們小團體內(nèi)更酷的東西，看看Instagram和 Facebook上都有什么，然后盲目地追隨著他們的引導(dǎo)者。這些技術(shù)形成了各自的派系，精心雕琢著各自的技術(shù)——甚至?xí)诠P記本上貼上屬于他們的標(biāo)志和顏色，并且排斥和抱怨他們陌生或者不同的技術(shù)。

而進入的那個世界的Docker——幾乎所有的工作方式都是新的。它拋棄了各種舊規(guī)則——包括操作系統(tǒng)、部署、運維、 封裝、防火墻、PaaS等等。一些開發(fā)者立刻愛上了它，有時候是因為它有效解決了一些問題，有時候是因為它是閃亮的玩具——讓他們在其他孩子玩到它之前顯得很酷。另一些開發(fā)者則討厭它，討厭它大肆的宣傳和炒作，認為它就和其他之前新出的技術(shù)一樣，并沒有什么不同，卻被人人談?wù)撝?/p>

因此，很多人對于Docker的感受并不是源于技術(shù)本身。許多Docker的反感者并不是厭惡Docker在重要和復(fù)雜問題上的解決能力。如果他們沒有花足夠的時間去了解大規(guī)模系統(tǒng)的擴縮，絕大多數(shù)問題他們是沒法理解的。如果不是直觀且深入地了解過，那么關(guān)于Docker的很多選項和相關(guān)的工具都會看起來很奇怪很嚇人。

Docker出現(xiàn)在兩個學(xué)科的結(jié)合點上——Web應(yīng)用和分布式系統(tǒng)。對于過去的十年，我們在web社區(qū)很多時候都在假裝只要知道如何編程就可以搭建web應(yīng)用。我們寫一些HTML、 JavaScript 、 Rails，然后我們就有了一個網(wǎng)頁。我們加一些窗口、處理程序和一個API，然后我們就完成了它。之后發(fā)布產(chǎn)品，就能夠吸引用戶，獲得收入，就改變這個世界了！

而同時，過去的二十年間，分布式系統(tǒng)的家伙一直在做一些相當(dāng)無聊的東西。他們使用CORBA和SOAP這樣復(fù)雜的協(xié)議進行試驗，學(xué)會了如何處理像CAP定理這樣的問題，了解了時鐘同步是何等重要，認識到Two Generals Problem等主要理論。這些問題和解決方案對于只是想簡單地編程和交付應(yīng)用的人來說，相當(dāng)?shù)姆ξ稛o聊。

但是之后有趣的事情發(fā)生了。Web應(yīng)用變得非常大，開始變得規(guī)模化。很多人進入互聯(lián)網(wǎng)，web應(yīng)用不能只在單一VPS上，或者只是垂直方向擴展。我們開始擴大它的規(guī)模，然后我們看到了應(yīng)用中的各種bug，它們的名字很有趣：像“raceconditions”，“networkpartitions”，“ deadlock”和“Byzantine failures”等。這些問題是分布式系統(tǒng)的那些家伙搞了很久的問題，很多問題的解決方案不只是困難，理論上甚至是不可解的。

在擴展危機的早期，Heroku出來了。Heroku可以使我們很容易地在基礎(chǔ)設(shè)施水平層面上進行擴展，讓我們再一次假裝只做簡單web應(yīng)用。于是那五年，我們花錢買的是自欺欺人的假裝。

我們現(xiàn)在走到了自欺欺人的邊界上，輕輕一腳邁了出來，我們在試圖建立早期的擴展性，重構(gòu)破碎的事物，了解了單體應(yīng)用架構(gòu)的缺點以及為什么單一數(shù)據(jù)庫不能持續(xù)為我們工作。我們提出了一些概念，像不可變架構(gòu)，“寵物還是放養(yǎng)”，微服務(wù)，以及一整套最佳和最差實踐來嘗試讓問題簡單化。

在這個轉(zhuǎn)變中，Docker入局，嘗試解決很多問題。但是與Heroku那樣告訴我們可以假裝擴展問題不存在、可以繼續(xù)按照過去的方式來行事不同，Docker告訴我們分布式系統(tǒng)是我們一直在做的基礎(chǔ)，我們需要接受它并在這個模型下工作。不再像過去的web框架、數(shù)據(jù)庫和操作系統(tǒng)那樣只處理簡單問題，我們現(xiàn)在使用Swarm、Weave、Kubernetes和etcd等工具，不再假裝一切都很簡單。實際上，我們不再是單純解決問題，而是深入了解我們正在解決的問題。

我們終于有能力構(gòu)建可伸縮的架構(gòu)而不是假裝它只是抽象事物了?，F(xiàn)在我們需要了解什么是網(wǎng)絡(luò)分區(qū)并且如何處理它，如何在AP和CP系統(tǒng)中做出選擇，如何構(gòu)建在現(xiàn)有網(wǎng)絡(luò)和機器的約束下仍然可以擴展的架構(gòu)——有時在弗吉尼亞州發(fā)生一場風(fēng)暴，有時會發(fā)生火災(zāi)，有時鯊魚會咬斷海底電纜，有時會是一個延遲、一個交付失敗、機器死機或者抽象層有了裂縫，意外總是不時發(fā)生，不是嗎？

一切都渴望更有彈性、更可靠，作為開發(fā)應(yīng)用的一部分這些都是需要考慮的。并不是因為它是閃亮的新事物、或者它是一些虛構(gòu)的最佳實踐，而是因為像亞馬遜、Netflix或者Google已經(jīng)在這上面投入了15年的心血，他們告訴了我們?nèi)绾螛?gòu)建真正有規(guī)模的系統(tǒng)。

所以，Docker到底為我們解決了什么問題？我們?yōu)榇罱╳eb應(yīng)用而做的每件事都是脆弱而混亂的，Docker正在讓它變得清晰而條理：

截止目前，我們已經(jīng)部署機器（DevOps中的運維部分）和應(yīng)用（開發(fā)部分）分離，甚至我們有兩個不同的團隊來管理這部分應(yīng)用的堆棧。然而這很可笑，因為應(yīng)用像依賴代碼一樣依賴著機器和OS，考慮把它們分開沒有意義。容器在開發(fā)者工具的幫助下可以統(tǒng)一管理OS和應(yīng)用。

截止目前，我們一直在AWS上運行我們的面向服務(wù)的體系架構(gòu)、Heroku、其他PaaS和IaaS，缺乏真正的工具來管理面向服務(wù)的架構(gòu)，而Kubernetes和Swarm管理和編排了這些服務(wù)。

截止目前，我們已經(jīng)使用整個操作系統(tǒng)來部署我們的應(yīng)用。容器允許我們公開一個非常小的應(yīng)用程序，只需要一些端口——小到一個靜態(tài)二進制。

截止目前，機器上線后我們一直通過使用“配置管理”工具或者在同一臺機器上重新部署應(yīng)用來擺弄它們。由于容器是通過編排框架來實現(xiàn)規(guī)模擴縮，只需不變的鏡像來啟動，跑的機器不會被重復(fù)使用，消除了潛在的故障點。

截止目前，很大程度上我們一直在使用單個機器為單體應(yīng)用設(shè)計的語言和框架。在這之前，Rail為面向服務(wù)架構(gòu)設(shè)計的路線沒有真正存在過?，F(xiàn)在Kubernetes和Compose允許我們在服務(wù)之上指定拓撲結(jié)構(gòu)。

截止目前，我們已經(jīng)部署了由亞馬遜等提供的重量級虛擬化服務(wù)器。然而我們不能說“我想要0.1個CPU，和200MB的內(nèi)存”。我們已經(jīng)浪費了很多虛擬化的開銷和超出應(yīng)用所需的資源。而容器可以更少需求地進行部署，并且更好地進行共享。

截止目前，我們已經(jīng)在多用戶操作系統(tǒng)上部署了應(yīng)用和服務(wù)。多個用戶可以同時跑在Unix上，共享文件、數(shù)據(jù)庫、文件系統(tǒng)和服務(wù)。當(dāng)我們搭建web服務(wù)時，它會與我們的工作完全不匹配。而容器可以保存簡單文件而不是整個操作系統(tǒng)，讓我們減少對于應(yīng)用和服務(wù)的考慮。

我們的行業(yè)發(fā)展如此迅速，對于新技術(shù)狂熱崇拜并且不會等技術(shù)真正落地成熟。Docker正在以不可思議的速度發(fā)展著，這也意味著它還沒有接近穩(wěn)定和成熟。對于容器運行時、鏡像格式、編排工具和主機OS，我們有很多選擇，每一個都有不同的使用水準(zhǔn)、范圍、吸引力和社區(qū)的支持。

環(huán)顧我們的行業(yè)，在事物變得又老又無聊之前，它是不會穩(wěn)定。舉個例子，在我們有REST之前，有多少協(xié)議不得不消亡。我們踩在SOAP和CORBA的尸體之上通過經(jīng)驗和教訓(xùn)建立了REST 、AJAX和JSON。這是過去十年最主要的兩個技術(shù)轉(zhuǎn)折點。然而我們基于API的REST工具還沒有達到十年前我們?yōu)镾OAP所做的水平，特別是SOAP尚未完全死亡。

我們都知道Docker還沒有成熟，在嘗試它的時候仍有許多邊界情況和缺陷。問題的浮沉之間，我們一次又一次思考解決的辦法，不斷嘗試不斷失敗，直到探索出最佳實踐的方法。可能幾年以后我們再回顧這段經(jīng)歷，會發(fā)現(xiàn)很多決策上的錯誤或者失敗，但是這就是探索的意義，進步的代價。

或許會花費很多年的時間，了解了它全部的特性，Docker才會真正穩(wěn)定下來。但是這并不意味著容器是無稽之談。我們總是面對著選擇，是選擇我們已經(jīng)深刻了解的技術(shù)還是嘗試一些新的事物？答案很清楚，只有不斷地學(xué)習(xí)和適應(yīng)技術(shù)的迭代，才能帶來我們行業(yè)的進步和提升。

如果你在尋找我，那么向前看，我就在未來。

（文章轉(zhuǎn)自：CircleCI blog）