才雲科技CTO鄧德源：不可不知的谷歌叢集管理經驗（圖靈訪談）

訪談嘉賓：

鄧德源， 才雲科技CTO。2011年畢業於電子科技大學機械與自動化專業，2013年獲美國頂級計算機學府Carnegie Mellon University大學電子與計算機工程學位，專修作業系統、分散式計算等方向。參與亞太機器人大賽，代表電子科大獲全國第一名，後代表中國隊在埃及獲金牌。

曾為美國谷歌叢集管理組核心成員，主要參與開發叢集管理系統。負責管理運維工程師提交的生產環境變更請求，自動化風險分析，自動化生產環境準備工作，以及各種叢集容錯處理。保證系統升級、軟硬體錯誤等均能及時被發現並處理，谷歌叢集能24/7小時不間斷工作。作為核心成員參加了開發基於容器叢集的谷歌開源專案（Kubernetes），一度成為全球前十的貢獻者和貢獻最高的華人。

訪談內容：

鄧老師目前在才雲科技主要負責什麼工作？

我目前在才雲科技主要負責公司內部的團隊管理，技術管理以及部分對外工作。

團隊管理方面主要包括搭建技術團隊、組織架構、制度規範的建立、技術文化等，技術管理方面主要是組建中層團隊、制定技術路線、建立培訓機制。對外方面，更多的是瞭解企業市場、瞭解客戶需求、反思產品。最終，希望我們的產品能為客戶提供更多的價值。

卡耐基梅隆學習和Google工作的經歷跟國內學習和工作相比，最大的差別有哪些？

卡耐基梅隆大學更加側重原理和實踐的結合，其中實踐性內容的質量非常高，比如基礎類的作業系統、編譯原理等課程。設定的每一門課程都會把原理解析得非常透徹，學生需要根據原理親自編寫屬於自己的作業系統或者編譯器。一些較為前沿的類別，比如雲端計算、人工智慧，教學內容大多都與業界接軌，並且學生有更多的自主性，可以根據某次課程的某個論點進行學術研究、參與相關開源專案的研發等。無論學生準備走學術界還是工業界，學校都可以提供非常多的資源。因此，卡耐基梅隆大學培養的學生大多數都能很快地融入到之後的科研或者工作當中。

大家可能認為卡耐基梅隆大學的學習壓力非常大，但是根據我個人的體會來看，並非如此。學校的整體氛圍實際上是比較寬鬆的，更重要的還是靠學生的自主意識。

至於工作方面，因為是直接從國外回國創業的，我不敢妄加評論國內的工作環境。

可以分享下在Google工作時，Google內部容器管理的經驗和教訓嗎？

Google內部容器管理平臺已經非常成熟，但也是一個持續演進的過程，其最早來源於Google Search的業務運維平臺。由三四個人將搜尋引擎中的錯誤處理等邏輯拿出來作為Borg的最初原型，使其他系統也能享受叢集服務。由於類似的歷史原因，Google的容器管理平臺和內部的業務結合非常緊密。

關於叢集管理經驗，首先一定要專注於持久的運維自動化工具開發。提到Google的容器管理平臺，自然會想到Borg。Borg的主要功能是容器的排程和編排，以及容器的生命週期管理。使用者不用考慮程式執行在哪裡，只需要根據描述檔案通知系統執行程式即可。Borg自己會考慮如何分配任務，任務錯誤重啟等眾多功能。Borg與外部的系統結合緊密，例如儲存系統、安全系統，開發者可以認為程式執行的所有環境都已經被準備好，只需要關心業務邏輯就好。儘管有如此多的功能，Borg依然只是平臺的一部分，Google再此之上做了非常多的工具，如機器生命週期管理系統“亞里士多德”，會持續監測物理機資訊並與Borg互動；叢集生命週期管理系統“PCMS”，負責接收叢集變更事件（如機器批量下線），與Borg互動確保業務穩定執行。

其次，監控是整個平臺穩定執行的核心。Borg出現不久，也就是2003年，其監控系統Borgmon就已經開始重點開發。Borgmon是基於黑盒的拉模型系統，側重效率，但也意味著它需要業務應用的配合。監控需要著重於延遲、流量、錯誤率等指標，針對不同的業務設計不同的粒度。例如，對於提供年SLA 99.9%的業務，需要將監控粒度放得更大。報警層面，Google更加看重“有效報警”，因此開發了Alertmanager來幫助使用者管理所有的報警。總而言之，Google的容器管理將監控提升到了“一等公民”的地位。

另外，優先順序和資源分配是容器管理的一個重點。幾乎所有使用者都不太明白如何去分配優先權（我的應用需要什麼樣的優先順序），以及請求多少資源（我的應用需要多少 CPU、記憶體）。在優先順序問題上，Google有一套優先順序配額相關的管理，確保高優先順序沒有被濫用；資源問題上，有類似Resource Weather的系統提供整體的資源分佈和使用情況，也有類似Flex、autopilot的系統幫助使用者決定、調整資源使用。優先順序和資源分配的合理管理，極大提高了系統資源利用率。有人曾經在Borg上做過實驗，利用Borg排程 1 萬個Hello world任務，總共用時大概2分半。但是，由於分配的優先順序很低，大多數時候並沒有10000個任務在執行，而是被其他應用搶佔（最高優先順序200，最低優先順序0）。

