揭祕谷歌每週20億+容器背後的管理技術

此次我想跟你們分享一下谷歌使用容器集羣技術的案例實踐，因爲我我的在集羣管理團隊從事了3年的研發，這裏帶來的是我我的的經驗和觀點。

首先你們應該都據說過容器是什麼，而Docker則是基於容器技術的現階段最流行的一種容器產品、工具和生態。對於不瞭解Docker或者容器的人，一個簡單的比喻（但不是最貼切）就是容器就是一個更輕量級的「虛擬化」和「應用隔離」工具。具體有多輕量呢？一個服務器可能能夠運行10個虛擬機，可是一個服務器上能夠運行上百個容器，不一樣容器裏運行用戶的應用，並在必定程度上實現了相互之間的隔離。此外，容器能夠在秒級啓動，相比於啓動一個完整的虛擬機也有巨大的優點。除了效能上的提高，容器仍是一種應用的打包格式，能夠將應用和它運行時的依賴封裝在一塊兒，實現一次封裝、到處運行的功能。

谷歌從2000年初開始使用容器，可是它所使用的是自研的一種叫作lmctfy的容器格式，實際上是Let Me Contain That For You幾個單詞首字母的縮寫。谷歌最先使用容器的初衷之一是節省物理資源，經過用容器取代虛擬化層（hypervisor和每一個虛擬機所佔用的物理資源）來極大地節省計算成本。谷歌在2013年對lmctfy其進行了開源:連接，但因爲流行程度不如Docker，後面就沒有再繼續推廣。同時，根據谷歌內部運行15年容器的經驗來看，將應用程序裝入容器僅僅是第一步，然後面的大量工做是如何管理、運維這一個全新的容器世界，所以谷歌在2014年將精力轉入了開源容器集羣管理技術，即Kubernetes項目：連接

下面咱們正好來聊聊谷歌容器集羣的實踐。谷歌在2015年已經達到了80多個數據中心，超過一百萬臺機器。其中你們所熟知的search，youtube，maps，gmail等全部產品，包括不少咱們使用的內部工具，都是基於容器在運行。這個容器的數量是巨大的，官方稱之爲每週運行20億個容器。那麼緊接着咱們面臨的問題就是如何去管理這麼多的容器，其包括：

• 決定哪一個容器運行在哪臺服務器上

• 如何實現應用容器的多副本部署來實現高可用、高併發，同時按需動態伸縮以節省、優化資源利用率

• 如何自動監測應用的運行情況，並在出錯誤時進行自我修復和故障轉移

• 如何實現應用於配置的解耦合，使得一個數據中心的業務系統能夠快速的「全盤」複製到另外的數據中內心（咱們稱之爲cluster turnup and turndown，基本上是每一個季度都會發生的事情）

谷歌爲此創建了一整套集羣管理（Cluster Management）機制，其中包含幾十種不一樣的組建。以下圖所示：

初始化

咱們從硬件開始提及。當一臺服務器從QA經過後，它會投放到數據中內心的一個合適的rack中。當硬件設施、網絡都配好後，該服務器的信息會被寫入一個集中的機器數據庫裏。這個數據庫裏不光記錄了機器的硬件配置信息，還會記錄這臺服務器會被賦予哪些平臺級別的特殊使命（例如運行Borg的master節點、運行Chubby服務器等）。默認地，每個服務器上都要運行Borg的工做節點服務（Borglet），用來運行用戶應用和業務。

隨後，在集羣管理系統裏一個叫作「亞里士多德」的組件會按期（每15分鐘）獲取機器數據庫中的最新數據，當發現有新的服務器時，則會按照指示對該服務器進行配置：

1. 先經過調用一個叫作installer的組件對機器進行操做系統的安裝（谷歌叫作Prodimage，是一個基於Ubuntu的通過安全改良的系統鏡像）

2. 而後根據數據庫中的指示，在服務器上安裝合適的平臺軟件（borglet，borgmaster，chubby等）。

