摘要：曾為美國(guó)谷歌集群管理組核心成員，主要參與開(kāi)發(fā)集群管理系統(tǒng)。保證系統(tǒng)升級(jí)軟硬件錯(cuò)誤等均能及時(shí)被發(fā)現(xiàn)并處理，谷歌集群能小時(shí)不間斷工作。關(guān)于集群管理經(jīng)驗(yàn)，首先一定要專(zhuān)注于持久的運(yùn)維自動(dòng)化工具開(kāi)發(fā)。

本文僅用于學(xué)習(xí)和交流目的，不得用于商業(yè)目的。非商業(yè)轉(zhuǎn)載請(qǐng)注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/art...

鄧德源， 才云科技CTO。2011年畢業(yè)于電子科技大學(xué)機(jī)械與自動(dòng)化專(zhuān)業(yè)，2013年獲美國(guó)頂級(jí)計(jì)算機(jī)學(xué)府Carnegie Mellon University大學(xué)電子與計(jì)算機(jī)工程學(xué)位，專(zhuān)修操作系統(tǒng)、分布式計(jì)算等方向。參與亞太機(jī)器人大賽，代表電子科大獲全國(guó)第一名，后代表中國(guó)隊(duì)在埃及獲金牌。

曾為美國(guó)谷歌集群管理組核心成員，主要參與開(kāi)發(fā)集群管理系統(tǒng)。負(fù)責(zé)管理運(yùn)維工程師提交的生產(chǎn)環(huán)境變更請(qǐng)求，自動(dòng)化風(fēng)險(xiǎn)分析，自動(dòng)化生產(chǎn)環(huán)境準(zhǔn)備工作，以及各種集群容錯(cuò)處理。保證系統(tǒng)升級(jí)、軟硬件錯(cuò)誤等均能及時(shí)被發(fā)現(xiàn)并處理，谷歌集群能24/7小時(shí)不間斷工作。作為核心成員參加了開(kāi)發(fā)基于容器集群的谷歌開(kāi)源項(xiàng)目（Kubernetes），一度成為全球前十的貢獻(xiàn)者和貢獻(xiàn)最高的華人。

鄧?yán)蠋熌壳霸诓旁瓶萍贾饕?fù)責(zé)什么工作？

我目前在才云科技主要負(fù)責(zé)公司內(nèi)部的團(tuán)隊(duì)管理，技術(shù)管理以及部分對(duì)外工作。

團(tuán)隊(duì)管理方面主要包括搭建技術(shù)團(tuán)隊(duì)、組織架構(gòu)、制度規(guī)范的建立、技術(shù)文化等，技術(shù)管理方面主要是組建中層團(tuán)隊(duì)、制定技術(shù)路線、建立培訓(xùn)機(jī)制。對(duì)外方面，更多的是了解企業(yè)市場(chǎng)、了解客戶需求、反思產(chǎn)品。最終，希望我們的產(chǎn)品能為客戶提供更多的價(jià)值。

卡耐基梅隆學(xué)習(xí)和Google工作的經(jīng)歷跟國(guó)內(nèi)學(xué)習(xí)和工作相比，最大的差別有哪些？

卡耐基梅隆大學(xué)更加側(cè)重原理和實(shí)踐的結(jié)合，其中實(shí)踐性?xún)?nèi)容的質(zhì)量非常高，比如基礎(chǔ)類(lèi)的操作系統(tǒng)、編譯原理等課程。設(shè)置的每一門(mén)課程都會(huì)把原理解析得非常透徹，學(xué)生需要根據(jù)原理親自編寫(xiě)屬于自己的操作系統(tǒng)或者編譯器。一些較為前沿的類(lèi)別，比如云計(jì)算、人工智能，教學(xué)內(nèi)容大多都與業(yè)界接軌，并且學(xué)生有更多的自主性，可以根據(jù)某次課程的某個(gè)論點(diǎn)進(jìn)行學(xué)術(shù)研究、參與相關(guān)開(kāi)源項(xiàng)目的研發(fā)等。無(wú)論學(xué)生準(zhǔn)備走學(xué)術(shù)界還是工業(yè)界，學(xué)校都可以提供非常多的資源。因此，卡耐基梅隆大學(xué)培養(yǎng)的學(xué)生大多數(shù)都能很快地融入到之后的科研或者工作當(dāng)中。

大家可能認(rèn)為卡耐基梅隆大學(xué)的學(xué)習(xí)壓力非常大，但是根據(jù)我個(gè)人的體會(huì)來(lái)看，并非如此。學(xué)校的整體氛圍實(shí)際上是比較寬松的，更重要的還是靠學(xué)生的自主意識(shí)。

