Eric Brewer：容器是計算的未來

作者：黃帥翻譯 2015-05-21 13:11:06

云計算 本文是一篇對Eric Brewer的采訪稿，探討了他本人對容器和Kubernetes過往的看法以及未來的展望。Brewer提到他現(xiàn)在主要的工作重點之一就是 Kubernetes和容器。展望未來十年，Eric Brewer認(rèn)為，軟件開發(fā)的方式將有很大變化。微服務(wù)和容器將會引領(lǐng)未來。

創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、集寧網(wǎng)絡(luò)推廣、小程序開發(fā)、集寧網(wǎng)絡(luò)營銷、集寧企業(yè)策劃、集寧品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供集寧建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com

本文是一篇對Eric Brewer的采訪稿，探討了他本人對容器和Kubernetes過往的看法以及未來的展望。Brewer提到他現(xiàn)在主要的工作重點之一就是 Kubernetes和容器。展望未來十年，Eric Brewer認(rèn)為，軟件開發(fā)的方式將有很大變化。微服務(wù)和容器將會***未來。

以下為作者原文。

Eric Brewer，加州大學(xué)伯克利分校教授，曾提出CAP理論(分布式系統(tǒng)的重要設(shè)計理念)，也是網(wǎng)絡(luò)搜索先驅(qū)Inktomi公司的聯(lián)合創(chuàng)始人。本次采訪中，他作為Google基礎(chǔ)設(shè)施的副總裁，解釋了為何他認(rèn)為自己在容器上正進(jìn)行的工作，其重要性不亞于云計算，并討論了CAP理論自出現(xiàn)以來將近二十年是如何經(jīng)受住了檢驗。

Google目前正在推動一個叫Kubernetes的開源項目，它簡化了在Docker容器集群之上構(gòu)建應(yīng)用的流程。

為什么是容器?為什么是現(xiàn)在?

您在Google的角色是什么?一直以來有一些猜測，但沒有真正公開過。

Eric Brewer：我的工作和Kubernetes、容器相關(guān)。這個項目是我非常關(guān)心的，我也很確信它可以推動Google在這個方向做更多的事情。這讓我感到很興奮。

在Google之前，你和容器有什么交集嗎?

早先我一直從事集群相關(guān)的工作，所以后來就有了Inktomi公司，這要早于虛擬機(jī)，至少早于虛擬機(jī)的重新回歸[編者注:[1]]。Google也是類似的情況，始于1998年，幾乎和現(xiàn)代版的虛擬機(jī)在同一個時期誕生，而那時候還沒有用虛擬機(jī)構(gòu)建服務(wù)的概念。

早先大家都是在硬件上直接搭建服務(wù)。Inktomi公司，也包括早期的Google，實質(zhì)上使用的是Unix進(jìn)程模型，用進(jìn)程來完成各種任務(wù)，在相同的硬件上跑多個進(jìn)程。事實上，Google開始也并沒有使用虛擬機(jī)，直到它開始做一些企業(yè)的東西，因為要跑第三方的應(yīng)用。但是，對于Google所有內(nèi)部的應(yīng)用，從來也沒有使用過虛擬機(jī)。

坦率地說，參與提交代碼和評價(Kubernetes)的人實在太多。

與此同時，整個IaaS技術(shù)革新發(fā)生了，它們都是建立在虛擬機(jī)的基礎(chǔ)上。因此，從這個意義上來說，開源世界不得不使用虛擬機(jī)作為其技術(shù)基礎(chǔ)來構(gòu)建應(yīng)用，并且很多的工具以及管理都是圍繞你怎么操作和控制虛擬機(jī)。

從某種意義上來說，現(xiàn)在有關(guān)容器以及Kubernetes的工作，其實就是早先用進(jìn)程來完成任務(wù)的一種回歸，不過是在更高的層次上進(jìn)行了抽象。而且事實上，在Google內(nèi)部，人們使用Linux容器，通過在同一臺機(jī)器上運行不同的任務(wù)，來嘗試實現(xiàn)性能隔離。這就是為何容器對Google的運維而言如此重要的一個原因。

不過說真的，如果你仔細(xì)分析的話，真正的原因其實是Inktomi和Google公司的誕生早于虛擬機(jī)的廣泛使用，而并不是因為容器當(dāng)時已存于工具箱中。

這聽起來像是重溫21世紀(jì)初我們圍繞“效用計算”進(jìn)行的討論，其目的是不再以服務(wù)器作為計算的度量單位。