這裏指的點出的是，咱們對於每個生產服務器的配置和安裝，並不是是經過ssh進行，而是經過在機器上安裝一個API服務（稱爲sushiD），並經過調用API進行。這樣能夠避免SSH所暴露出來的過多的權限和潛在的attack surface。這個流程我用圖表總結以下：

管理和監測系統平臺

當服務器和平臺服務都運行起來之後，集羣管理系統則處於一個有限狀態機的模式，對服務器和上面的平臺軟件（例如Borg，Chubby等）進行不間斷、自動化的管理和維護。

1) 每一個機器上安裝的一個「機器醫生」agent會時刻關注服務器狀態（例如經過觀測/proc目錄等），並根據本身的一個「症狀規則庫」判斷機器是否出現問題，例如 bad-hda, slow-ethernet等，若有，則將此問題加入機器數據庫中。

2) 亞里士多德系統在按期檢查機器數據庫時會發現服務器上的問題，並採用相應的workflow和工具進行軟件修復。在谷歌，有60%的「硬盤」或文件系統故障均可以經過此自動化在線修復工具完成修復，無需人工介入。

3) 除了對機器的管理，亞里士多德還會經過預先定義的server 模塊和健康檢查機制檢查平臺軟件的健康性（例如Borg等）。不管是出現軟件問題，仍是軟件所在的機器出現了問題，根據策略咱們會採起不一樣的修復手段和軟件遷移機制。例如若是是Borg的master所在的物理服務器出現硬件問題，哪怕這個問題尚未影響到上面的服務（例如機器過熱），亞里士多德會觸發在線替換的workflow，主動在新的機器上部署Borg Master服務，作到未雨綢繆。

4) 當修復機器問題時，咱們要作的一個準備工做叫作drain，就是把機器上的業務和數據先刪除掉（因爲谷歌內部的應用、數據都採用分佈式結構，使得刪除某個節點不會影響總體業務）。然而在刪除前，亞里士多德系統會詢問一些安全把控組件，保證該服務器下線後不會影響總體的系統容量。

上述是一個很是基本的工做流，只是管中窺豹。我用流程圖總結以下：

發佈並運行應用

谷歌的代碼都存放在同一個龐大的代碼庫中，開發者在開發完代碼後相似於Github裏的Pull Request同樣也要發一個Change List，進行code review。在谷歌，code review是嚴格執行的，不然代碼沒法提交（除了特殊狀況）。大體的開發流程以下：

1）開發者寫好代碼後，先在本地進行編譯。因爲谷歌的代碼庫很是龐大，編譯代碼所需的依賴可能就須要很長時間。谷歌內部使用了一個叫作blaze的編譯和測試工具，Blaze能夠運行在Borg容器集羣上，經過優化的依賴分析，高級的緩存機制，和並行的構建方法，能夠快速地對代碼進行構建。而谷歌也將這一工具進行開源：http://www.bazel.io/

2）構建完成後，咱們須要在本地進行單元測試，而單元測試的運行測試由一個內部叫作Forge的系統完成，而Forge也是經過運行在Borg容器集羣上從而實現快速的並行測試。

3）當本地的代碼更新以Change List的形式發送出來之後，谷歌內部的人員經過一個叫作Critique的UI進行代碼審查，同時Change List會觸發一個叫作TAP（Tap Anything Protocol）的系統對該Change List進行單元測試，並保證這個局部的代碼變化不會影響谷歌的其餘應用和代碼。TAP具備智能的依賴監測功能，會在谷歌內部浩瀚的代碼庫和產品線中檢測到哪些部分可能會被潛在的影響到。

4）當代碼經過測試和審覈提交後，咱們會等到下一個release cycle進行發佈。如前所述，谷歌內部的應用都是以容器的形式運行在Borg上。所以發佈的第一步工做就是經過一個叫作Rapid的系統，對代碼進行容器打包成鏡像（內部稱爲MPM格式），再經過Rapid發佈工具進行發佈（按照前述的灰度發佈原則）。