至于工作方面，因?yàn)槭侵苯訌膰?guó)外回國(guó)創(chuàng)業(yè)的，我不敢妄加評(píng)論國(guó)內(nèi)的工作環(huán)境。

可以分享下在Google工作時(shí)，Google內(nèi)部容器管理的經(jīng)驗(yàn)和教訓(xùn)嗎？

Google內(nèi)部容器管理平臺(tái)已經(jīng)非常成熟，但也是一個(gè)持續(xù)演進(jìn)的過(guò)程，其最早來(lái)源于Google Search的業(yè)務(wù)運(yùn)維平臺(tái)。由三四個(gè)人將搜索引擎中的錯(cuò)誤處理等邏輯拿出來(lái)作為Borg的最初原型，使其他系統(tǒng)也能享受集群服務(wù)。由于類(lèi)似的歷史原因，Google的容器管理平臺(tái)和內(nèi)部的業(yè)務(wù)結(jié)合非常緊密。

關(guān)于集群管理經(jīng)驗(yàn)，首先一定要專(zhuān)注于持久的運(yùn)維自動(dòng)化工具開(kāi)發(fā)。提到Google的容器管理平臺(tái)，自然會(huì)想到Borg。Borg的主要功能是容器的調(diào)度和編排，以及容器的生命周期管理。用戶不用考慮程序運(yùn)行在哪里，只需要根據(jù)描述文件通知系統(tǒng)運(yùn)行程序即可。Borg自己會(huì)考慮如何分配任務(wù)，任務(wù)錯(cuò)誤重啟等眾多功能。Borg與外部的系統(tǒng)結(jié)合緊密，例如存儲(chǔ)系統(tǒng)、安全系統(tǒng)，開(kāi)發(fā)者可以認(rèn)為程序運(yùn)行的所有環(huán)境都已經(jīng)被準(zhǔn)備好，只需要關(guān)心業(yè)務(wù)邏輯就好。盡管有如此多的功能，Borg依然只是平臺(tái)的一部分，Google再此之上做了非常多的工具，如機(jī)器生命周期管理系統(tǒng)“亞里士多德”，會(huì)持續(xù)監(jiān)測(cè)物理機(jī)信息并與Borg交互；集群生命周期管理系統(tǒng)“PCMS”，負(fù)責(zé)接收集群變更事件（如機(jī)器批量下線），與Borg交互確保業(yè)務(wù)穩(wěn)定運(yùn)行。

其次，監(jiān)控是整個(gè)平臺(tái)穩(wěn)定運(yùn)行的核心。Borg出現(xiàn)不久，也就是2003年，其監(jiān)控系統(tǒng)Borgmon就已經(jīng)開(kāi)始重點(diǎn)開(kāi)發(fā)。Borgmon是基于黑盒的拉模型系統(tǒng)，側(cè)重效率，但也意味著它需要業(yè)務(wù)應(yīng)用的配合。監(jiān)控需要著重于延遲、流量、錯(cuò)誤率等指標(biāo)，針對(duì)不同的業(yè)務(wù)設(shè)計(jì)不同的粒度。例如，對(duì)于提供年SLA 99.9%的業(yè)務(wù)，需要將監(jiān)控粒度放得更大。報(bào)警層面，Google更加看重“有效報(bào)警”，因此開(kāi)發(fā)了Alertmanager來(lái)幫助用戶管理所有的報(bào)警?？偠灾?，Google的容器管理將監(jiān)控提升到了“一等公民”的地位。

另外，優(yōu)先級(jí)和資源分配是容器管理的一個(gè)重點(diǎn)。幾乎所有用戶都不太明白如何去分配優(yōu)先權(quán)（我的應(yīng)用需要什么樣的優(yōu)先級(jí)），以及請(qǐng)求多少資源（我的應(yīng)用需要多少 CPU、內(nèi)存）。在優(yōu)先級(jí)問(wèn)題上，Google有一套優(yōu)先級(jí)配額相關(guān)的管理，確保高優(yōu)先級(jí)沒(méi)有被濫用；資源問(wèn)題上，有類(lèi)似Resource Weather的系統(tǒng)提供整體的資源分布和使用情況，也有類(lèi)似Flex、autopilot的系統(tǒng)幫助用戶決定、調(diào)整資源使用。優(yōu)先級(jí)和資源分配的合理管理，極大提高了系統(tǒng)資源利用率。有人曾經(jīng)在Borg上做過(guò)實(shí)驗(yàn)，利用Borg調(diào)度 1 萬(wàn)個(gè)Hello world任務(wù)，總共用時(shí)大概2分半。但是，由于分配的優(yōu)先級(jí)很低，大多數(shù)時(shí)候并沒(méi)有10000個(gè)任務(wù)在運(yùn)行，而是被其他應(yīng)用搶占（最高優(yōu)先級(jí)200，最低優(yōu)先級(jí)0）。