這當(dāng)然是我的想法，起于1997年。我曾談到了一般性的話題，且我仍然堅信這一點。在某種意義上來說，我們只是剛巧出現(xiàn)在那里。

所以，你有沒有對Kubernetes如此之受歡迎感到驚訝?

我承認(rèn)我感到過驚訝。我曾想過它將會成功，我們也著手準(zhǔn)備使之變得成功，但同時，坦率地說，參與提交代碼和評論的人太多，我們忙不過來。

這也是很令人振奮的，我們不可能處理所有的pull request。我想，根據(jù)GitHub的日志，現(xiàn)在每天約有40個commits，需求則遠(yuǎn)遠(yuǎn)高于此。每一個都要進(jìn)行校閱，質(zhì)量參差不齊。有些很容易，有些則非常困難。

這是個成功帶來的難題，我們是很開心的。因此增加了團(tuán)隊成員來嘗試改善處理的速度，而且也要求提高我們自己的能力，來和開源社區(qū)希望貢獻(xiàn)代碼或者已經(jīng)貢獻(xiàn)很多的人進(jìn)行更好的溝通與合作。我非常興奮，因為這些都已經(jīng)有了，這一切太快，以至于很難能了解每天所有這些已發(fā)生的變化。

Kubernetes和Borg及Omega(Google內(nèi)部的兩個資源編排系統(tǒng))有什么關(guān)聯(lián)嗎?

我要說，沒有共享的代碼，不過有共享的成員。

你可以看Kubernetes，特別是像pods和labels等，吸取了Borg和Omega系統(tǒng)的經(jīng)驗教訓(xùn)，坦率地說，這使得現(xiàn)在的 Kubernetes變得更好。最終Kubernetes一些方面與Borg會非常相似，比如使用IP地址的方式，但有些方面比如 labels，Kubernetes會比內(nèi)部系統(tǒng)好得多。

我得說，那些經(jīng)驗教訓(xùn)可是來之不易的啊。

我的主要目標(biāo)是......讓開發(fā)者看待自己的應(yīng)用像一組服務(wù)的集合，而不用直接地考慮有關(guān)資源的問題。

這是關(guān)于開發(fā)者和數(shù)據(jù)中心

#p#

從開發(fā)者的角度來看，在這些系統(tǒng)上部署應(yīng)用的優(yōu)勢在哪里?

有很多的好處。Kubernetes扮演的角色就是使你對自己的應(yīng)用有一個長遠(yuǎn)的視角。

容器的最初價值，真的只是你可以在筆記本上運行你的應(yīng)用，然后也可以在云端部署這個應(yīng)用。這是一件非常好的事，Docker干得很出色!可是之后，你還能做什么呢? Kubernetes回答了這個問題，你可以運行一組容器，按照你想要控制的方式去升級、導(dǎo)入流量，你可以通過容器的數(shù)量來改變服務(wù)的規(guī)模，也就是說當(dāng)你的負(fù)載提高，你可以很容易地增加容量。

這些運維方面的方便，我覺得，才是Kubernetes帶來的重要價值。

我很好奇你是如何看待過去幾十年分布式系統(tǒng)的發(fā)展?比如非常流行的技術(shù)如Hadoop和NoSQL的出現(xiàn)，而且我們也開始回來思考共享資源的管理。

我認(rèn)為以虛擬機(jī)作為基本資源，工作受到了某種限制。這不是一個可怕的限制，特別是對小型服務(wù)(如果它太小，這也是限制)，但對于大多數(shù)服務(wù)而言，這不是一個可怕的限制。 但它確實干擾了資源利用的效率，以及在某種程度上有關(guān)容量的規(guī)劃。

我認(rèn)為更大的問題是，作為一個開發(fā)者，你真的不用去想這些細(xì)節(jié)：操作系統(tǒng)啊，安全補(bǔ)丁啊，服務(wù)器的數(shù)量等等。 這些東西，真的，我們能夠為你處理。你只要花更多的時間專注于應(yīng)用本身。

我想說，我們正在這場革新之中。

這聽起來你看待這場革新是有關(guān)開發(fā)的，而不是作為基礎(chǔ)設(shè)施的。

他們可以齊頭并進(jìn)，但我的主要目標(biāo)，其實是，首先，讓開發(fā)者看待自己的應(yīng)用像一組服務(wù)的集合，而不用直接地考慮有關(guān)資源的問題。他們當(dāng)然不用直接處理有關(guān)操作系統(tǒng)安裝和升級補(bǔ)丁之類的問題。

我感覺它最終會成為一個巨大的變革，至少和云計算一樣。

