來膜拜下 Google 的全球化網站架構

知識 08-31

這是 Google SRE 工程師在2018年5月的一篇分享。本文大致的介紹了 Google 整個網站的 infrastructure，以及代碼發布流程。而更詳細的細節，可以閱讀 Google 出的《Site Reliability Engineering》這本書。

原視頻 Google Tech Talk 的鏈接：https://youtu.be/dhTVVWzpc4Q

網路層

Google Edge network，是 Google 分布全球各地的伺服器網路Data Center 通過國際骨幹網 B4 連接

Data Center 內部使用 Jupiter 連接。Jupiter 可以把多個交換機（一般是幾百個）虛擬成一個交換機。Jupiter 的帶寬大約是 1.3PB/s

一個發給 google 的 web request 通過 edge network 之後，到達 Google frontend （GFE）。GFE 進行 reverse proxy （反向代理），將 request 發送給內部 service

Global software load balancer （GSLB）在三個層面做 load balance

地理位置層面的 load balance，比如發往 google.com 的 request

針對不同產品的 load balance，比如 google maps, youtube

RPC load balance

所以，用戶瀏覽 google.com 時，request 通過當地的 ISP，到達 Google edge network，到達 GFE，然後通過 GSLB 進行 load balance，然後通過Jupiter，轉送到 service。整個過程的耗時在 ms 級。

Data Center

Data Center 的層級關係是：

一個 campus 可以有多個數據中心。campus 類似於 region 或 availability zone 的概念。圖中展示的是一個 campus，包含兩個 data center

Data center 有多個 cluster。圖中每個 data center 有兩個 cluster ，用方形表示。

cluster 有很多排（row）

每排有很多伺服器機架（rack）

每個機架上有很多台機器（machine）

Campus > Data center > Cluster > Row > Rack > Machine

Cluster 的管理

Cluster 需要高效地管理裡面的伺服器資源。 Google 內部，有 job 的概念。每個 job 有很多子 task（關於 job 和 task 的概念，可以參考之前 Netflix Titus 架構部分的內容）。job 還定義了期望使用多少資源。

工程師們使用內部軟體運行 job。job 被發送給 Borg （Borg 是 Google 內部的容器管理工具，暫時未開源）。Borg master 詢問 scheduler 應該由哪幾台機器來運行 job。得到回應後，將請求發給指定的機器 Borglet，開始運行 job。如果job 失敗，應該會被自動重新運行。

Google 使用 Borg name service （BNS）來定位伺服器上的 task。格式是 /bns////。

BNS 地址需要映射到 IP:port 地址，並且保證同步。

Lock service

這個 BNS 映射到 IP 的信息，存儲在另一個內部服務 Chubby 中。Chubby 是一個分散式系統中的鎖服務，它下面還提供一個可以用類似 API 方式操作的文件系統，並使用 Paxos 演算法來實現各個伺服器之間的非同步一致（asynchronous consensus）。這個映射信息就是在 Chubby 裡面。

存儲系統 storage

HDD + SSD：在存儲系統的最底層，是機械硬碟和固態硬碟。

D：意思是 disk，用來管理 HDD + SSD。D 提供的服務是存儲臨時數據，主要是給運行中的 job 使用。

Colossus 是基於 google file system 開發的分散式文件系統，運行在 cluster 之內，支持永久保存數據，支持複製、加密等等。

Bigtable 是一個NoSQL 資料庫。Bigtable 可以保存有序的數據。在 cluster 之間進行複製時，bigtable 保證 eventually consistent。

Spanner 是一個 NewSQL 資料庫。旨在實現具有 NoSQL 一般可擴展性的關係型資料庫。

通過 Borg， Google 將伺服器集群實現的和單獨一台電腦一樣，可以運行 job 也可以存儲數據。但是分散式系統會面臨機器損壞的情況。舉個例子，如果一個job 運行到一半，機器壞了，怎麼辦？

Monitoring

上面那個問題是通過監控的辦法解決的。 Borgmon 是 Borg 的監控工具。圖中， Borgmon 存在於很多層級。Borgmon 獲取各個 task 的運行狀態信息，然後最後向上匯總到 global borgmon。而 cluster borgmon 除了把信息匯總給 global borgmon，還發送給 google 的 time series database （時序資料庫）以及 alert manager 警報系統。例如當某個 cluster 的錯誤率異常高的時候，會觸發警報。

還有一個輔助工具 Prober ，負責給 task 所在伺服器發送請求，並監控響應時間。這是從另一個角度觀察伺服器的健康狀況。Prober 也將信息匯總給 borgmon。

Inter-task communication 任務之間的通訊

task 和其他 task 之間進行通訊使用 Stubby。Stubby 是一個 RPC（遠程進程調用）服務，基於 http，使用 protobuf 協議。或者可以簡單的說，task 之間使用 protobuf 進行 RPC。

從代碼到 production

Google 以他們使用 mono repo 出名。他們的代碼管理工具叫做 Piper（類似於 git）。到2016年為止， Piepr 管理了10億文件，20億行代碼，9百萬個源碼文件，總過大約 86 TB 的數據，3500萬次 commit。

當提交代碼時，工程師寫一份文檔 changelist，會有其他工程師使用 Rietveld 做 review，項目管理者最終同意發布。提交代碼到 code repo 時，系統會自動運行一個presubmit check檢測。比如靜態代碼分析等。檢測通過後，代碼進入 repo。

代碼提交成功後，Blaze （Google 的 build tool，它的開源版是 Bazel）將代碼編譯成二進位文件。Blaze 的使用，需要工程師指定 build 的 output 輸出，dependencies 依賴等等。

另一個工具 Continuous testing，從 repo 獲得最新代碼後開始運行自動化測試。通過後，一個叫 Rapid 的工具會調用 Blaze 來生成 MPM （Midas Package Manager）package。MPM 給軟體加上名字、版本號，以及簽名以確保軟體的 authenticity。最後 MPM package 被 Sisyphus 部署到 production。Sisyphus 是 google 的 deploy 工具，可以做 deploy 過程中很多複雜而又繁瑣的工作。並且可以指定 deploy 的方式，比如是立即通過 canary 的方式 deploy，還是指定未來某個時刻 deploy。