無論是高可用計算架構還是高可用存儲架構，它們的核心設計目標均是在部分服務器出現故障時確保系統能繼續運行。然而，在極端情況下，如機房斷電、火災、地震或洪水等，可能導致一個地點的所有服務器同時出現故障，使得整個業務系統癱瘓。即便依靠其他地區的備份系統，全面恢復業務的時間也可能較長，從半小時到12小時不等。備份系統由于平時不提供服務，可能存在許多未被發現的潛在問題。如果業務需求是在這種災難性故障發生后也能保持業務連續性，或者希望在幾分鐘內快速恢復服務，那么就需要采用異地多活架構。

接下來，我將繼續探討異地多活架構的設計技巧和實施流程。

圖片

應用場景

異地多活架構的核心概念包括“異地”和“多活”，其中“異地”指的是將系統部署在地理位置分散的不同地點，類似于常說的“不把所有雞蛋放在一個籃子里”的策略；而“多活”意味著這些地理上分散的系統都處于活躍狀態，隨時能夠提供業務服務。要判斷一個系統是否實現了異地多活，主要看以下兩點：

在正常情況下，無論用戶連接到哪個地點的系統，都能夠接收到一致且正確的服務。

當某地的系統出現異常時，用戶可以無縫連接到其他地點的系統，繼續獲得所需服務。

相對于“多活”的“備”更多指的是備份系統，這類系統通常不對外提供服務，只在主系統出現問題時，經過一系列人工操作后才能變“活”，這個過程通常耗時較長。

雖然從理論上講，異地多活架構能夠提供極高的業務連續性，即使在面臨災難時也能保證業務不中斷，但這并不意味著所有業務都必須實現異地多活。實際上，異地多活架構的成本和系統復雜度都非常高。具體體現在：

• 系統設計復雜度顯著增加，需要構建一個在多個地點同時活躍的復雜系統架構。
• 運行成本提高，因為需要在多個數據中心部署并維護相同的業務系統。

因此，并非所有業務都適合采用異地多活架構。對于一些新聞網站、內部IT系統、游戲和博客等，如果不能承擔高昂的成本和復雜度，可以選擇僅進行異地備份。這類業務即便暫時中斷，也不會對用戶造成重大影響。例如，如果一個新聞網站暫時無法訪問，用戶可以選擇其他新聞源。

然而，對于像共享單車、網約車、支付寶、微信等關鍵業務系統，它們的中斷會直接影響到用戶的日常生活，因此必須實現異地多活架構。此外，對于規模較大的業務，異地多活不僅可以在突發事件中保證服務的連續性，還有助于維護品牌聲譽和最小化收入損失。例如，對于新聞網站來說，雖然短時間的服務中斷看似影響有限，但從長遠來看，頻繁的服務中斷會損害用戶信任，同時也會導致廣告收入的直接損失。

架構模式

異地多活架構根據地理位置的分布，可以分為同城異區、跨城異地和跨國異地。這里，我將詳細說明每種架構的細節及其優缺點。

同城異區

這種架構涉及在同一城市的不同區域部署多個數據中心。例如，在北京的海淀區和通州區各設有一個數據中心，它們通過高速網絡連接。

雖然在極端災難如全城大停電或洪水時，同城異區可能無法提供保護，但這種設計的優點在于網絡延遲極低，可以視為一個邏輯上的單一數據中心，這簡化了系統設計，降低了成本和復雜度。

盡管面對如新奧爾良洪水這樣的災難無力回天，但需要注意的是這類極端災難發生的頻率相對較低。相比之下，如數據中心火災、停電或空調故障這樣的常見問題更為頻繁，同城異區架構能有效應對這些情況。綜合考慮成本、復雜度和故障概率，同城異區為解決數據中心級別的故障提供了最優解決方案。

圖片

跨城異地

跨城異地指將業務系統部署在相距較遠的不同城市，比如北京和廣州，而不是相近的城市如廣州和深圳。

圖片

跨城部署的主要優點是能有效抵御區域性災難，如大規模停電或地區性自然災害。然而，增加的地理距離導致網絡延遲增加，這不僅是因為物理距離，還包括中間網絡設備處理等因素，這使得設計異地多活架構的復雜度大幅上升。

跨城異地的網絡傳輸速度會受到限制，這是由光速在光纖中的傳播速度決定的。此外，網絡中斷、光纜損壞等不可預測的因素也可能導致連接問題。例如，從廣州到北京的機房網絡延遲在正常情況下可能為50毫秒，但在網絡不穩定時，延遲可能急劇增加。

針對這種架構，必須考慮數據一致性與業務需求。對于要求高數據一致性的服務（如金融服務），跨城異地多活可能不適合，因為數據不一致性可能導致重大錯誤。而對于數據一致性要求較低的應用，如新聞發布或社交媒體，跨城異地多活則可以提供有效的災難恢復解決方案。

跨國異地指的是業務部署在不同國家的多個機房。相比跨城異地，跨國異地的距離就更遠了，因此數據同步的延時會更長，正常情況下可能就有幾秒鐘了。這種程度的延遲已經無法滿足異地多活標準的第一條：“正常情況下，用戶無論訪問哪一個地點的業務系統，都能夠得到正確的業務服務”。例如，假設有一個微博類網站，分別在中國的上海和美國的紐約都建了機房，用戶 A 在上海機房發表了一篇微博，此時如果他的一個關注者 B 用戶訪問到美國的機房，很可能無法看到用戶 A 剛剛發表的微博。雖然跨城異地也會有此類同步延時問題，但正常情況下幾十毫秒的延時對用戶來說基本無感知的；而延時達到幾秒鐘就感覺比較明顯了。

因此，跨國異地的“多活”，和跨城異地的“多活”，實際的含義并不完全一致?？鐕惖囟嗷畹闹饕獞脠鼍耙话阌羞@幾種情況：

為不同地區用戶提供服務

例如，亞馬遜中國是為中國用戶服務的，而亞馬遜美國是為美國用戶服務的，亞馬遜中國的用戶如果訪問美國亞馬遜，是無法用亞馬遜中國的賬號登錄美國亞馬遜的。

只讀類業務做多活

例如，谷歌的搜索業務，由于用戶搜索資料時，這些資料都已經存在于谷歌的搜索引擎上面，無論是訪問英國谷歌，還是訪問美國谷歌，搜索結果基本相同，并且對用戶來說，也不需要搜索到最新的實時資料，跨國異地的幾秒鐘網絡延遲，對搜索結果是沒有什么影響的。

假設我們做了前面提到的高可用存儲架構中的數據分區備份，又通過自動化運維能夠保證 1 分鐘就能將全部系統正常啟動，那是否意味著沒有必要做異地多活了？