云計算使開發(fā)者期待更好的經(jīng)驗和工具，是因為這個時間點正好呢?還是因為以云服務(wù)為基礎(chǔ)的小規(guī)模初創(chuàng)公司，像Pinterest和Airbnb，現(xiàn)在都碰到了多年前像Google這樣的公司遇到的服務(wù)擴(kuò)充問題?

我想有些事情已經(jīng)發(fā)生了。就像你看待SnapChat，他們實際上是運行在Google App Engine上面，對于他們而言，這些問題已經(jīng)都被解決了。在App Engine中，你不必?fù)?dān)心有關(guān)操作系統(tǒng)補(bǔ)丁和機(jī)器的邊界。而且，事實上，SnapChat說，它實際上并沒有任何運維人員，都是靠Google來解決。

這就是那種我希望所有開發(fā)者可以得到的體驗，只是，App Engine不夠靈活做所有人想做的事情。然而，容器模型基本上是帶給你和虛擬機(jī)一樣的靈活性，而且多了很多類似App Engine的可用性。還有很多，我們可以用這個方法進(jìn)行自動化，這些對于開發(fā)者而言，這非常重大。

是不是由于靈活性受到限制，使得App Engine以及早期的一些PaaS服務(wù)，沒有像人們期望的方式獲得成功?

我認(rèn)為他們適合在特定的市場中成功。App Engine適合網(wǎng)站，Heroku適合Salesforce集成相關(guān)的業(yè)務(wù)，如果你想要使用Ruby on Rails，Engine Yard是相當(dāng)不錯的，但他們沒有一個是通用的。

我們試圖利用托管虛擬機(jī)來使App Engine變得更通用。但實際上我覺得能夠給App Engine帶來通用性的，其實是容器?，F(xiàn)在，問題是，我們是否可以將App Engine的所有優(yōu)點放入容器的世界。隨著時間的推移，我認(rèn)為我們能做到。 這不是小事，但，總的來說，還是要往那里去的。

從客戶的角度，大規(guī)模采用容器，可以讓更多的服務(wù)如Google和Facebook，能夠處理巨大的用戶量而不宕機(jī)，這是不是最終的結(jié)果?

我認(rèn)為最終的結(jié)果是對于行業(yè)而言意味著更高的運轉(zhuǎn)速度，對于消費者意味著每天有更多的選擇，更多的服務(wù)，更有趣的東西。

很多NoSQL的項目采用CAP理論來為自己所作的設(shè)計決策證言，但其中有些正確，有些并不正確。

20年后的CAP理論

除了你在Kubernetes上的工作，實際上可能，最出名的是你提出了CAP理論。能簡單解釋一下嗎?

CAP理論描述了你想要得到三種屬性，可是你只能獲得其中兩種，這是一個令人驚訝的和消極的結(jié)果。人們想得到的三個屬性，***個，系統(tǒng)一致性，意味著系統(tǒng)中所有服務(wù)器能達(dá)成數(shù)據(jù)值的一致性，比如你有一個銀行賬戶，每個服務(wù)器都應(yīng)該接受銀行賬戶的數(shù)值是多少，也就是說，銀行賬戶的數(shù)值應(yīng)該在所有服務(wù)器上是一樣的。

第二個是可用性。系統(tǒng)應(yīng)當(dāng)在線運行，并可以與用戶形成交互。

第三個是為了容錯而進(jìn)行的數(shù)據(jù)分區(qū)，當(dāng)你將數(shù)據(jù)分區(qū)到幾個服務(wù)器上時，你可能覺得數(shù)據(jù)有兩份或多份副本，很可靠了，但是服務(wù)器之間的網(wǎng)絡(luò)連接會斷線，那么這時你就不能既要一致性，又要可用性，只能在這兩者之間選擇一個。

這是我在2000年討論的，究竟是什么意思，大概，是數(shù)據(jù)庫選擇一致性，因為他們看重銀行帳戶的約定，互聯(lián)網(wǎng)服務(wù)則是選擇可用性，包括Inktomi。所以我們做出選擇，為了讓系統(tǒng)持續(xù)運行，犧牲了一致性。

這困擾我好一段時間，直到我最終意識到，這是一個權(quán)衡，而且任何人在分布式系統(tǒng)中都希望獲得高可用性，不得不對在一致性上進(jìn)行妥協(xié)。

那是你在2000年的想法，現(xiàn)在有所變化嗎?

現(xiàn)在大家都在位置之上，改變就發(fā)生了。整個NoSQL運動，從某種程度上來說，是在探索可用性。很多NoSQL的項目采用CAP理論來為自己所作的設(shè)計決策證言，但其中有些正確，有些并不正確。

