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”
最佳實務:
-
實作適度降級以將適用的硬相依性轉換為軟相依性: 當元件的相依性狀況不良,元件本身仍可運作,但以降級的方式運作。例如,當相依性呼叫失敗時,容錯移轉為預先決定的靜態回應。
-
調節請求: 這是一種緩解模式,用於回應意外增加的需求。有些請求會接受,但超過定義限制的請求會遭到拒絕,並傳回訊息,指出它們已受到調節。預期用戶端會退避並放棄請求,或以較慢的速率再試一次。
-
控制和限制重試呼叫: 使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化這些重試間隔,並限制重試次數上限。
-
快速失敗和限制佇列: 如果工作負載無法成功回應請求,則快速失敗。如此將可釋放與請求關聯的資源,並且使服務在資源用盡時復原。如果工作負載能成功回應,但請求率太高,則改為使用佇列來緩衝請求。不過,請勿允許可能導致處理用戶端已放棄的過時請求之長佇列。
-
設定用戶端逾時: 適當設定逾時、系統性對其進行驗證,並且不要依賴預設值,因為它們通常設定得太高
-
盡可能讓服務無狀態: 服務不應要求狀態,或應該卸載狀態,以便在不同的用戶端請求之間,不依賴磁碟或記憶體中本機儲存的資料。這讓伺服器能夠任意置換,而不會對可用性造成影響。Amazon ElastiCache 或 Amazon DynamoDB 是卸載狀態的適當目的地。
-
實作緊急控制桿: 這是可緩解對工作負載的可用性影響的快速程序。它們可以在沒有根本原因的情況下操作。理想的緊急控制桿會提供完全決定性啟用和停用準則,將解析器的認知負擔降至零。範例控制桿包括封鎖所有機器人流量或提供靜態回應。控制桿通常是手動的,但也可以自動化。
改進方案
實作適度降級以將適用的硬相依性轉換為軟相依性
- 透過傳回靜態回應,您的工作負載可減輕在其相依性中發生的故障
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability - 偵測重試操作何時可能失敗,並防止用戶端以斷路器模式進行失敗的呼叫
CircuitBreaker
調節請求
- 使用 Amazon API Gateway
Throttle API Requests for Better Throughput
控制和限制重試呼叫
Error Retries and Exponential Backoff in AWS
- Amazon SDK 在預設情況下實作它。呼叫自己的相依服務時,在相依性層中實作類似的邏輯。根據您的使用案例確定逾時時間以及何時停止重試。
快速失敗和限制佇列
- 服務受壓時實作快速失敗
Fail Fast - 限制佇列: 在佇列式系統中,當處理停止但訊息持續送達時,待處理訊息可能大量積存,使得處理時間增加。工作可能太晚完成而無效,基本上會導致佇列要防範的可用性問題。
The Amazon Builders' Library: Avoiding insurmountable queue backlogs
設定用戶端逾時
AWS SDK: Retries and Timeouts
盡可能讓服務無狀態
- 移除實際上可以儲存在請求參數中的狀態。
- 某些資料 (如 Cookie) 可以在標頭或查詢參數中傳遞。
- 重構以移除可以在請求中快速傳遞的狀態。
- 在檢查了是否需要狀態之後,將狀態追蹤移至彈性的多區域快取或資料存放區,例如 Amazon ElastiCache、Amazon RDS、Amazon DynamoDB
或第三方分散式資料解決方案: 儲存無法移動到彈性資料儲存的狀態。
- 某個請求可能實際上並不需要某些資料,這些資料可以隨需擷取。
- 移除可以非同步擷取的資料。
- 確定滿足所需狀態要求的資料儲存。
- 考慮將 NoSQL 資料庫用於非關聯式資料。
實作緊急控制桿
- 實作和使用緊急控制桿的秘訣
- 當啟用控制桿時,請少做,而非多做
- 保持簡單,避免雙模式行為
- 定期測試您的控制桿
- 以下是非緊急控制桿動作的範例
- 新增容量
- 呼叫依賴您服務的用戶端服務擁有者,並要求他們減少呼叫
- 變更程式碼並將其釋出