如何實現彈性架構

為了管理大規模的系統，你必須把系統推向強度極限，但仍然有能力在故障中恢復，並且擁抱失敗，Adrian Hornsby 寫了兩篇部落格，分享了自己在大規模系統工作中十多年的經驗，以及他發現的有用的模式。

\\

Hornsby是AWS的技術專員，他指出，對於較小的系統，最多幾十個例項，完全執行模式通常是正常狀態，很少出現故障。在大規模系統中實現這一點幾乎是不可能的;相反，部分失敗是常態，他指出，對於大多數web應用程式來說，這並不是一個大問題，儘管這當然會影響收入。為了應對這一點，他的建議是在彈性成本和可能的收入損失之間找到一個很好的平衡。

\\

Hornsby描述了幾種他認為有助於構建彈性體系結構的模式，但他強調彈性不僅僅與軟體有關。基礎設施層、網路和應用程式設計以及人員和文化也很重要。

\\

冗餘

\\

對於Hornsby來說，在雲中部署應用程式時最重要的事就是冗餘了，通過部署多個例項(可能在不同的區域或地區)來增加可用性。

\\

自動伸縮

\\

Hornsby的下一步是根據需求自動調整應用程式的容量，這是目前常見的機制。不同的自動縮放技術以不同的速度運作，因此，選擇一種適合應用程式需求的非常重要。他還指出，由於容器平臺和功能的存在，如今的擴充套件速度要快得多。

\\

基礎設施即程式碼

\\

在使用基礎架構即程式碼時，可重複性是一個重要的收益點，他比較了使用一個模版針對多套環境手工配置資料中心的工作和多次自動執行模板的工作。

\\

如果，環境遭到某種方式的破壞，甚至被刪除時，您可以從備份中恢復所有資料，並使用模板重新構建所有內容。這比手工完成這些工作要快得多，風險也小得多。

\\

Hornsby還將基礎架構即程式碼視為知識共享。團隊可以像處理其他程式碼一樣對待這類程式碼，也可以使用拉請求來驗證更改。

\\

不可變的基礎設施

\\

不可變的基礎設施意味著對於每次部署來說，所有元件都是可替換的，不做任何更新，Hornsby notes提到兩條基於不可變伺服器模式的規則:

\\

• 不應該在實時系統上進行任何更新。\

• 必須始終從供應資源的新例項開始著手。\

在處理不可變的基礎設施時，Hornsby建議使用金絲雀部署，以減少部署新版本應用程式時出現故障的風險。使用這種技術，您可以在真實的生產環境中進行測試，並在需要時進行非常快速的回滾。

\\

無狀態應用程式

\\

為了能夠使用自動伸縮和不可變的基礎設施，應用程式必須是無狀態的。這意味著所有請求都必須獨立於先前的請求或會話處理，不能將任何資訊儲存在本地磁碟或記憶體中。在自動縮放組中共享狀態只能使用記憶體物件快取系統，比如Memcached或類似的產品。

\\

避免級聯故障

\\

按照Hornby的經驗，導致停機的一個常見原因是級聯故障，在這種情況下，通過不同型別的依賴關係發生的區域性故障有時會導致整個系統崩潰。一個常見的例子是過載，例如當一個叢集當機時，所有的流量都轉移到另一個叢集。為了避免這些型別的失敗，他推薦了一些模式，包括：

\\

• 超時。資料庫速度減慢時，如果仍有相同數量的傳入流量可能很快使系統失敗。超時的速度越快，可能意味著服務的質量下降而不至於崩潰。\

• 冪等操作。由於暫時的錯誤，客戶端可能多次傳送相同的請求，這可能導致錯誤。為了避免這種情況，Hornsby傾向於使用冪等請求，使這些請求可被反覆處理而不會出現問題。\

• 服務降級和回退。在處理高負載時，一種選擇是提供要求較低的服務變體。比如說，返回通用的資訊列表，而不是個性化的列表。\

• 拒絕。自衛的最後一步是開始放棄請求，最好是先放棄不那麼重要的請求。\

Hornsby最後指出，在處理雲中的大規模分散式系統時，間歇性錯誤是一種常態。可能很難一下子搞清楚如何及時響應這些錯誤，但他建議可以收集統計資料，並根據這些資料建立處理錯誤的閾值。最後，他強調了自動化的重要性。要得到彈性和可靠的應用程式，它們經過了充分測試過的部署並具有快速自旋時間，您必須儘可能地自動化。

\\

檢視英文原文：How to Achieve a Resilient Architecture