異地雙活的四個誤區

鄭昀（老兵筆記） 20190305

阿里雲華北二機房2019年3月3日凌晨服務中斷長達三小時，我在微博上喊出了：工程師趕忙起牀，切多活流量啊。

那麼切多活有什麼常見誤區呢？

A，災備（主備）仍是雙活？
多年前，你們每每作成了災備機房，一主一備。結果是，真正災難發生的時候，最高領導人下不了決心切機房，由於沒法預料切換後果（災難老是不期而遇，切過去就可能切不回來了）。
因此必定是多個數據中心同時運行着一樣的應用，擁有一樣的數據，任何一個客戶的交易能夠在分鐘級所有路由到另外一箇中心並對外提供服務，不至於說災難來臨時才發現集羣沒法工做。

B，雙活測試模擬正常流量切換就夠了嗎？
不是模擬在正常狀況下的多活切換，那怎麼測怎麼有。
而是模擬災難發生（忽然發生）的時候，另一個機房物理消失了，你該如何切換。
咱們過去犯的兩個錯誤是：
-用代碼邏輯限制雙活機房之間的數據庫同步不能延時超過N分鐘，超過了就阻止切換；
-限制雙活機房的 otter 服務訪問超時時間不得超過N分鐘，超過了就阻止切換。
問題就在於，真正災難發生的時候，機房已物理不可訪問了，這時候就是要馬上地、所有地切換流量，人下達的命令就是最終裁決。拼着損失一分鐘的交易和髒數據，也要把交易切到另外一個機房。

C，全部業務都雙活嗎？
基於互聯網公司經常使用的基本可用性保障原則，只是保障核心業務雙活。
怎麼定義核心業務？即不能容忍中斷的服務。
用戶註冊，商戶進件，這些都屬於能容忍臨時性中斷的服務。
非核心業務應用都被標記爲非多活業務，非多活數據庫與多活數據庫要嚴格區分開來。

D，切機房的時候直接切嗎？
雙活意味着兩個機房都不須要維護一個能承載全部流量的集羣，不然太費錢。
因此模擬切機房流量的時候，必定要測試與核心業務有關的全部應用自動擴容，擴容以後再切換流量。測試擴容的效率，分鐘級擴容完畢。
因此你的應用最好都是部署在Docker容器集羣上的，這樣才能作到擴容分鐘級。
並且你們通常是混合雲部署，因此在不一樣的雲平臺上，你的應用部署底層基礎最好都如出一轍，方便你擴容和切換。

-EOF-
歡迎訂閱老兵筆記：