才雲科技CTO鄧德源：不可不知的谷歌集羣管理經驗

本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明做譯者、出處，並保留本文的原始連接：http://www.ituring.com.cn/art...

訪談嘉賓：

鄧德源， 才雲科技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須要下降使用和運維的門檻，去更加貼近用戶。最後，即便二者有趨同的狀況，也不必定是敵對關係，放在他們面前的，是如何轉變企業的思惟，如何權衡與虛擬化的關係等問題。

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

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

---

——更多訪談

---

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