谷歌架構的轉變：從單資料中心到故障轉移系統，再到多宿主架構

運作單資料中心的系統很有難度，那麼設想一下切換到雙資料中心吧，假設你需要對多個位于不同地理位置的資料中心提供支援。谷歌有一篇發人深思的優秀論文，其中對這一過程有所描述——“大規模高可用性：打造谷歌的廣告資料基礎設施”。

文中的主要觀點是：在将單個資料中心切換到多個資料中心時，典型的故障轉移架構在實踐中效果并不太好。能夠起到作用，使用較少資源就能提供高可用性和一緻性的方法，是原生的多宿主/多重連接配接架構（natively multihomed architecture）：

我們目前的方式是建構原生多宿主架構。 在這樣的系統中，多個資料中心會持續運作，并根據情況自發平衡不同資料中心的負載，同時還能以完全透明化的方式解決任意規模的資料中心停機。此外，按計劃執行的資料中心停機與維護事件也是完全透明化的，這樣就會将對營運系統造成的影響降到最低。在過去，要想完成停機與維護事件，需要付出大量人力将營運系統從一個資料中心遷移到另一個。

“多宿主”這種說法也許會令人費解，因為多宿主這個詞一般指的是一台電腦連接配接着多個網絡。不過按照谷歌的規模，用這種說法描述連接配接着多個資料中心也是非常自然的。

谷歌建構了多個多宿主系統，以確定在出現資料中心級别的停機時，還能保持高可用性（99.99%到99.999%）與一緻性，下面這些文章對這些系統進行了較長的描述：f1 / spanner：關系資料庫；photon：對多個連續資料流進行join的部署；mesa：資料倉儲。這些論文分别讨論了各系統所采用的方式，以及在建構多宿主系統時遇到的諸多挑戰：全局狀态同步、怎麼設定檢查點，以及可重複的輸入與隻執行一次的輸出等。

為了 保持可用性與一緻性，系統受到了很大限制。這就凸顯了谷歌持續在簡化這些複雜系統，提高其易用性上付出的努力：

多宿主系統的簡單性對使用者是極有價值的，沒有多宿主系統的話，無論故障轉移、系統恢複還是一緻性問題，都是應用需要解決的問題。而借助多宿主系統，基礎設施會處理這些麻煩的問題，應用開發者隻要專注于自身應用即可，可用性和一緻性有系統來保障。

在這篇論文中最大的驚喜就是：實際中，多宿主系統比故障轉移系統所耗費的資源還要少：

部署在3個資料中心之上的多宿主系統，總同步性能為穩定狀态的20%，總資源占用為170%，遠遠小于故障轉移系統所需的300%。

故障轉移系統有什麼問題？

基于故障轉移系統的方式并未真正實作高可用性，而且由于需要部署備用資源，會帶來成本浪費。

以前我們在使用故障轉移系統時，有很多不好的體驗。由于非計劃性停機很少見，故障轉移系統多是後期才添加的功能，無法自動化執行，也沒有經過很好的測試。很多時候，團隊需要花費數日才能從停機中恢複，一個元件一個元件的上線，用自定義mapreduces之類的臨時工具執行狀态恢複，并在系統處理停機時的積壓工作時，逐漸執行優調。這些情況不僅讓系統無法再進行擴充，還讓團隊由于所運作的關鍵任務系統太過複雜而承受了極大壓力。

多宿主系統的工作原理是什麼？

相比之下，多宿主系統在設計之初就将運作多個資料中心作為核心設計屬性，是以無需另外添加故障轉移系統。多宿主系統一直保持多個資料中心運作。每個資料中心都在持續處理工作，同時各資料中心之間的負載會自動進行平衡。一旦某個資料中心的處理速度減緩，系統就會自動将一部分工作調整到速度較快的資料中心上去。一旦某個資料中心出現故障完全不可用，所有工作都會自動分發到其他資料中心上去。

隻有持續的動态負載平衡，不再有故障轉移的過程。多宿主系統通過實時同步的全局共享狀态來協調資料中心之間的工作。所有關鍵的系統狀态都有備份，以確定随時能從另一個資料中心的某個點重新開始工作，同時確定恰一次語義（exactly once semantics）。在出現資料中心級别的故障時，多宿主系統是唯一能夠提供高可用性和完整一緻性的系統。

在典型流系統中，事件處理基于使用者互動來解決；同時，全世界範圍内的多台資料中心會為使用者提供流量服務和日志存儲服務。日志收集服務會在全球範圍内收集這些日志，并将其複制到兩台或多台特定的日志資料中心上。每個日志資料中心都會儲存完整的日志記錄，并確定複制到某個資料中心中的所有事件都會（逐漸）複制到其他日志資料中心上。流處理系統運作在一個或多個日志資料中心之上，并處理所有事件。流處理系統所輸出的内容通常會存儲在全球範圍内的一些複制系統中，這樣從任何地方都能可靠地對輸出執行消費。

在多宿主系統中，所有資料中心都會持續運作并處理事件，典型狀況下會部署三台資料中心。在穩定狀态下，這三台資料中心每個都能處理33%的流量。如果某台資料中心出現故障而停機，剩下的兩台資料中心會分别承擔50%的流量處理工作。