但是我確實認(rèn)為在過去十年，各種各樣不同數(shù)據(jù)管理系統(tǒng)的出現(xiàn)，它們所進(jìn)行的各種探索是非常有益的。任何這些數(shù)據(jù)管理系統(tǒng) 如Bigtable，Cassandra還是Dynamo等等，探索如何管理數(shù)據(jù)，這是非常好的。在這個過程中，受益匪淺。

所以目前我們都接受了這個理論，現(xiàn)在需要做的是進(jìn)一步精細(xì)化調(diào)配屬性之間的關(guān)系，來滿足不同的應(yīng)用場景。我認(rèn)為這也是非常有幫助的。

聽起來像是一個通用性的進(jìn)步。舉個例子，如果你足夠用心調(diào)配，是不是三個屬性中，我可以獲得2.5個呢?

這還是三選二的權(quán)衡，只是當(dāng)你對數(shù)據(jù)進(jìn)行充分分區(qū)時，來做這個權(quán)衡，這也不是常見的。大多數(shù)時候，你可以擁有兩個屬性，你需要研判如果一個數(shù)據(jù)分區(qū)出現(xiàn)問題，你要怎么辦，你要怎么恢復(fù)。這并不容易，其實很復(fù)雜，但我想這恰恰就是架構(gòu)師應(yīng)該認(rèn)真考慮的事情[編者注:[2]]。

舉例，ATM機(jī)有時會和銀行機(jī)房失去聯(lián)絡(luò)，但問題是，在這種狀態(tài)下，如果有用戶等待ATM取款，它到底給不給錢出來呢?如果它給錢，那它是可用的，但是會導(dǎo)致數(shù)據(jù)不一致，因為ATM內(nèi)賬戶的錢少了，但由于網(wǎng)絡(luò)中斷，銀行機(jī)房數(shù)據(jù)庫對應(yīng)的賬戶錢卻沒有少，也就是說，實際上這個用戶的銀行賬戶中，錢并沒有因ATM給錢而削減掉這一筆錢。實際上，ATM也可以選擇可用性，在網(wǎng)絡(luò)中斷的狀態(tài)下，給的錢會有一個上限，比如200美金，***次可以這樣，第二次ATM就會拒絕了。

這是靠隱瞞不一致性來進(jìn)行的風(fēng)險管理，但，這是一個相當(dāng)不錯的選擇。

你允許不一致性，然后你想辦法彌補(bǔ)，或者試圖阻止。

除了某些特殊行業(yè)，如果數(shù)據(jù)并不總是一致，影響大嗎?例如，消費者網(wǎng)站，大多數(shù)人都不會注意到。

我想大部分人的方案是，他們允許不一致的問題發(fā)生，但會確?？梢栽谑潞笸ㄟ^審計來檢測到它們。例如，一個很常見的錯誤是你訂購的東西，它可能會被下兩次單，或者他們可能忘了你已經(jīng)取消訂單，最終東西意外地寄給了你。這都是很容易彌補(bǔ)的，他們可以把它收回來。

所以一般的答案是你允許不一致性，然后你想辦法彌補(bǔ)，或者試圖阻止。事實上，金融系統(tǒng)也不保證一致性，它是靠審計和賠償來解決問題。他們不了解CAP理論，只是這個決策解決了他們的需要而已。所以我覺得，這就是一個正確的決策。

#p#

當(dāng)你構(gòu)建新的應(yīng)用時，這會帶來什么影響?如果你嘗試創(chuàng)建下一代Facebook或者Twitter，由于上面討論的問題，你將不得不失去大量的休息時間?

你無須為此犧牲休息的時間，但***能了解當(dāng)你進(jìn)行數(shù)據(jù)分區(qū)時所可能帶來的后果。最常見的可能就是有些消息不可用了，或者部分不可用了。偶爾你發(fā)現(xiàn)消息被發(fā)送兩次，或者不一致的消息內(nèi)容發(fā)給了不同的人。你應(yīng)該知道后果是什么，盡管通常它們都是短暫的，或者無害的。

但是它們也可以是很嚴(yán)重的問題。很多系統(tǒng)因分區(qū)而丟失數(shù)據(jù)，是因為他們根本就沒考慮到這些問題。

我覺得你構(gòu)建應(yīng)用的方式真的將發(fā)生改變。實際上，在你的應(yīng)用中，很容易啟用10個微服務(wù)，理論上，它們甚至可以使用10個不同的編程語言。

開發(fā)者的黃金時代

