AWS光纜被挖後對架構設計的一點總結(一)

公衆號:大豬蹄子程序員程序員

昨天科技圈最火的新聞應該是「AWS中國區光纜被挖,致使三星、小米等衆多企業服務不可用」。 又是光纜被挖,咦!?爲何是又,讓咱們來一塊兒回到過去:數據庫

  • 2019.6.02:亞馬遜光纜被挖斷,國內部分地區網絡出現異常
  • 2019.3.23:施工隊挖斷騰訊光纖,致騰訊旗下100多款遊戲受影響,損失大了
  • 2015.5.27:因爲杭州市蕭山區某地光纖被挖斷,形成目前少部分用戶沒法使用支付寶

我這裏只是列出來了幾家大公司所涉及到的光纜被挖事故,其他還包括什麼廣電光纜被挖,社保局光纜被挖就不列了,感興趣的本身去百度。服務器

好,咱們發現「公司再大,也怕施工隊」,那麼這種事故能怪施工隊嗎?我的以爲不能把責任都推給施工隊,固然咱們這裏不討論這些,咱們作爲大公司,咱們之後怎麼預防這種現象呢? 這個咱們能夠來看下支付寶的解決辦法,畢竟它老人家在2015年就經歷過這種慘況了。網絡

2018年9月20日,杭州雲棲大會ATEC主論壇現場上演了一場特別的技術秀。螞蟻金服副CTO胡喜現場模擬挖斷支付寶近一半服務器的光纜。結果只過了26秒,模擬環境中的支付寶就徹底恢復了正常。架構

這種解決辦法就是「三地五中心」,這是一種機房架構,即在三座城市部署五個機房,一旦其中一個或兩個機房發生故障,依靠技術能夠將故障城市的流量所有切換到運行正常的機房。 那麼在「三地五中心」以前還存在不少其餘架構,咱們一一來看一下他們的特色。異步

災難演進

最初,咱們把應用(一個很是簡單的只讀應用,好比一個顯示Hello World的網頁,不考慮數據存儲)只放在一個機器上,那麼當這個服務器down機了,咱們的應用便不可用了。 因此,咱們考慮把咱們的應用放在多個機器上,在公司單獨開闢一個機房來放置這些機器,這樣單獨某一個臺機器down機了並不影響咱們的應用。 可是,若是大家公司某一天停電了呢?這個時候咱們就考慮在這座城市的另一個地方在放置一個機房,這是應用就被部署在了同城的兩個機房(這個叫同城雙活) 可是,若是大家城市某一天經歷了海嘯、颱風、地震等天然災害,兩個機房都不能使用了,這個時候咱們就會考慮在另一個城市再搭建一個機房來部署咱們的應用,這樣咱們應用的可用性就更高了(這個叫異地多活)。 好,到此爲止無論出現什麼樣的情況,咱們的應用基本上均可用(除非地球毀滅...)性能

那麼咱們上面考慮的應用是一個很是簡單的只讀應用,因此各個地方的應用是能夠同時對外提供服務的,那麼若是咱們的應用涉及到數據存儲,這個時候各個地方的應用就不能同時對外提供寫入數據的服務了,由於頗有可能會出現數據衝突,那麼咱們暫且規定只有公司內部機房裏的服務器(後文咱們叫主機房)能夠提供寫數據服務,而同城的另一個機房以及異地的另一個機房只能從主機房同步數據,這樣這兩個地方的機房的功能就叫災備,由於數據會同步,因此就算主機房停電了,另外兩個機房仍是能夠臨時來對外提供服務的。因此如今的架構能夠以下: cdn

image.png
當主機房停電後,用戶會去請求北京備份機房,當北京備份機房也停電後,用戶會去請求上海備份機房。 好,對於這個架構,咱們剛剛說只有主機房能對外提供服務,另外兩個機房都只是做爲容災的備份,那麼也就是說備份機房利用率不高,由於畢竟正常請求下主機房不可能老停電,因此對於備份機房能不能提升它的利用率呢?固然能夠,咱們可讓北京的備份機房也去接收部分業務請求,只是這些請求能夠沒那麼重要,好比一些讀請求,而上海的備份機房不去接收請求,仍是單純做爲容災備份機器,由於若是誰都不能保證當備份機房接收業務請求會不會出現其餘不可預知的問題,那麼如今三個機房的角色實際上已經有些不一樣了:

image.png

這個就叫兩地三中心blog

那麼兩地三中心這種架構是目前不少銀行或大型企業正在使用的一種架構,由於國家針對銀行的災備能力作過要求,資產超過多少多少的必定要作兩地三中心架構,以保證銀行系統的穩定。遊戲

那麼這種架構有沒有它的缺點呢?咱們來考慮一下它的可用性高不高?可用性的意思就是這個架構處理用戶請求時夠不夠快? 咱們發現這種架構,中心之間是須要數據備份的,那麼對於數據備份只有兩種方式,要麼異步,要麼同步。

  • 最大性能模式:若是是異步,表示用戶一個寫數據請求,只要在生產數據中心存儲完數據後就會直接返回結果給用戶,同時異步去備份數據,可是,若是正準備去異步備份數據的時候生產數據中心停電了~,那麼這個時候還能將災備服務器暴露出去給用戶提供服務嗎?不能了,由於頗有可能災備中心的數據是過期的數據。
  • 最大保護模式:若是是同步,表示用戶一個寫數據請求,不只要等待生產數據中心存儲完數據,還須要等其餘災備中心備份完數據後才能返回,並且僅僅當災備中心出現問題時,由於不能完成數據的備份,因此整個架構也不能對外提供服務,這種可用性是很低的。
  • 最大可用模式:這是廣泛採用的方案,正常狀況下使用最大保護模式,同時生產數據中心監控災備數據中心,一旦發現某一災備中心出現了問題,那麼則會改成最大性能模式,這樣就保證了生產數據中心不受其餘災備中心影響。
  • 三寫兩同步:這是阿里以前的架構模式,意思是同城三個中心,數據備份不是發生在數據庫層面,而是應用層,當應用向數據庫去寫數據時,會同時向三個中心去寫數據,只要有兩個中心返回成功便可,這樣就算三個中心有一箇中心停電了,那麼並不影響整個架構的高可用,這個思路和咱們前面三種是不同的,性能確定會高不少。

好,咱們介紹了一下兩地三中心,總結一下它的缺點:

  1. 災備中心利用率不高
  2. 生產數據中心中止運行後,災備中心中不必定有100%如出一轍的數據
  3. 成本高,但又沒法真正實現指望的高可用能力

那麼爲了解決這個問題,就出現了三地五中心,雖然名字和兩地三中心相似,但提供的功能徹底不一樣。

三地五中心是指三個城市,5箇中心,三地五中心基於的概念是單元化,還得花很大篇幅來說,下一篇繼續吧。

相信你們不喜歡在小小的手機屏幕上還看到一大塊的代碼,閱讀體驗很差,因此我寫做的風格會文字偏多一點。若是以爲有所收穫就給個小小的贊吧。

相關文章
相關標籤/搜索