用流程圖總結以下：

應用運行期間的自動化管理

最後，我來簡單分享下谷歌是如何採用容器集羣Borg來實現其應用的高可用和高擴展性的。因爲Borg博大精深，我這裏只列舉一些經典的功能：

1）動態任務調度：開發者經過Borg的命令行來將應用跑起來。在一個Borg Cell裏，Borg調度器將會動態的、自動的、智能的爲不一樣的應用選擇合適的機器來運行。如大數據業務、cron job、Google web業務、搜索業務等應用都會被動態的分配到集羣中的不一樣主機上，調度算法會根據每一個主機當前的物理資源狀況來作優化，實現物理資源利用率最大化，並保證各個主機的流量平均分配，不會形成局部熱點。不一樣的任務有不一樣的優先級，來保證大數據任務不會在用戶流量高峯期搶佔web業務的資源。

2）模塊、服務間的自動服務發現：Borg內運行的全部應用都有一個相似於DNS的名稱，咱們內部稱之爲BNS Path。不一樣的服務間相互訪問時能夠直接根據BNS名稱來進行鏈接，BNS系統會自動地將名稱轉化爲實際的IP地址。所以，在不一樣的環境切換時（例如從測試到生產）、或隨着主機的重啓或更換而致使底層IP地址變化，應用程序也無需作任何修改就可作到無縫遷移，極大地減小了環境配置和人工操做來帶的成本與風險。此外，BNS的方式也更好地支持了應用的多實例部署，在具體的實例發生變化時，應用的BNS不變。

3）多副本負載均衡與彈性伸縮：爲了應對互聯網應用的突發和難以預測的用戶流量，用戶在Borg平臺部署應用時可指定所須要的副本數量，例如運行10個Nginx的實例。Borg會自動建立指定個數的應用實例，而且：

對應用進行實時監測，保證任什麼時候候都有指定數量的實例在運行。若是因爲主機故障致使2個Nginx實例失效，Borg會主動地建立2個新的Nginx實例來保證高可用。

當其餘服務須要訪問Nginx時，無需直接綁定具體10個實例中的任何一個IP地址，而是能夠經過上述的服務名稱（例如「Nginx」）來訪問。Borg會自動將請求按照必定的負載均衡策略轉發到10個實例中的合適實例。

集羣管理中的其餘組件如 Autoscaler還支持自動伸縮策略，例如當CPU利用率超過60％時，自動將Nginx從10個實例擴展到20個實例。

4）自我修復與故障應對：當應用程序出現故障時，Borg會自動發現並在新的主機上重啓應用。Borg檢測故障的方法能夠針對業務和應用進行定製化，除了簡單地檢測應用是否在運行之外，還支持基於HTTP鉤子的自定義監測（內部稱爲healthz和varz）。而其開源的Kubernetes也支持相似的自定義健康檢查規則：

1. HTTP鉤子：例如對於Web應用，檢測其服務URL是否正常

2. 檢測腳本：對於任意應用，經過定時在應用容器中運行自定義腳本進行檢測。以Redis爲例，能夠經過 「redis-cli」來進行自定義的數據檢查。

3. TCP socket：能夠經過檢測TCP socket來判斷應用是否健康。

5）配置管理：一個複雜的生產系統中存在諸多配置，除了不一樣組件的IP地址、端口，還有應用程序的配置文件、中間件的配置文件等。Borg充分利用了基於Chubby的配置管理服務，實現應用與配置的分離。用戶能夠將不一樣環境下的應用配置文件、數據庫密碼、環境變量等配置放入每一個集羣內統一的Chubby服務中，併爲每個配置項取名字（例如 「APP_CONFIG_FILE」, 「DB_PASSWORD」等），然後應用可經過這些名字來在運行時獲取這些與環境相關的配置信息。此外，Chubby支持watcher功能，所以應用程序能夠動態監聽其配置文件是否有變化，實現配置的熱更新。感興趣的朋友能夠參考Chubby的論文來了解更多詳情：連接