如果我是開發(fā)者，做我***個初創(chuàng)公司，如果有對開發(fā)者友好的抽象和工具，我是不是能做任何東西?或者我真的需要深入了解計算機(jī)科學(xué)后才可以開發(fā)一個可行的產(chǎn)品?

我覺得人們應(yīng)該不需要大量計算機(jī)科學(xué)的知識來開發(fā)產(chǎn)品的***版。你可以選擇一些簡單的應(yīng)用，有時候它們也會出問題，但大多數(shù)情況下是好的。

但是最終，但你二次開發(fā)時，你需要擴(kuò)充服務(wù)，你不得不擔(dān)心用戶流量大增的情況，然后你得思考這些問題。因為它們確實會影響你系統(tǒng)的性能，通過影響系統(tǒng)的可用性，會使你的利潤受到影響。

我們以Kubernetes為例。當(dāng)規(guī)模成為一個問題，到底有哪些東西影響你的決策和流程?

我想說這不能解決本質(zhì)的問題，但我認(rèn)為你可以利用別人的優(yōu)點。比如在Kubernetes，我們使用etcd來管理一定的數(shù)據(jù)，保證它們的一致性，而且etcd已經(jīng)做了一些工作。如果你想在Kubernetes里面進(jìn)行分區(qū)，你可能會進(jìn)入一種奇怪的狀態(tài)，但問題也不是很大，因為 Kubernetes是運行在同一個數(shù)據(jù)中心所有的節(jié)點上。

麻煩的是你想把應(yīng)用擴(kuò)展到多個數(shù)據(jù)中心，很可能網(wǎng)絡(luò)會中斷，你不得不去進(jìn)一步考慮這些問題。但是你通常可以推遲這個問題的發(fā)生，直到后來你的應(yīng)用真的進(jìn)化成為一個企業(yè)或者產(chǎn)品。

我認(rèn)為最終的結(jié)果是對于行業(yè)而言意味著更高的運轉(zhuǎn)速度，對于消費者意味著每天有更多的選擇，更多的服務(wù)，更有趣的東西。

有沒有什么更通用的東西?這些年，Google和其他公司已經(jīng)構(gòu)建、開源了很多技術(shù)。在某一點上看，使用這些技術(shù)，你也可以避免很多問題。

Bigtable是一個很好的例子。大約10年前，Google構(gòu)建了Bigtable，是因為Google需要這樣一個系統(tǒng)，可以管理相關(guān)的數(shù)據(jù)，同時又能做到有關(guān)一致性和可用性上的一些平衡。

但是你是對的：因為大家需要它，在Bigtable的論文發(fā)布之后，圍繞它出現(xiàn)了很多開源版本，這確實幫助了整個社區(qū)。直到最近，你才可以直接使用Bigtable，真正的Bigtable，Google的Bigtable云服務(wù)。

如果回頭看過去的十年，今天發(fā)生的事情，對應(yīng)用和系統(tǒng)的構(gòu)建發(fā)揮什么樣的作用?

我想你構(gòu)建應(yīng)用的方法真的將會改變。原因如我所說，一旦你以微服務(wù)的方式去看待一個應(yīng)用，那么軟件工程師將不再構(gòu)建程序庫而且開始構(gòu)建微服務(wù)?，F(xiàn)在當(dāng)給你使用一個開源項目，實際上，你有很多事要做，先要讓它在你的系統(tǒng)中跑起來，然后再將它和你的其他技術(shù)集成在一起。

如果我們能抽象掉實際的機(jī)器環(huán)境，更多地關(guān)注API和代碼，一個很大的好處是，為了讓API工作起來，你可以對不同的服務(wù)使用不同的編程語言。所以，實際上這就變得很簡單，只要啟用10個微服務(wù)在你的應(yīng)用中，理論上，它們甚至使用10種不同的編程語言。嘗試將大量現(xiàn)存的東西粘合在一起成為一個整體，這是一個非常大的好處。

那種系統(tǒng)要是變得越來越普遍，會讓我們更容易地以服務(wù)為中心來開發(fā)相應(yīng)的軟件。

這算不算另一種從大型機(jī)，客戶端-服務(wù)器到云的過渡進(jìn)化，抑或是更大的或不同的東西?

很難知道，現(xiàn)在還非常早期。我感覺它最終會成為一個巨大的變革，至少和云計算一樣。

原文鏈接：http://dockone.io/article/384
 

分享名稱：EricBrewer：容器是計算的未來
當(dāng)前URL：http://fisionsoft.com.cn/article/dhphgoh.html