Google 如何設計與構建超大規模的軟體系統

導讀：最近，在谷歌工作近十年的高階軟體工程師Onufry，以Brog為例，講解了Google 這樣的大公司裡如何設計與建造超大規模的軟體系統。Borg 是谷歌設計的一個叢集管理器，它負責對來自於幾千個應用程式所提交的 job 進行接收、除錯、啟動、停止、重啟和監控，這些 job 將用於不同的服務，執行在不同數量的叢集中，每個叢集各自都可包含最多幾萬臺伺服器。Borg 的目的是讓開發者能夠不必操心資源管理的問題，讓他們專注於自己的工作，並且做到跨多個資料中心的資源利用率最大化。

根據我的經驗，大多數的超大規模系統都擁有以下特點：

• 都是從一個相對較大的、較複雜的、但還不算是超大規模的系統核心開始做起。
• 隨著需求的快速迭代，該系統的複雜度顯著增大，並且區域性的邏輯也變得複雜起來。
• 隨後在一些高階工程師的帶領下，對系統進行多次的大規模重構，這些高階工程師通常對該系統有更多的瞭解。

我對一些超大規模的系統有過較深入的瞭解，在這些超大規模的系統中，最著名的莫過於谷歌的 Borg 系統了。從部署方面來看，Borg 系統幾乎涵蓋了谷歌所有的資料中心；從複雜度方面來看，Borg 系統估計是從 2000 年開始開發一直持續發展到現在這樣子的。因此無論從“部署“還是“複雜度”方面 Borg 系統都算得上是超大規模系統。

大而複雜的系統核心

與大多數複雜的系統一樣，Borg 最初的設計理念也是十分複雜的，但其實遠沒有今天這麼複雜。起初它的核心思想可以簡單用一頁文字來描述。簡要總結如下：

• 我們希望能夠自動地、動態地將所有的任務排程到由數千臺獨立機器組成的機器單元中。
• 排程工作將由一箇中央的“主伺服器”完成，它負責維護整個機器單元的執行狀態（作為主副本複製狀態）。
• 待工作的任務將指定它們對 CPU、磁碟和記憶體的要求，以及它們的優先順序。“主伺服器”將利用該優先順序對所有的任務進行合理的排序，暫時騰出低優先順序任務的資源給高優先順序的任務使用。
• 我們將採取超額預定資源的機制，將低優先順序的任務放入那些雖然被高優先順序任務預定但是還未使用的資源中。
• 對任務資源佔有量的評估，以及對超額配置所導致的資源短缺問題的響應，將由一臺機器上的代理（Borglet）來完成，該代理需要擁有超級使用者的許可權。

其他更多關於 Borg 系統的細節資訊此處省略不講。至此我已經可以在長達一個小時的講座中向電腦科學專業的同學講述完 Borg 系統的所有基本思想。

該專案最初的想法可能是十年前由那些擁有 WorkQueue 工作經驗的工程師提出來的，他們起初就已經清楚地知道自己想要實現的系統是什麼樣的。

新增更多的需求

隨後就出現了系統需求的大規模增長。同時也新增了 SSD 作為一種額外的資源。即便後來證明最初的假設是錯誤的，即如果一個機械硬碟發生故障，那麼所有使用該機械硬碟的任務都應該被認為是處於死亡狀態。因此該系統中便新增了允許倖存磁碟丟失的程式碼路徑，以用來重新排程資源，更好的組織機器單元。

此外，也圍繞“主伺服器”和 borglet 的核心思想構建了新的生態系統，它是一個內部檢查的工具，也是一款配置語言。它可以自動化預測任務對資源的需求，而不再需要人們在配置中手動輸入，同時還可以用來配額管理系統、跨機器單元排程，以及更多其他的功能，在這其中的每個功能都是為了滿足特定需求而構建的。

最終，系統也在我們的開發過程中得到了改進。最初每隔一秒計算一次的資源核算機制逐漸被基於系統核心的機制（cgroups）所取代。另外，我們的使用者也抱怨道，當系統有錯誤出現時，他們並不能完全理解他們所看到的內容，因此我們便徹底的檢查了之前所有的錯誤提示，並對錯誤提示進行了大幅改進。在 Borg 系統的“主伺服器”和 borglet 級別新增了只讀的使用者介面展示，然後隨著系統的改進，最終構建出了可以跨機器單元的使用者介面展示。

所有的這些都是在擴充 Borg 的主要系統或功能，也都將使其規模變得更大，系統變得更加複雜，儘管它們並不一定能使 Borg 系統變得更加深入。也就是說，你仍然可以僅僅通過對所有這些功能和想法的簡單瞭解來推斷其核心繫統和API。

主要的重構

大多數從事 Borg 系統工作的初級工程師都不是很瞭解整個 Borg 系統。他們可能在 borglet（我工作的地方）工作，也可能擁有更加具體的工作，比如：Borg系統的記憶體管理系統，在該記憶體管理系統中新增新的功能。雖然他們對 Borg 系統的核心思想有過簡單的瞭解，但他們可能從未接觸過 Borg 系統真正的核心程式碼，更不用說任何獨立的系統了。

然而，我認為這樣一個超大規模系統的持續進步還是主要取決於幾個高階工程師，他們相比之下更瞭解整個系統，也更加清楚系統的大部分功能是如何工作的，並且能夠意識到，在新的要求和需求下，系統中的哪些部分會發生怎樣的變化。如果由於某些原因導致系統的某些內容無法擴充，不論是由系統使用規模的極速擴大導致，還是由過多需求的增加導致系統的可維護性降低，最終可能都需要對該系統整體的體系結構進行大規模的重構來解決。

請注意，我們這裡提到的 “高階工程師的全域性重構” 和 “本地的程式碼重構” 之間的界限並不難分辨。這兩種重構都會導致 Borg 系統發生許多變化，當然我們也可以分別為他們命名，它們其中也都可能包含有主要的架構的變化，比如：“主伺服器”，將它的狀態變為 Paxos，或者 Borglet 的變化。因此，我認為一個系統的全域性體系架構的重構能力，對於這個龐大而複雜的系統是否能夠持續保持增長至關重要，不過當然還是要保證系統在全域性重構中不至於整體崩潰。

相關文章：

Google 釋出論文披露大規模叢集管理工具 Borg 的細節

原文連結：https://www.quora.com/How-do-software-engineers-design-and-adapt-huge-systems-like-the-Google-search-engine-Facebook-or-Windows