最後，健壯性測試非常有必要。健壯性測試包括容器管理平臺和執行在平臺之上的應用。物理裝置會出錯，例如物理硬碟；裝置也會有定期維護，例如Borg使用的機器平均大約每個月重啟一次。一箇中等規模的Borg叢集大約有 1w 臺機器，因此可以想象，叢集的“動盪“是比較頻繁的。但是即便在SLA中明確告訴了使用者可能出現的問題，使用者也會依賴於平臺。因此，Google會進行DiRT(disaster recovery test)，在叢集中注入較大規模的錯誤，幫助使用者提高應用的健壯性。

Google執行應用程式和服務的方式是怎樣的？

Google的程式碼都存放在同一個龐大的程式碼庫中，開發完程式碼後，開發者需要發一個Change List，進行code review。這類似於Github裡的Pull Request。在Google，code review必須嚴格執行，否則程式碼將無法提交（除了特殊情況）。

大致的流程如下。

1）開發者寫好程式碼後，先在本地進行編譯。由於Google的程式碼庫非常龐大，編譯程式碼所需的依賴可能就需要很長時間。Google內部使用一個叫作Blaze的編譯和測試工具，Blaze可以執行在Borg容器叢集上，通過優化的依賴分析，高階的快取機制和並行的構建方法，快速地對程式碼進行構建。而Google也將這一工具進行了開源：http://www.bazel.io/

2）構建完成後，我們需要在本地進行單元測試，而單元測試的執行測試由叫作Forge的內部系統完成，而 Forge也是通過執行在Borg容器叢集上實現快速並行測試的。

3）當本地的程式碼更新以Change List的形式傳送出來以後，Google內部的人員通過Critique的UI進行程式碼審查，同時Change List會觸發一個叫作TAP（tap anything protocol）的系統對該Change List進行單元測試，並保證這個區域性的程式碼變化不會影響Google其他的應用和程式碼。TAP具有智慧的依賴監測功能，會在Google內部浩瀚的程式碼庫和產品線中檢測到哪些部分可能會被影響到。

4）當程式碼通過測試和稽核提交後，我們會等到下一個Release cycle進行釋出。如前所述，Google內部的應用都是以容器的形式執行在Borg上，因此釋出的第一步工作就是通過一個叫作Rapid的系統，對程式碼進行容器打包成映象（內部稱為MPM格式，通過一個叫Midas的系統管理），再通過Rapid釋出工具進行釋出。

5）在新版本的釋出過程中，我們深度採用了不同形式的灰度測試機制。如果是平臺軟體更新（如容器叢集平臺，伺服器基礎映象升級），按照一定的速度逐漸更新到不同的資料中心，如第一天釋出到一個資料中心，第二天釋出到五個資料中心，以此類推，並在過程中不斷進行A/B測試和對比。如果是面向使用者的產品（如廣告、購物等），則會採用基於使用者流量分流的灰度釋出法，先選擇5%的使用者流量使用新的版本，並自動收集metrics來進行新舊版本的比對。

6）當應用成功執行後，應用可以通過BNS訪問其他服務。BNS類似於DNS，不同之處在於，BNS將IP和埠資訊都封裝在了BNS路徑中。除了使用者自身應用，Google的技術設施服務也可以通過BNS來訪問，例如 Chubby, Colossus。

Kubernetes會商業化麼？如何從Docker那裡，搶到足夠的使用者群？

目前來看，Kubernetes一定是會商業化的。不過，個人認為Kubernetes的大規模使用還有兩個前提：一是相關生態更加成熟，二是尋找更多企業場景。不同於Borg，Kubernetes需要滿足的場景更多；相反，Borg是專門為Google定製的，無需考慮複雜的場景，也無需構建開放的生態。因此，Kubernetes現在極力做到外掛化、模組化，以賦予企業更多定製化的能力，而Kubernetes本身僅提供核心功能。作為一款明星開源軟體，Kubernetes的重點一定是社群和生態的建設，一旦成功，商業化也是順其自然的事情，我們還需要給予它一定的耐心。

Docker專案一直在進行重構，拆分元件進行模組化，目標是標準化容器執行時等技術，構建可插拔的元件。在這一點上，其目標與Kubernetes是相同的，即構建完善的容器生態圈，並不存在衝突。但兩者所關注的層面並不完全相同，前者在於容器本身，後者在於大規模容器叢集的管理。但隨著Docker公司的贏利壓力，Docker公司開始逐漸在Docker（專案）中加入容器編排的功能。在這方面，Docker起步較晚，使用方式更加貼近開發者，適合於小規模環境；而Kubernetes更為完善，適合於場景複雜、較大規模的環境，也不存在直接的競爭。如果一定要說如何獲得更多的使用者，個人認為Kubernetes需要降低使用和運維的門檻，去更加貼近使用者。最後，即使兩者有趨同的情況，也不一定是敵對關係，放在他們面前的，是如何轉變企業的思維，如何權衡與虛擬化的關係等問題。

您認為國內企業，尤其是傳統企業應該做出哪些轉變，去擁抱國外先進的事物？

傳統企業的轉變，最重要的還是觀念上的改變。可喜的是，我們現在接觸到了很多的傳統企業，他們對新技術都是開放的態度。但轉變不是一朝一夕的事情，企業要學會從邊緣到核心的方法，從小做起，慢慢滲透到企業內部。另外，行業的推動也是極其重要的，只靠一家的力量是很難完成轉變的，企業需要聯合同行夥伴建立行業聯盟，學習行業標杆以及其他行業的經驗，一起推動轉型。最後，轉型離不開人，離不開新型人才，僅僅靠內部人力也很難完成轉變。傳統企業要積極尋找並引進人才，很多問題便可迎刃而解。不過，企業一定要注意可能的問題，比如新老融合的問題，這更需要企業決策者對轉型的決心和毅力。

---

——更多訪談

---

更多精彩，加入圖靈訪談微信！