轉載自微信公衆號：成哥的世界，《公有云上應該怎麼做容災？》
接着上篇《做容災，雙活、多活、同城、異地、多雲，到底應該怎麼選？》，這篇聊聊公有云上應該如何建容災，跟我們自建機房有什麼區別，沒看過的同學，建議先從上篇文章看一下。
做個簡單總結就是，要想起到容災效果，優先做到同城雙活，再考慮異地雙活或多活。從這個鋪墊往下，談談如果我們上了雲，高可用和容災策略應該怎麼選擇。
我從幾個方面來講：
第一，先理解幾個公有云的通用概念。
爲了便於理解，我儘量說的通俗點，大家別跟我摳字眼，如果要找準確定義，大家可以Google，也可以去看幾大公有云實際的佈局，比看我講的更清楚。
我們知道的公有云一些專用名詞，如Region-地域和AZ-可用區，通用的IDC-機房園區，其中Region和AZ理解起來，本質上都是邏輯概念，並不像機房一樣更多的是物理概念。
簡單理解，先說Region，公有云可能會有北京的Region、上海的Region、杭州的Region等等。
對於AZ可用區，是包含在Region內的，比如公有云上海Region，可能會有多個AZ，而單個AZ可能會有一個或多個IDC機房園區組成，比如上海一號可用區，可能包括了徐匯IDC園區和靜安IDC園區。
這裏的原則，就是同一個AZ內的機房距離要相對較近，中間可以通過專線互通，保證較低的時延，從而將物理上分離的機房組合成邏輯上統一的可用區，這個是有建設標準的。
一個AZ多個IDC機房園區的目的，我認爲跟多的是提供足夠大的資源容量，單個機房的容量有時是有限的，特別是有些通用的存儲類服務務，如數據庫、緩存、消息、分佈式存儲等等也可以以AZ爲單位來統一管理，提供足夠容量的同時，也可以方便統一管理。
目前瞭解到的一些信息，貌似一個AZ對應一個IDC園區的情況多一些，特別是新建的IDC園區，規模足夠大，足夠匹配AZ的頭銜。
而一個Region多個AZ的目的，就是從底層的機房電力/網絡等層面來保障一個AZ出現故障的時候不會影響到另外一個可用區。
上面僅僅是舉例，方便理解，但是實際場景下，這些概念的界限有時候是有些模糊的，據說（僅僅是據說）早期阿里雲上海和杭州就是同一個Region，因爲兩個地方相對較近，專線帶寬、時延和成本相對可控（我想主要是因爲阿里有錢吧），所以雖然地域是兩個，但是從管理的維度，他們仍然是同一個Region。
第二，在公有云上的雙活、多活，應該怎麼選擇？
講到這裏，我們再聯繫下上篇文章提到的同城雙活、異地多活的概念，就不難理解，雲其實是在同城和異地這個概念之上的一個新的維度。
不過，上面文章如果看明白了，在整清楚上面的幾個概念，答案不難得出。
掙大眼睛看，我要說結論了！
如果要是做同城，其實就是選擇同一個公有云同一Region的不同AZ就好了。
因爲前面提過，不同的AZ在電力設施和網絡入口層面是做了隔離的，不會因爲一個AZ故障導致其它AZ同時故障。而且，不同AZ必然是不同的機房，如果考慮地域距離相對遠一些，可以選擇距離遠的AZ。
比如，業務運行在上海1可用區，再建一個雙活站點，我就選擇到松江區或嘉定區這種距離較遠的AZ，但是AZ之間有專線，時延也不用擔心有太大問題。
如果是異地，把異地轉化成Region這個維度來看就好了，就是選擇哪個Region的問題。
像阿里雲前兩天的IO HANG的故障，看故障描述，應該就是單AZ內分佈式存儲故障，也就是我們常說的ECS使用的網盤出現故障，很多ECS虛擬機不可用了，這個沒招，除非有同城不同AZ的雙活，立馬把業務切走，否則，就只能等着。
第三，關於雲產品層面的高可用應該怎麼做？
上面我主要講的還是基礎設施層面的內容，不同的AZ完全可以滿足要求。
或者說的簡單點，很多產品都是AZ級別的，在一個AZ不可用，但是可以跨AZ容災訪問。不過前面說的IO HANG的問題，就比較困難，現實情況下，跨AZ做虛擬機熱遷移，這麼大批量同時做，帶寬滿足不了，在很多技術細節上也沒法做到，所以，還是具體問題具體看。
但是有些產品，本身就是Region級別的，也就是有可能某個Region整個地域就是一套服務，比如常見的文件存儲OSS，或者騰訊雲的COS。
這裏帶來的問題就是，數據或文件存儲在Region內就一份，比如很多圖片、css、js、hdsf文件存在上面。
如果掛了，就是整個Region不可用，這時切同城AZ其實也沒用了，業務自身有雙活、有多活，這個時候都是沒效果的。
那咋辦呢？
就是在使用這類Region級別的產品，必須要要求在另一個Region有對應的容災集羣，出問題能切過去。
比如我們在騰訊雲上，COS就做了華東和華南兩個Region的同步和備份，如果出現災難狀態，華東不可用，我還可以切到華南。
當然，有備份，必然帶來成本，但是有時候總比故障造成的損失要小的多，這個還是看ROI。
對於公有云廠商來說，應該要提供這種Region級別的數據同步機制，客戶可以自己選擇是否需要備份，當故障時，雲產品做的完善點可以自己切走，但是廠商一般不會這麼做，因爲有時候影響並不是全局的，所以這個時候客戶自身就要做好切換手段，通過切域名或IP的方式，將服務依賴指向可用Region的備份集羣。
但是，是不是所有產品都適合這種模式呢？答案是，不一定，還是要看場景，看具體情況。
比如，對於文件存儲，業務對其時延的要求可能沒有這麼高，特別是用在CDN場景下，時延長一點也沒問題。
對於數據庫或緩存這樣的雲產品來說，跨Region就沒有任何意義了，時延太大，業務根本無法容忍。如果是跨AZ，數據庫可能還好，但是緩存有時候也無法接受。
從AWS的標準來說，像數據庫或緩存是要保證同Region跨AZ高可用的，但是實際能不能滿足真實的業務要求，這個還要看具體情況，有些系統對時延敏感度極高，可能容忍度就更弱一些。
好在絕大多數的產品都是AZ級別，Region的相對較少，但是一定要注意識別，如果有使用Region級別的產品，那我們的雙活、甚至多活方案，就要考慮這個因素，而不能僅僅考慮我們自身的技術架構。
單就這一點，客戶不提，一般雲廠商也沒人提，有時候爲了跟憂傷對比，反而更喜歡強調自己有多少個9的穩定性，這個從客戶引導上是有問題的。其實真誠一點，承認自己無法做到100%，建議客戶做更可靠的方案，產品在基礎能力層面更完善一些，反而會收到更多的利益，客戶也會更滿意。
所以，我前面一直在講，雲計算行業，需要有更多的解決方案架構師真正站在客戶角度考慮問題，當真正能解決用戶的痛點問題時，纔會帶來更廣闊的合作空間，最終帶來的收益，一定會這些地方呈現出來。
最後，總結一下：
到了公有云上，面對的場景，使用的產品類型不同，這時候要做高可用，要做容災，要考慮的因素就更多，其實比自建機房時考慮的因素還要多，因爲業務不僅僅是對基礎設施依賴，可能還跟很多雲產品發生了緊耦合，場景必然更復雜。
幾個結論：
-
第一，雲上做容災，做高可用，先搞清楚雲的幾個關鍵概念，比如Region、AZ和IDC，以及它們之間的關係。
-
第二，雲上的雙活就選同城不同AZ即可，多活就選多Region。
-
第三，一定要注意識別雲產品的高可用級別，是AZ級別，還是Region級別，如果是Region級別，就要考慮跨Region的備份方案，否則，即使做了業務多活和雙活，真的災難狀態下，還是起不到作用。
-
第四，大家可以繼續補充。。。。