最后，健壯性測(cè)試非常有必要。健壯性測(cè)試包括容器管理平臺(tái)和運(yùn)行在平臺(tái)之上的應(yīng)用。物理設(shè)備會(huì)出錯(cuò)，例如物理硬盤(pán)；設(shè)備也會(huì)有定期維護(hù)，例如Borg使用的機(jī)器平均大約每個(gè)月重啟一次。一個(gè)中等規(guī)模的Borg集群大約有 1w 臺(tái)機(jī)器，因此可以想象，集群的“動(dòng)蕩“是比較頻繁的。但是即便在SLA中明確告訴了用戶可能出現(xiàn)的問(wèn)題，用戶也會(huì)依賴(lài)于平臺(tái)。因此，Google會(huì)進(jìn)行DiRT(disaster recovery test)，在集群中注入較大規(guī)模的錯(cuò)誤，幫助用戶提高應(yīng)用的健壯性。

Google運(yùn)行應(yīng)用程序和服務(wù)的方式是怎樣的？

Google的代碼都存放在同一個(gè)龐大的代碼庫(kù)中，開(kāi)發(fā)完代碼后，開(kāi)發(fā)者需要發(fā)一個(gè)Change List，進(jìn)行code review。這類(lèi)似于Github里的Pull Request。在Google，code review必須嚴(yán)格執(zhí)行，否則代碼將無(wú)法提交（除了特殊情況）。

大致的流程如下。

1）開(kāi)發(fā)者寫(xiě)好代碼后，先在本地進(jìn)行編譯。由于Google的代碼庫(kù)非常龐大，編譯代碼所需的依賴(lài)可能就需要很長(zhǎng)時(shí)間。Google內(nèi)部使用一個(gè)叫作Blaze的編譯和測(cè)試工具，Blaze可以運(yùn)行在Borg容器集群上，通過(guò)優(yōu)化的依賴(lài)分析，高級(jí)的緩存機(jī)制和并行的構(gòu)建方法，快速地對(duì)代碼進(jìn)行構(gòu)建。而Google也將這一工具進(jìn)行了開(kāi)源：http://www.bazel.io/

2）構(gòu)建完成后，我們需要在本地進(jìn)行單元測(cè)試，而單元測(cè)試的運(yùn)行測(cè)試由叫作Forge的內(nèi)部系統(tǒng)完成，而 Forge也是通過(guò)運(yùn)行在Borg容器集群上實(shí)現(xiàn)快速并行測(cè)試的。

3）當(dāng)本地的代碼更新以Change List的形式發(fā)送出來(lái)以后，Google內(nèi)部的人員通過(guò)Critique的UI進(jìn)行代碼審查，同時(shí)Change List會(huì)觸發(fā)一個(gè)叫作TAP（tap anything protocol）的系統(tǒng)對(duì)該Change List進(jìn)行單元測(cè)試，并保證這個(gè)局部的代碼變化不會(huì)影響Google其他的應(yīng)用和代碼。TAP具有智能的依賴(lài)監(jiān)測(cè)功能，會(huì)在Google內(nèi)部浩瀚的代碼庫(kù)和產(chǎn)品線中檢測(cè)到哪些部分可能會(huì)被影響到。

4）當(dāng)代碼通過(guò)測(cè)試和審核提交后，我們會(huì)等到下一個(gè)Release cycle進(jìn)行發(fā)布。如前所述，Google內(nèi)部的應(yīng)用都是以容器的形式運(yùn)行在Borg上，因此發(fā)布的第一步工作就是通過(guò)一個(gè)叫作Rapid的系統(tǒng)，對(duì)代碼進(jìn)行容器打包成鏡像（內(nèi)部稱(chēng)為MPM格式，通過(guò)一個(gè)叫Midas的系統(tǒng)管理），再通過(guò)Rapid發(fā)布工具進(jìn)行發(fā)布。

5）在新版本的發(fā)布過(guò)程中，我們深度采用了不同形式的灰度測(cè)試機(jī)制。如果是平臺(tái)軟件更新（如容器集群平臺(tái)，服務(wù)器基礎(chǔ)鏡像升級(jí)），按照一定的速度逐漸更新到不同的數(shù)據(jù)中心，如第一天發(fā)布到一個(gè)數(shù)據(jù)中心，第二天發(fā)布到五個(gè)數(shù)據(jù)中心，以此類(lèi)推，并在過(guò)程中不斷進(jìn)行A/B測(cè)試和對(duì)比。如果是面向用戶的產(chǎn)品（如廣告、購(gòu)物等），則會(huì)采用基于用戶流量分流的灰度發(fā)布法，先選擇5%的用戶流量使用新的版本，并自動(dòng)收集metrics來(lái)進(jìn)行新舊版本的比對(duì)。

