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

多宿主系統(tǒng)的簡單性對用戶是極有價值的，沒有多宿主系統(tǒng)的話，無論故障轉(zhuǎn)移、系統(tǒng)恢復還是一致性問題，都是應用需要解決的問題。而借助多宿主系統(tǒng)，基礎設施會處理這些麻煩的問題，應用開發(fā)者只要專注于自身應用即可，可用性和一致性有系統(tǒng)來保障。

部署在3個數(shù)據(jù)中心之上的多宿主系統(tǒng)，總同步性能為穩(wěn)定狀態(tài)的20%，總資源占用為170%，遠遠小于故障轉(zhuǎn)移系統(tǒng)所需的300%。

基于故障轉(zhuǎn)移系統(tǒng)的方式并未真正實現(xiàn)高可用性，而且由于需要部署備用資源，會帶來成本浪費。

以前我們在使用故障轉(zhuǎn)移系統(tǒng)時，有很多不好的體驗。由于非計劃性停機很少見，故障轉(zhuǎn)移系統(tǒng)多是后期才添加的功能，無法自動化執(zhí)行，也沒有經(jīng)過很好的測試。很多時候，團隊需要花費數(shù)日才能從停機中恢復，一個組件一個組件的上線，用自定義MapReduces之類的臨時工具執(zhí)行狀態(tài)恢復，并在系統(tǒng)處理停機時的積壓工作時，逐步執(zhí)行優(yōu)調(diào)。這些情況不僅讓系統(tǒng)無法再進行擴展，還讓團隊由于所運行的關(guān)鍵任務系統(tǒng)太過復雜而承受了極大壓力。

相比之下，多宿主系統(tǒng)在設計之初就將運行多個數(shù)據(jù)中心作為核心設計屬性，因此無需另外添加故障轉(zhuǎn)移系統(tǒng)。多宿主系統(tǒng)一直保持多個數(shù)據(jù)中心運行。每個數(shù)據(jù)中心都在持續(xù)處理工作，同時各數(shù)據(jù)中心之間的負載會自動進行平衡。一旦某個數(shù)據(jù)中心的處理速度減緩，系統(tǒng)就會自動將一部分工作調(diào)整到速度較快的數(shù)據(jù)中心上去。一旦某個數(shù)據(jù)中心出現(xiàn)故障完全不可用，所有工作都會自動分發(fā)到其他數(shù)據(jù)中心上去。

只有持續(xù)的動態(tài)負載平衡，不再有故障轉(zhuǎn)移的過程。多宿主系統(tǒng)通過實時同步的全局共享狀態(tài)來協(xié)調(diào)數(shù)據(jù)中心之間的工作。所有關(guān)鍵的系統(tǒng)狀態(tài)都有備份，以確保隨時能從另一個數(shù)據(jù)中心的某個點重新開始工作，同時確保恰一次語義（exactly once semantics）。在出現(xiàn)數(shù)據(jù)中心級別的故障時，多宿主系統(tǒng)是唯一能夠提供高可用性和完整一致性的系統(tǒng)。

在典型流系統(tǒng)中，事件處理基于用戶交互來解決；同時，全世界范圍內(nèi)的多臺數(shù)據(jù)中心會為用戶提供流量服務和日志存儲服務。日志收集服務會在全球范圍內(nèi)收集這些日志，并將其復制到兩臺或多臺特定的日志數(shù)據(jù)中心上。每個日志數(shù)據(jù)中心都會保存完整的日志記錄，并確保復制到某個數(shù)據(jù)中心中的所有事件都會（逐漸）復制到其他日志數(shù)據(jù)中心上。流處理系統(tǒng)運行在一個或多個日志數(shù)據(jù)中心之上，并處理所有事件。流處理系統(tǒng)所輸出的內(nèi)容通常會存儲在全球范圍內(nèi)的一些復制系統(tǒng)中，這樣從任何地方都能可靠地對輸出執(zhí)行消費。

在多宿主系統(tǒng)中，所有數(shù)據(jù)中心都會持續(xù)運行并處理事件，典型狀況下會部署三臺數(shù)據(jù)中心。在穩(wěn)定狀態(tài)下，這三臺數(shù)據(jù)中心每個都能處理33%的流量。如果某臺數(shù)據(jù)中心出現(xiàn)故障而停機，剩下的兩臺數(shù)據(jù)中心會分別承擔50%的流量處理工作。