鄭昀（老兵筆記） 20190305
阿里雲華北二機房2019年3月3日凌晨服務中斷長達三小時，我在微博上喊出了：工程師趕緊起牀，切多活流量啊。
那麼切多活有什麼常見誤區呢？
A，災備（主備）還是雙活？
多年前，大家往往做成了災備機房，一主一備。結果是，真正災難發生的時候，最高領導人下不了決心切機房，因爲無法預料切換後果（災難總是不期而遇，切過去就可能切不回來了）。
所以一定是多個數據中心同時運行着同樣的應用，擁有同樣的數據，任何一個客戶的交易可以在分鐘級全部路由到另一箇中心並對外提供服務，不至於說災難來臨時才發現集羣無法工作。
B，雙活測試模擬正常流量切換就夠了嗎？
不是模擬在正常情況下的多活切換，那怎麼測怎麼有。
而是模擬災難發生（突然發生）的時候，另外一個機房物理消失了，你該如何切換。
我們過去犯的兩個錯誤是：
-用代碼邏輯限制雙活機房之間的數據庫同步不能延時超過N分鐘，超過了就阻止切換；
-限制雙活機房的 otter 服務訪問超時時間不得超過N分鐘，超過了就阻止切換。
問題就在於，真正災難發生的時候，機房已物理不可訪問了，這時候就是要立刻地、全部地切換流量，人下達的命令就是最終裁決。拼着損失一分鐘的交易和髒數據，也要把交易切到另一個機房。
C，所有業務都雙活嗎？
基於互聯網公司常用的基本可用性保障原則，只是保障核心業務雙活。
怎麼定義核心業務？即不能容忍中斷的服務。
用戶註冊，商戶進件，這些都屬於能容忍臨時性中斷的服務。
非核心業務應用都被標記爲非多活業務，非多活數據庫與多活數據庫要嚴格區分開來。
D，切機房的時候直接切嗎？
雙活意味着兩個機房都不需要維護一個能承載所有流量的集羣，否則太費錢。
所以模擬切機房流量的時候，一定要測試與核心業務有關的所有應用自動擴容，擴容之後再切換流量。測試擴容的效率，分鐘級擴容完畢。
所以你的應用最好都是部署在Docker容器集羣上的，這樣才能做到擴容分鐘級。
而且大家一般是混合雲部署，所以在不同的雲平臺上，你的應用部署底層基礎最好都一模一樣，方便你擴容和切換。
-EOF-
歡迎訂閱老兵筆記：