Q&A環節

Q：數據分析真的能驅動用戶快速增加麼？

A：必定能的！谷歌有很是龐大的數據分析團隊，除了專門的團隊，廣告、購物等revenue產品都是基於數據。開發新功能前要經過理論驗證和數據分析推演它對用戶增加的做用（好比click through rate）；此外，每一次新的release，必定是經過嚴格的A/B測試，經過數據分析，所以廣告組和shopping組裏有很是多的data scientist。

Q：谷歌的管理制度對你目前公司管理有哪些方面的影響和應用？

A：從我我的僅有的團隊管理經驗來看，有值得借鑑的地方也有不接地氣的地方。在個人實踐裏，performance review中融入不少peer review的成分對於創建健康的技術團隊氛圍和互幫互助精神比較有利。此外經過planning poke來作規劃也能充分調動你們積極性，讓每一個人都參與其中，同時經過「賺取點數」讓你們感到這個形式比較有意思。

可是20%和團隊輪換等，一方面是隻有大公司才玩得起，另外一方面是谷歌工程師的自我管理約束力和self motivation也是在通常公司可能難以找到的。因此在管理的靈活性上要打一些折扣。

Q：OKR制定後發生戰略調整，是否也同時修改OKR？若是這一變化發生在考覈期已通過了一半的時候如何處理？

A：是的，出現重大的戰略調整，在審覈OKR的時候每每會加上"blocked by XXX"，這個會靈活調整的。可是客觀上，確實會對這個OKR的assignee形成不可避免的影響。我我的經歷了3次谷歌內部戰略調整形成的被迫轉變方向，這會影響我的績效和工做的連續性。

Q：Google的技術和產品是兩個團隊嗎？是產品提需求嗎？有項目經理嗎？

A：Google通常分爲是userfacing product還有internal product（好比borg）。對於前者，有專門的產品經理，通常是產品經理提需求，技術團隊實現並參與討論，和傳統的比較像。對於internal product，通常用戶是谷歌工程師本身或是SRE，這種產品通常沒有PM，由工程師或SRE本身提需求。

Q：谷歌怎麼監控系統異常，如何預防和恢復？

A：首先，最重要的幾點：1）監控系統必定要避免cyclicdependency，好比監控borg容器集羣的系統不能運行在borg上。2）監控的指標必定要簡單，actionable。具體的監控和預防除了一些黃金metrics，還要根據業務來制定，這個我不太好一律而論。從預防和恢復的角度，講究三個層面：a) prevention, b) detection, c) resilience。具體展開的話有不少東西，能夠私下細聊。

做者簡介：

才雲 聯合創始人 & CEO 張鑫

曾爲美國谷歌軟件工程師，從事谷歌核心技術底層系統研發。2012年至2014年，做爲主要技術人員從事谷歌數據中心（IDC）集羣管理系統（Cluster Management）的研發，該集羣系統自動管理和維護95%以上的谷歌集羣機器；帶頭開發的自動故障應對系統將谷歌集羣的故障率大大下降，爲谷歌節省了每一年千萬美圓的運維成本；做爲核心技術人員參與了谷歌雲計算平臺的系統到產品的全棧式開發；開發的圖形化應用部署（Click-to-deploy）、部署經理（Deployment Manager）等產品上線後即得到用戶普遍使用；設計了谷歌倡導的新一代「雲服務」（Managed Cloud）的設計，此理念得到了美國IBM，VMWare，Redhat等雲計算巨頭公司一致響應。於2012獲美國頂級計算機學府Carnegie Mellon University (CMU)大學計算機博士學位，發表國際學術論文數十篇，成爲分佈式系統和網絡安全方向的學術專家，曾爲美國個性醫療初創公司SMART-MD, AllPancreas提供應用軟件平臺構架、安全技術諮詢和基於雲平臺的系統開發。