公眾號：大豬蹄子程式設計師
昨天科技圈最火的新聞應該是“AWS中國區光纜被挖，導致三星、小米等眾多企業服務不可用”。
又是光纜被挖，咦！？為什麼是又，讓我們來一起回到過去：
- 2019.6.02：亞馬遜光纜被挖斷,國內部分地區網路出現異常
- 2019.3.23：施工隊挖斷騰訊光纖,致騰訊旗下100多款遊戲受影響,損失大了
- 2015.5.27：由於杭州市蕭山區某地光纖被挖斷，造成目前少部分使用者無法使用支付寶
我這裡只是列出來了幾家大公司所涉及到的光纜被挖事故，其餘還包括什麼廣電光纜被挖，社保局光纜被挖就不列了，感興趣的自己去百度。
好，我們發現“公司再大，也怕施工隊”，那麼這種事故能怪施工隊嗎？個人覺得不能把責任都推給施工隊，當然我們這裡不討論這些，我們做為大公司，我們以後怎麼預防這種現象呢？
這個我們可以來看下支付寶的解決辦法，畢竟它老人家在2015年就經歷過這種慘況了。
2018年9月20日，杭州雲棲大會ATEC主論壇現場上演了一場特別的技術秀。螞蟻金服副CTO胡喜現場模擬挖斷支付寶近一半伺服器的光纜。結果只過了26秒，模擬環境中的支付寶就完全恢復了正常。
這種解決辦法就是“三地五中心”，這是一種機房架構，即在三座城市部署五個機房，一旦其中一個或兩個機房發生故障，依靠技術可以將故障城市的流量全部切換到執行正常的機房。
那麼在“三地五中心”之前還存在很多其他架構，我們一一來看一下他們的特點。
災難演進
最初，我們把應用(一個非常簡單的只讀應用，比如一個顯示Hello World的網頁，不考慮資料儲存)只放在一個機器上，那麼當這個伺服器down機了，我們的應用便不可用了。
所以，我們考慮把我們的應用放在多個機器上，在公司單獨開闢一個機房來放置這些機器，這樣單獨某一個臺機器down機了並不影響我們的應用。
但是，如果你們公司某一天停電了呢？這個時候我們就考慮在這座城市的另外一個地方在放置一個機房，這是應用就被部署在了同城的兩個機房（這個叫同城雙活）
但是，如果你們城市某一天經歷了海嘯、颱風、地震等自然災害，兩個機房都不能使用了，這個時候我們就會考慮在另外一個城市再搭建一個機房來部署我們的應用，這樣我們應用的可用性就更高了（這個叫異地多活）。
好，到此為止不管出現什麼樣的狀況，我們的應用基本上都可用（除非地球毀滅...）
那麼我們上面考慮的應用是一個非常簡單的只讀應用，所以各個地方的應用是可以同時對外提供服務的，那麼如果我們的應用涉及到資料儲存，這個時候各個地方的應用就不能同時對外提供寫入資料的服務了，因為很有可能會出現資料衝突，那麼我們暫且規定只有公司內部機房裡的伺服器（後文我們叫主機房）可以提供寫資料服務，而同城的另外一個機房以及異地的另外一個機房只能從主機房同步資料，這樣這兩個地方的機房的功能就叫災備，因為資料會同步，所以就算主機房停電了，另外兩個機房還是可以臨時來對外提供服務的。所以現在的架構可以如下：
當主機房停電後，使用者會去請求北京備份機房，當北京備份機房也停電後，使用者會去請求上海備份機房。
好，對於這個架構，我們剛剛說只有主機房能對外提供服務，另外兩個機房都只是作為容災的備份，那麼也就是說備份機房利用率不高，因為畢竟正常請求下主機房不可能老停電，所以對於備份機房能不能提高它的利用率呢？當然可以，我們可以讓北京的備份機房也去接收部分業務請求，只是這些請求可以沒那麼重要，比如一些讀請求，而上海的備份機房不去接收請求，還是單純作為容災備份機器，因為如果誰都不能保證當備份機房接收業務請求會不會出現其他不可預知的問題，那麼現在三個機房的角色實際上已經有些不同了：
這個就叫兩地三中心。
那麼兩地三中心這種架構是目前很多銀行或大型企業正在使用的一種架構，因為國家針對銀行的災備能力做過要求，資產超過多少多少的一定要做兩地三中心架構，以保證銀行系統的穩定。
那麼這種架構有沒有它的缺點呢？我們來考慮一下它的可用性高不高？可用性的意思就是這個架構處理使用者請求時夠不夠快？
我們發現這種架構，中心之間是需要資料備份的，那麼對於資料備份只有兩種方式，要麼非同步，要麼同步。
- 最大效能模式：如果是非同步，表示使用者一個寫資料請求，只要在生產資料中心儲存完資料後就會直接返回結果給使用者，同時非同步去備份資料，但是，如果正準備去非同步備份資料的時候生產資料中心停電了~，那麼這個時候還能將災備伺服器暴露出去給使用者提供服務嗎？不能了，因為很有可能災備中心的資料是過時的資料。
- 最大保護模式：如果是同步，表示使用者一個寫資料請求，不僅要等待生產資料中心儲存完資料，還需要等其他災備中心備份完資料後才能返回，而且僅僅當災備中心出現問題時，因為不能完成資料的備份，所以整個架構也不能對外提供服務，這種可用性是很低的。
- 最大可用模式：這是普遍採用的方案，正常情況下使用最大保護模式，同時生產資料中心監控災備資料中心，一旦發現某一災備中心出現了問題，那麼則會改為最大效能模式，這樣就保證了生產資料中心不受其他災備中心影響。
- 三寫兩同步：這是阿里之前的架構模式，意思是同城三個中心，資料備份不是發生在資料庫層面，而是應用層，當應用向資料庫去寫資料時，會同時向三個中心去寫資料，只要有兩個中心返回成功即可，這樣就算三個中心有一箇中心停電了，那麼並不影響整個架構的高可用，這個思路和我們前面三種是不一樣的，效能肯定會高很多。
好，我們介紹了一下兩地三中心，總結一下它的缺點：
- 災備中心利用率不高
- 生產資料中心停止執行後，災備中心中不一定有100%一模一樣的資料
- 成本高，但又無法真正實現期望的高可用能力
那麼為了解決這個問題，就出現了三地五中心，雖然名字和兩地三中心類似，但提供的功能完全不同。
三地五中心是指三個城市，5箇中心， 三地五中心基於的概念是單元化，還得花很大篇幅來講，下一篇繼續吧。
相信大家不喜歡在小小的手機螢幕上還看到一大塊的程式碼，閱讀體驗不好，所以我寫作的風格會文字偏多一點。如果覺得有所收穫就給個小小的贊吧。