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

\\

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

\\

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

\\

冗余

\\

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

\\

自動伸縮

\\

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

\\

基礎設施即代碼

\\

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

\\

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

\\

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

\\

不可變的基礎設施

\\

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

\\

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

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

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

\\

無狀態應用程序

\\

為了能夠使用自動伸縮和不可變的基礎設施，應用程序必須是無狀態的。這意味著所有請求都必須獨立于先前的請求或會話處理，不能將任何信息存儲在本地磁盤或內存中。在自動縮放組中共享狀態只能使用內存對象緩存系統，比如Memcached或類似的產品。

\\

避免級聯故障

\\

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

\\

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

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

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

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

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

\\

查看英文原文：How to Achieve a Resilient Architecture

總結

以上是生活随笔為你收集整理的如何实现弹性架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。