此內容已過時。這個版本的 Well-Architected 框架現在可以在以下位置找到: https://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/reliability.html

REL 5: 如何設計分散式系統中的互動以緩解或承受故障?

分散式系統倚賴通訊網路來互連元件 (例如,伺服器或服務)。即使這些網路上的資料遺失或延遲,您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務讓工作負載能夠承受壓力或故障,更快速地從其中復原,並減輕這類受損的影響。最終縮短平均復原時間 (MTTR)。

資源

Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
Error Retries and Exponential Backoff in AWS
Amazon API Gateway: Throttle API Requests for Better Throughput
The Amazon Builders' Library: Timeouts, retries, and backoff with jitter
The Amazon Builders' Library: Avoiding fallback in distributed systems
The Amazon Builders' Library: Avoiding insurmountable queue backlogs
The Amazon Builders' Library: Caching challenges and strategies
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability
CircuitBreaker (summarizes Circuit Breaker from “Release It!” book)
Michael Nygard “Release It! Design and Deploy Production-Ready Software”

最佳實務:

改進方案

實作適度降級以將適用的硬相依性轉換為軟相依性

  • 實作適度降級以將適用的硬相依性轉換為軟相依性: 當元件的相依性狀況不良,元件本身仍可運作,但以降級的方式運作。例如,當相依性呼叫失敗時,容錯移轉為預先決定的靜態回應。
  • 調節請求

  • 調節請求: 這是一種緩解模式,用於回應意外增加的需求。有些請求會接受,但超過定義限制的請求會遭到拒絕,並傳回訊息,指出它們已受到調節。預期用戶端會退避並放棄請求,或以較慢的速率再試一次。
  • 控制和限制重試呼叫

  • 控制和限制重試呼叫: 使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔,並限制重試次數上限。
    Error Retries and Exponential Backoff in AWS
  • 快速失敗和限制佇列

  • 快速失敗和限制佇列: 如果工作負載無法成功回應請求,則快速失敗。如此將可釋放與請求關聯的資源,並且使服務在資源用盡時復原。如果工作負載能成功回應,但請求率太高,則改為使用佇列來緩衝請求。不過,請勿允許可能導致處理用戶端已放棄的過時請求之長佇列。
  • 設定用戶端逾時

  • 針對任何遠端呼叫 (通常為跨程序的任何呼叫) 同時設定連線逾時和請求逾時: 許多框架都提供內建的逾時功能,但請注意,許多框架都有無限或過高的預設值。太高的值會降低逾時的實用性,因為當用戶端等待逾時發生時,資源會持續耗用。太低的值可能會增加後端流量和延遲,原因是重試的請求過多。在某些情況下,這可能導致完全停機,原因是正在重試所有請求。
    AWS SDK: Retries and Timeouts
  • 盡可能讓服務無狀態

  • 讓您的應用程式無狀態: 無狀態應用程式支援水平擴展,並且可以容忍單個節點的失敗。
  • 實作緊急控制桿

  • 實作緊急控制桿: 這是可緩解對工作負載的可用性影響的快速程序。它們可以在沒有根本原因的情況下操作。理想的緊急控制桿會提供完全決定性啟用和停用準則,將解析器的認知負擔降至零。範例控制桿包括封鎖所有機器人流量或提供靜態回應。控制桿通常是手動的,但也可以自動化。