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

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

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

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

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

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

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

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

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

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

而進(jìn)入的那個(gè)世界的Docker——幾乎所有的工作方式都是新的。它拋棄了各種舊規(guī)則——包括操作系統(tǒng)、部署、運(yùn)維、 封裝、防火墻、PaaS等等。一些開發(fā)者立刻愛上了它，有時(shí)候是因?yàn)樗行Ы鉀Q了一些問題，有時(shí)候是因?yàn)樗情W亮的玩具——讓他們?cè)谄渌⒆油娴剿帮@得很酷。另一些開發(fā)者則討厭它，討厭它大肆的宣傳和炒作，認(rèn)為它就和其他之前新出的技術(shù)一樣，并沒有什么不同，卻被人人談?wù)撝?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們都知道Docker還沒有成熟，在嘗試它的時(shí)候仍有許多邊界情況和缺陷。問題的浮沉之間，我們一次又一次思考解決的辦法，不斷嘗試不斷失敗，直到探索出最佳實(shí)踐的方法?？赡軒啄暌院笪覀?cè)倩仡欉@段經(jīng)歷，會(huì)發(fā)現(xiàn)很多決策上的錯(cuò)誤或者失敗，但是這就是探索的意義，進(jìn)步的代價(jià)。

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

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

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