本文針對AWS宕機事件，分析了面對云服務中斷時，作為應用架構和運維人員，采用何種架構方式能盡可能規(guī)避這種事的影響。
今天，云服務宕機時有發(fā)生，比如AWS在前段時間就有過服務中斷。為應對這種宕機，有很多關于架構的討論以及它們能如何有效處理這種狀況。因為這些討論在成本、復雜性和權衡方面有很大不同，所以我想在概覽層面簡要介紹其中的幾個，然后深入介紹一個在很多對話中被忽略的一種架構。
1、多云
首先，就是關于多云價值的討論。它的理念就是在多個云中運行你的應用。
通過將負載分散到多個供應商，我們就能在其中的某一個供應商出現(xiàn)故障的時候得以幸免于難。在理論上，這種方式聽起來很不錯！當然，兩家云廠商不會同時宕機。但是，在實踐中，由于種種原因，在應用層面這樣做是很困難的：
每種云的基礎設施是不同的
部署的復雜性會大幅度增加
兩者之間的帶寬費用相當高昂
鑒于此，多云架構并不是高可用的可行方案（少數(shù)的邊緣情況除外）。
2、多Region
接下來，是關于多Region的討論。AWS Region是由多個可用區(qū)（availability zone，AZ）組成的，每個AZ是一個或多個的數(shù)據(jù)中心，它們具有獨立的電源、網(wǎng)絡和連接。在一個Region的多個AZ中運行能提供高可用性，但是無法提供災難恢復（Disaster Recovery，DR）功能。為實現(xiàn)這一點，我們需要多個Region。一個非常簡略的多Region結構如下所示：
這種方式解決了多云架構的多個問題：
應用依然在同一個云中運行，所以基礎設施保持不變
Region是完全獨立的，因此能獲得同樣的可用性優(yōu)勢
Region之間的帶寬費用要比云之間的費用低得多
但令人遺憾的是，大多數(shù)的評論都是圍繞Active-Active的多Region。也就是將負載同時分布到多個Region，這帶來了很多關于持久化同步方面的復雜性。同時，這種方式也會增加部署方面的復雜性，并且很多地方都很容易出錯，甚至它本身的停機時間比AWS導致的宕機時間可能還要長。
3、多Region DR
這是最近以來一種被忽視的方案。它的理念是在同一時間只有一個Region處于活躍狀態(tài)，在發(fā)生災難的時候，另外一個備用的Region能接管系統(tǒng)的功能（因此是DR）。這種方式和上面所述方案的收益是一樣的，但是它能極大地規(guī)避全Active-Active架構的復雜性。在這種架構下，備用Region不用完全構建，只需要復制持久化數(shù)據(jù)即可。
但是，稍等，在發(fā)生災難時，部署完整的應用棧難道不需要一段時間嗎？是的，是這樣的，不過這是允許的！對大多數(shù)常見的中斷場景來說，高可用是通過使用多AZ實現(xiàn)的，這種方式就足夠了。
如果整個Region出現(xiàn)問題，就像我們前段時間在AWS上所看到的那樣，花費小于一個小時的時間從備份中建立一個新的應用棧，仍然要比大于八個小時的中斷更可取。這個過程可以通過自動化的方式來進行簡化，但即便是手動的（但經(jīng)過了實踐檢驗）操作，有可選的備用方案也是很重要的。
所以，我們更深入地探討一下這種架構：
應用程序像平常那樣部署在主Region中
使用AWS托管的服務、備份和副本實現(xiàn)數(shù)據(jù)持久化，這通常只需要一兩個配置即可：
a.在不同的Region中為RDS添加一個讀副本；
b.創(chuàng)建Dynamo DB global表；
c.啟用S3 bucket副本
在進行故障恢復的時候，將應用程序部署在其他的Region上，并更新DNS的設置
a.這一過程要定期進行測試
這是一個銀彈嗎？絕不是。它并不適用于任何類型的工作負載，也絕對不可能適用于任何類型的宕機。然而，它是一個相對簡單的方案，并且有一定的成本效益。
4、總結
總之，中斷肯定是會發(fā)生的，這絲毫不會降低AWS的價值，但是這確實表明了良好架構和規(guī)劃的重要性。我們可以設計一些非常昂貴和復雜的系統(tǒng)來緩解這些中斷，但這對大多數(shù)客戶來說是過猶不及和不切實際的。幸運的是，我們還有一些其他的選擇，它們可能會提供一個“足夠有效”的解決方案，并有合理的權衡，這應該成為在AWS上開展工作時的“最佳實踐”。
原文鏈接：
https://www.forelse.io/posts/architectures-for-mitigating-aws-outages