6）當(dāng)應(yīng)用成功運(yùn)行后，應(yīng)用可以通過(guò)BNS訪問(wèn)其他服務(wù)。BNS類(lèi)似于DNS，不同之處在于，BNS將IP和端口信息都封裝在了BNS路徑中。除了用戶自身應(yīng)用，Google的技術(shù)設(shè)施服務(wù)也可以通過(guò)BNS來(lái)訪問(wèn)，例如 Chubby, Colossus。

Kubernetes會(huì)商業(yè)化么？如何從Docker那里，搶到足夠的用戶群？

目前來(lái)看，Kubernetes一定是會(huì)商業(yè)化的。不過(guò)，個(gè)人認(rèn)為Kubernetes的大規(guī)模使用還有兩個(gè)前提：一是相關(guān)生態(tài)更加成熟，二是尋找更多企業(yè)場(chǎng)景。不同于Borg，Kubernetes需要滿足的場(chǎng)景更多；相反，Borg是專(zhuān)門(mén)為Google定制的，無(wú)需考慮復(fù)雜的場(chǎng)景，也無(wú)需構(gòu)建開(kāi)放的生態(tài)。因此，Kubernetes現(xiàn)在極力做到插件化、模塊化，以賦予企業(yè)更多定制化的能力，而Kubernetes本身僅提供核心功能。作為一款明星開(kāi)源軟件，Kubernetes的重點(diǎn)一定是社區(qū)和生態(tài)的建設(shè)，一旦成功，商業(yè)化也是順其自然的事情，我們還需要給予它一定的耐心。

Docker項(xiàng)目一直在進(jìn)行重構(gòu)，拆分組件進(jìn)行模塊化，目標(biāo)是標(biāo)準(zhǔn)化容器運(yùn)行時(shí)等技術(shù)，構(gòu)建可插拔的組件。在這一點(diǎn)上，其目標(biāo)與Kubernetes是相同的，即構(gòu)建完善的容器生態(tài)圈，并不存在沖突。但兩者所關(guān)注的層面并不完全相同，前者在于容器本身，后者在于大規(guī)模容器集群的管理。但隨著Docker公司的贏利壓力，Docker公司開(kāi)始逐漸在Docker（項(xiàng)目）中加入容器編排的功能。在這方面，Docker起步較晚，使用方式更加貼近開(kāi)發(fā)者，適合于小規(guī)模環(huán)境；而Kubernetes更為完善，適合于場(chǎng)景復(fù)雜、較大規(guī)模的環(huán)境，也不存在直接的競(jìng)爭(zhēng)。如果一定要說(shuō)如何獲得更多的用戶，個(gè)人認(rèn)為Kubernetes需要降低使用和運(yùn)維的門(mén)檻，去更加貼近用戶。最后，即使兩者有趨同的情況，也不一定是敵對(duì)關(guān)系，放在他們面前的，是如何轉(zhuǎn)變企業(yè)的思維，如何權(quán)衡與虛擬化的關(guān)系等問(wèn)題。

您認(rèn)為國(guó)內(nèi)企業(yè)，尤其是傳統(tǒng)企業(yè)應(yīng)該做出哪些轉(zhuǎn)變，去擁抱國(guó)外先進(jìn)的事物？

傳統(tǒng)企業(yè)的轉(zhuǎn)變，最重要的還是觀念上的改變。可喜的是，我們現(xiàn)在接觸到了很多的傳統(tǒng)企業(yè)，他們對(duì)新技術(shù)都是開(kāi)放的態(tài)度。但轉(zhuǎn)變不是一朝一夕的事情，企業(yè)要學(xué)會(huì)從邊緣到核心的方法，從小做起，慢慢滲透到企業(yè)內(nèi)部。另外，行業(yè)的推動(dòng)也是極其重要的，只靠一家的力量是很難完成轉(zhuǎn)變的，企業(yè)需要聯(lián)合同行伙伴建立行業(yè)聯(lián)盟，學(xué)習(xí)行業(yè)標(biāo)桿以及其他行業(yè)的經(jīng)驗(yàn)，一起推動(dòng)轉(zhuǎn)型。最后，轉(zhuǎn)型離不開(kāi)人，離不開(kāi)新型人才，僅僅靠?jī)?nèi)部人力也很難完成轉(zhuǎn)變。傳統(tǒng)企業(yè)要積極尋找并引進(jìn)人才，很多問(wèn)題便可迎刃而解。不過(guò)，企業(yè)一定要注意可能的問(wèn)題，比如新老融合的問(wèn)題，這更需要企業(yè)決策者對(duì)轉(zhuǎn)型的決心和毅力。

——更多訪談