本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 架構概觀 彈性分析架構是透過識別工作負載所需的彈性屬性來開發。所需的屬性是您希望系統真實的物件。彈性通常由可用性測量，因此五個屬性是高可用性分散式系統的特性：備援、足夠的容量、及時輸出、正確的輸出和故障隔離。這些屬性會顯示在下圖中。 ![所需彈性屬性的關係](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/resilience-analysis-framework/images/properties.png) + **備援** – 透過消除單一故障點 (SPOFs) 的備援來實現容錯能力。備援可以從工作負載中的備用元件延伸至整個應用程式堆疊的完整複本。當您考慮應用程式的備援時，請務必考慮您使用的基礎設施、資料存放區和相依性所提供的備援層級。例如，Amazon DynamoDB 和 Amazon Simple Storage Service (Amazon S3) 透過複寫區域中多個可用區域的資料來提供備援，並在多個可用區域中的多個工作者節點 AWS Lambda 上執行函數。對於您使用的每個服務，請考慮服務提供的內容以及您需要設計的內容。 + **足夠的容量** – 您的工作負載需要足夠的資源才能如預期般運作。資源包括記憶體、CPU 週期、執行緒、儲存體、輸送量、服務配額等。 + **及時輸出** – 當客戶使用您的工作負載時，他們希望它在合理的時間內執行其預期的函數。除非服務針對延遲提供服務層級協議 (SLA)，否則其預期通常是根據經驗證據，也就是自己的體驗。此*平均客戶體驗*通常被視為系統中的中位 (P50) 延遲。如果您的工作負載花費的時間超過預期，此延遲可能會影響客戶的體驗。 + **正確的輸出** – 需要工作負載軟體的正確輸出，才能提供其預期功能。不正確或不完整的結果可能會比完全沒有回應更差。 + **故障隔離** – 當故障發生時，故障隔離會將影響範圍限制在預期的故障容器。它可確保工作負載的特定元件一起失敗，同時防止故障串聯到其他非預期的元件。它也有助於限制對工作負載客戶的影響範圍。故障隔離與前四個屬性略有不同，因為它接受已發生故障，但應該包含。您可以在基礎設施、相依性和軟體函數中建立故障隔離。 違反所需的屬性時，可能會導致工作負載無法使用或被視為無法使用。根據這些所需的彈性屬性和與許多 AWS 客戶合作的經驗，我們找到了五個常見的故障類別：單點故障、負載過大、延遲過長、設定錯誤和錯誤，以及共享命運，我們縮寫為 SEEMS。這些提供一致的方法來分類潛在的失敗模式，如下表所述。 | | | **失敗類別** | **違規** | **定義** | | --- |--- |--- | | **單點故障 (SPOFs)** | 備援 | 由於元件缺乏備援，單一元件中的故障會中斷系統。 | | **負載過大** | 足夠的容量 | 透過過多的需求或流量過度消耗資源，會阻止資源執行其預期的函數。這可能包括達到限制和配額，這會導致限流和拒絕請求。 | | **過度延遲** | 及時輸出 | 系統處理或網路流量延遲超過預期的時間、服務層級目標 (SLOs) 或服務層級協議 (SLAs)。 | | **設定錯誤和錯誤** | 正確的輸出 | 軟體錯誤或系統設定錯誤會導致輸出不正確。 | | **共享命運** | 故障隔離 | 由上述任何故障類別引起的故障會跨越預期的故障隔離界限，並層疊到系統的其他部分或其他客戶。 |