Eric Brewer：容器是云計算的未來

Eric Brew是Google負責基礎設施的副總裁，本文探討了他本人對容器和Kubernetes過往的看法以及未來的展望。Brewer提到他現在主要的工 作重點之一就是Kubernetes和容器。展望未來十年，Eric Brewer認為，軟件開發的方式將有很大變化。微服務和容器將會引領未來。

Eric Brewer，加州大學伯克利分校教授，曾提出CAP理論（分布式系統的重要設計理念），也是網絡搜索先驅Inktomi公司的聯合創始人。本次采訪中， 他作為Google基礎設施的副總裁，解釋了為何他認為自己在容器上正進行的工作，其重要性不亞于云計算，并討論了CAP理論自出現以來將近二十年是如何 經受住了檢驗。

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

為什么是容器？為什么是現在？

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

Eric Brewer：我的工作和Kubernetes、容器相關。我非常關注這個項目，并且我會推動Google朝這個方向努力。這讓我感到很興奮。

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

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

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

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

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

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

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

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

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

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

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

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

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

Kubernetes和Borg及Omega（Google內部的兩個資源編排系統）有什么關聯嗎?

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

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

我得說，那些經驗教訓可是來之不易的啊。

我的主要目標是......讓開發者看待自己的應用像一組服務的集合，而不用直接地考慮有關資源的問題。

這是關于開發者和數據中心

從開發者的角度來看，在這些系統上部署應用的優勢在哪里？

有很多的好處。Kubernetes扮演的角色就是使你對自己的應用有一個長遠的視角。

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

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

我很好奇你是如何看待過去幾十年分布式系統的發展？比如非常流行的技術如Hadoop和NoSQL的出現，而且我們也開始回來思考共享資源的管理。

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

我認為更大的問題是，作為一個開發者，你真的不用去想這些細節：操作系統啊，安全補丁啊，服務器的數量等等。 這些東西，真的，我們能夠為你處理。你只要花更多的時間專注于應用本身。

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

這聽起來你看待這場革新是有關開發的，而不是作為基礎設施的。

他們可以齊頭并進，但我的主要目標，其實是，首先，讓開發者看待自己的應用像一組服務的集合，而不用直接地考慮有關資源的問題。他們當然不用直接處理有關操作系統安裝和升級補丁之類的問題。

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

云計算使開發者期待更好的經驗和工具，是因為這個時間點正好呢？還是因為以云服務為基礎的小規模初創公司，像Pinterest和Airbnb，現在都碰到了多年前像Google這樣的公司遇到的服務擴充問題？

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

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

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

我認為他們適合在特定的市場中成功。App Engine適合網站，Heroku適合Salesforce集成相關的業務，如果你想要使用Ruby on Rails，Engine Yard是相當不錯的，但他們沒有一個是通用的。

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

從客戶的角度，大規模采用容器，可以讓更多的服務如Google和非死book，能夠處理巨大的用戶量而不宕機，這是不是最終的結果?

我認為最終的結果是對于行業而言意味著更高的運轉速度，對于消費者意味著每天有更多的選擇，更多的服務，更有趣的東西。

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

20年后的CAP理論

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

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

第二個是可用性。系統應當在線運行，并可以與用戶形成交互。

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

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

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

那是你在2000年的想法，現在有所變化嗎?

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

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

所以目前我們都接受了這個理論，現在需要做的是進一步精細化調配屬性之間的關系，來滿足不同的應用場景。我認為這也是非常有幫助的。

聽起來像是一個通用性的進步。舉個例子，如果你足夠用心調配，是不是三個屬性中，我可以獲得2.5個呢？

這還是三選二的權衡，只是當你對數據進行充分分區時，來做這個權衡，這也不是常見的。大多數時候，你可以擁有兩個屬性，你需要研判如果一個數據分 區出現問題，你要怎么辦，你要怎么恢復。這并不容易，其實很復雜，但我想這恰恰就是架構師應該認真考慮的事情[編者注:[2]]。

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

這是靠隱瞞不一致性來進行的風險管理，但，這是一個相當不錯的選擇。

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

除了某些特殊行業，如果數據并不總是一致，影響大嗎？例如，消費者網站，大多數人都不會注意到。

我想大部分人的方案是，他們允許不一致的問題發生，但會確保可以在事后通過審計來檢測到它們。例如，一個很常見的錯誤是你訂購的東西，它可能會被下兩次單，或者他們可能忘了你已經取消訂單，最終東西意外地寄給了你。這都是很容易彌補的，他們可以把它收回來。

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

當你構建新的應用時，這會帶來什么影響？如果你嘗試創建下一代非死book或者推ter，由于上面討論的問題，你將不得不失去大量的休息時間？

你無須為此犧牲休息的時間，但最好能了解當你進行數據分區時所可能帶來的后果。最常見的可能就是有些消息不可用了，或者部分不可用了。偶爾你發現消息被發送兩次，或者不一致的消息內容發給了不同的人。你應該知道后果是什么，盡管通常它們都是短暫的，或者無害的。

但是它們也可以是很嚴重的問題。很多系統因分區而丟失數據，是因為他們根本就沒考慮到這些問題。

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

開發者的黃金時代

如果我是開發者，做我第一個初創公司，如果有對開發者友好的抽象和工具，我是不是能做任何東西？或者我真的需要深入了解計算機科學后才可以開發一個可行的產品？

我覺得人們應該不需要大量計算機科學的知識來開發產品的第一版。你可以選擇一些簡單的應用，有時候它們也會出問題，但大多數情況下是好的。

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

我們以Kubernetes為例。當規模成為一個問題，到底有哪些東西影響你的決策和流程？

我想說這不能解決本質的問題，但我認為你可以利用別人的優點。比如在Kubernetes，我們使用etcd來管理一定的數據，保證它們的一致 性，而且etcd已經做了一些工作。如果你想在Kubernetes里面進行分區，你可能會進入一種奇怪的狀態，但問題也不是很大，因為 Kubernetes是運行在同一個數據中心所有的節點上。

麻煩的是你想把應用擴展到多個數據中心，很可能網絡會中斷，你不得不去進一步考慮這些問題。但是你通常可以推遲這個問題的發生，直到后來你的應用真的進化成為一個企業或者產品。

我認為最終的結果是對于行業而言意味著更高的運轉速度，對于消費者意味著每天有更多的選擇，更多的服務，更有趣的東西。

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

Bigtable是一個很好的例子。大約10年前，Google構建了Bigtable，是因為Google需要這樣一個系統，可以管理相關的數據，同時又能做到有關一致性和可用性上的一些平衡。

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

如果回頭看過去的十年，今天發生的事情，對應用和系統的構建發揮什么樣的作用？

我想你構建應用的方法真的將會改變。原因如我所說，一旦你以微服務的方式去看待一個應用，那么軟件工程師將不再構建程序庫而且開始構建微服務。現在當給你使用一個開源項目，實際上，你有很多事要做，先要讓它在你的系統中跑起來，然后再將它和你的其他技術集成在一起。

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

那種系統要是變得越來越普遍，會讓我們更容易地以服務為中心來開發相應的軟件。

這算不算另一種從大型機，客戶端-服務器到云的過渡進化，抑或是更大的或不同的東西？

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

原文鏈接：Google systems guru explains why containers are the future of computing（翻譯：黃帥 校對：李穎杰）

===================================
譯者介紹
Henry Huang，目前供職于趨勢科技 Trend Micro（南京），負責集群運維的工作。