Eric Brewer:容器和微服務是計算的未來

Mesosphere的高級研究分析師Derrik Harris(原是GigaOM編輯,到訪過CSDN)最近採訪了Google負責基礎設施的副總裁Eric Brew,談到了容器技術、Kubernetes、雲計算當然還有CAP。

http://img.my.csdn.net/uploads/201505/18/1431922844_4841.png

Eric Brew,美國工程院院士和ACM Fellow,是著名的分佈式系統專家,32歲就拿到加州大學伯克利分校教授個人網頁),提出了分佈系統中非常重要的CAP定理。他也是搜索技術先驅Inktomi(李彥宏曾經在這裏任職)的聯合創始人和首席科學家。他在伯克利培養了David Wagner(伯克利教授)、Armando Fox(伯克利教授,Intel )、Matt Welsh(曾在哈佛大學後來轉到Google)和周楓(網易高級副總裁、有道的負責人)等人才。

下面是採訪的要點:

在採訪中,Brewer提到他現在主要的工作重點之一就是Kubernetes和容器,會推動Google往這個方向做更多事情。Google以及Inktomi歷史上之所以都沒有采用虛擬機管理集羣,原因是那時候還沒有或者不知道現代虛擬機技術,只能在裸硬件上用Unix的進程模型,用進程來做所有事情,在一個硬件上運行多個進程。Google主要系統自始至終都沒用虛擬機,只有後來爲了運行第三方的一些企業應用,纔有一點。

此後,基於虛擬機的IaaS革命來了,各種開源工具和管理環境都是圍繞虛擬機的管理和運行開發的。

容器和Kubernetes有一點返璞歸真的意思,但抽象層次更高。Google開發Linux容器就是爲了使運行在同一機器上的不同作業能夠實現性能隔離,容器是Google內部非常基礎的技術。

https://d262ilb51hltx0.cloudfront.net/max/888/1*I2UYglRZ80-tYA-8763GtA.jpeg

Kubernetes的架構圖

Brewer承認,Kubernetes開源後的火爆超出預期,GitHub上每天多達40個提交和評論讓他們忙不過來。

Kubernetes並沒有使用Google內部系統Borg和Omega的代碼,但開發者是同一撥人。Kubernetes尤其是pod和標籤相關的一些元素,都是吸取了Borg和Omega系統的經驗教訓,因此要好很多。最終Kubernetes一些方面與Borg會非常相似,比如使用IP地址的方式,但有些方面比如標籤,Kubernetes會比內部系統好得多。要知道,那些經驗教訓可是來之不易的啊。

Brewer強調,對於開發者而言,將系統部署在Kubernetes這樣的容器化系統上,有很多好處。Kubernetes的作用其實是提供應用的長期視角。

容器最初的價值是開發環境(包括程序員的筆記本)與雲端部署環境一致。Docker這方面非常出色,但之後呢?Kubernetes回答了這個問題:你可以運行一組容器,以可控的方式升級、導入流量,可以按容器數量擴展服務,因此負載增加時就能方便地增加容量。這些運維方面的方便是Kubernetes的重要價值。

過去幾十年分佈式系統的發展,Brewer認爲核心是雲計算興起使開發者能夠把精力花在應用本身上,不用再操心操作系統啊、安全補丁啊、服務器用多大啊、容量規劃啊之類的資源運維問題,應用就是一組服務而已。比如SnapChat完全基於GAE,他們一個運維人員都沒有。

當然,GAE和其他PaaS平臺也有侷限,就是不夠通用,只能適合某些場景。比如GAE適合網站,Heroku適合與Salesforce集成相關的事情,Engine Yard適合RoR技術棧。

GAE正在試圖通過託管虛擬機來逐漸變得更加通用,但是Brewer自己認爲很可能能使GAE真正能通用化的是容器。“問題在於,我們是否能將GAE的優點帶到容器世界。……這並非易事,但方向是這樣的。”

對於自己的學術代表作CAP,Brewer說,很多NoSQL項目都用CAP定理來爲自己所作的設計決策證言,但其中有些並不正確。但他認爲過去十年廣泛地探索不同數據管理系統,是非常有益的,從中獲得了許多寶貴經驗。架構師工作就是在不同場景下對互相矛盾的考慮因素進行細緻而困難的微調。(另外可以參考他在IEEE Software的CAP十二年回顧文章。)

他還提到,事實上金融系統也不是基於一致性的,他們依賴的是審計和賠償。他們甚至不知道什麼CAP定理,只是按照需求做出設計決策而已。當然,他們所作的是正確的決策。比如ATM機在斷網的情況下,用戶還能取一次小額的現金,從而保證可用性,但不允許再次取款。

展望未來十年,Eric Brewer認爲,軟件開發的方式將有很大變化。應用將由許多微服務組成的,開發軟件就是開發微服務而不再是庫。今天,拿到一個開源項目,需要做很多事情,才能與已有系統和其他系統集成。如果能夠抽象出機器細節,更關注API和代碼,那麼一個應用裏的十個服務理論上可以用十種不同的語言。這種更以服務爲中心的軟件將越來越普遍,這一變革的意義與從大型機到客戶端/服務器到雲,可能是等量齊觀的。

容器和微服務,能使整個企業更加敏捷,從而爲其用戶提供更多有意思的產品,它們是計算的未來。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章