# 設計分散式系統中的互動以緩解或承受失敗
分散式系統倚賴通訊網路來互連元件 (例如，伺服器或服務)。即使這些網路上的資料遺失或延遲，您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。這些最佳實務可讓工作負載承受壓力或故障，更快速地從其中復原，並減輕這類受損的影響。最終縮短平均復原時間 (MTTR)。
這些最佳實務可防止故障，並改善平均故障間隔時間 (MTBF)。
**Topics**
+ [REL05-BP01 實作適度降級，以將適用的硬相依性轉換為軟相依性](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 限流請求](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 控制和限制重試呼叫](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 快速檢錯和限制佇列](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 設定用戶端逾時](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 盡可能讓系統處於無狀態](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 實作緊急槓桿](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 實作適度降級，以將適用的硬相依性轉換為軟相依性
即使相依性變得不可用，應用程式元件仍應繼續執行其核心功能。它們有可能提供稍微陳舊的資料、備用資料，甚至未提供任何資料。這可確保整體系統運作在本地化失敗時只會受到最低限度的阻礙，同時提供核心商業價值。
**預期成果：**當元件的相依性狀況不良，元件本身仍可運作，但以降級的方式運作。元件的失敗模式應被視為正常運作。工作流程應適當設計，使此類失敗不會導致完全失敗，或至少會進入可預測和可復原的狀態。
**常見的反模式：**
+ 未識別所需的核心業務功能。即使在相依性失敗期間，也不測試元件是否正常運作。
+ 發生錯誤時，或只有多個相依性的其中之一無法使用，且仍可傳回部分結果時，就不提供資料。
+ 當交易部分失敗時建立不一致的狀態。
+ 沒有替代方法可存取中央參數存放區。
+ 因重新整理失敗而使本機狀態失效或清空，而未考量這麼做的後果。
**建立此最佳實務的優勢：**按正常程序降級可改善系統整體的可用性，並且讓最重要的功能保持運作，即使在失敗期間亦然。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
按正常程序實作降級，有助於將相依性失敗對元件功能的影響降到最低。理想情況下，元件會偵測相依性失敗，並以對其他元件或客戶造成最小影響的方式解決這些問題。
按正常程序降級的架構，意味著在相依性設計期間會考量潛在的失敗模式。對於每種失敗模式，都有一種方法可至少將元件最關鍵的功能提供給呼叫者或客戶。這些考量可能會成為可供測試和驗證的其他要求。理想情況下，即使有一或多個相依性失敗，元件仍然能夠以可接受的方式執行其核心功能。
這在商業上和技術上都同樣值得討論。所有業務要求都很重要，都應盡可能地滿足。然而，若無法滿足各項要求將會如何，仍是值得提出的問題。一個系統可以設計成可用且一致的，但在必須放棄一項要求的情況下，何者較重要？ 對於付款處理，可能應選擇一致性。對於即時應用程式，可能應選擇可用性。對於面向客戶的網站，答案可能取決於客戶的期望。
這意味著什麼，取決於元件的要求，以及應將哪些內容視為其核心功能。例如：
+ 電子商務網站可能會顯示來自多個不同系統的資料，例如個人化推薦、排名最高的產品，以及客戶訂單在登陸網頁上的狀態。當一個上游系統失敗時，顯示其他所有內容，而不是向客戶顯示錯誤頁面，仍然是合理的。
+ 如果個別作業之一失敗，執行批次寫入的元件仍然可以繼續處理批次。實作重試機制應該要很簡單。為此，您可以向呼叫者傳回關於哪些操作成功、哪些操作失敗及其為何失敗的資訊，或將失敗的請求放入無效字母佇列以實作非同步重試。失敗操作的相關資訊也應記錄下來。
+ 處理交易的系統必須確認是否執行了所有更新，或完全未執行更新。對於分佈式交易，可使用 Saga 模式在相同交易的後續操作失敗的情況下回復先前的操作。在此，核心功能保有一致性。
+ 具時間性的系統應該能夠處理未及時回應的相依性。在這類情況下，可以使用斷路器模式。若來自相依性的回應開始逾時，系統可以切換到不會進行其他呼叫的關閉狀態。
+ 應用程式可從參數存放區讀取參數。使用一組預設的參數建立容器映像，並在參數存放區無法使用時使用這些參數，會很有效用。
請注意，在元件失敗的情況下採取的路徑需進行測試，且應遠比主要途徑簡單。一般來說，[應避免使用備用策略](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)。
## 實作步驟
識別外部和內部相依性。請考量其中可能會發生什麼樣的失敗。思考在這類失敗期間，將上游和下游系統以及客戶受到的負面影響降到最低的方法。
以下列出相依性，並說明如何在其失敗時按正常程序降級：
1. **相依性的部分失敗：**一個元件可能會向下游系統提出多個請求，可以是對一個系統的多個請求，或者對多個系統各提出一個請求。視業務環境而定，對此可能會有不同的適當處理方式 (如需詳細資訊，請參閱實作指引中的先前範例)。
1. **下游系統因高負載而無法處理請求：**如果對下游系統的請求一直失敗，則繼續重試是沒有意義的。這樣可能會對已過載的系統產生額外的負載，並使復原變得更加困難。此時可以使用斷路器模式，以監控對下游系統的失敗呼叫。若有大量呼叫失敗，將會停止向下游系統傳送更多請求，且偶爾才會讓呼叫通過，以測試下游系統是否已恢復可用性。
1. **參數存放區無法使用：**若要轉換參數存放區，可以使用容器或機器映像中包含的軟相依性快取或有效的預設值。請注意，這些預設值需要保持最新狀態，並包含在測試套件中。
1. **監控服務或其他非功能性相依性無法使用：**如果元件間歇性地無法傳送記錄、指標或追蹤給中央監控服務，最好還是照常執行業務功能。一般而言，長時間不日誌記錄或推送指標且未顯示任何訊息，是不可接受的。此外，某些使用案例可能需要完整的稽核項目才能滿足合規要求。
1. **關聯式資料庫的主要執行個體可能無法使用：**Amazon Relational Database Service 與幾乎所有關聯式資料庫一樣，只能有一個主要寫入器執行個體。這會對寫入工作負載造成單一失敗點，並使擴展變得更加困難。透過使用多可用區域組態以獲得高可用性，或使用 Amazon Aurora Serverless 以獲得更好的擴展性，可以減輕部分問題。對於非常高的可用性要求，完全不依賴主要寫入器是有效用的。對於唯讀的查詢可以使用讀取複本，以提供備援和橫向擴展的能力，而不僅僅是縱向擴展。寫入可以緩衝處理 (例如，在 Amazon Simple Queue Service 佇列中)，如此，即使主要寫入器暫時無法使用，仍然可以接受客戶的寫入請求。
## 資源
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (摘要說明「Release It\$1」書籍中的斷路器)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS 中的錯誤重試與指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [Amazon 建置者資料中心：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon 建置者資料中心：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon 建置者資料中心：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon 建置者資料中心：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**相關影片：**
+ [重試、退避和抖動：AWS re:Invent 2019：Amazon 建置者資料中心簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 限流請求
限流請求以減輕因需求非預期地增加而耗盡資源。系統會處理低於限流速率的請求，並拒絕超過定義限制的請求，且傳回一則訊息，指出請求已遭到限流。
**預期成果：**由於客戶流量突然增加、洪水攻擊或重試風暴而造成的大量尖峰，可透過請求限流來緩解，讓工作負載能夠繼續正常處理支援的請求量。
**常見的反模式：**
+ API 端點限流未實作或保留為預設值，而未考量預期的數量。
+ API 端點未經過負載測試，或未測試限流限制。
+ 限流請求率，而不考量請求大小或複雜性。
+ 測試請求率上限或請求大小上限，但不同時測試兩者。
+ 資源不會佈建在測試時建立的相同限制。
+ 未針對應用程式對應用程式 (A2A) API 取用者設定或考量使用計畫。
+ 水平擴展的佇列取用者未進行最大並行設定。
+ 未實作個別 IP 位址的速率限制。
**建立此最佳實務的優勢：**設定限流限制的工作負載能夠在非預期的數量尖峰情況下正常運作，並成功處理已接受的請求負載。API 和佇列的請求若突然或持續激增將會受到限制，且不會耗盡請求處理資源。速率限制會限流個別請求者，使來自單一 IP 位址或 API 取用者的大量流量不會耗盡資源而影響到其他取用者。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
服務應設計為處理已知的請求容量；此容量可透過負載測試來建立。如果請求到達率超過限制，會有適當的回應訊號指出請求已受到限流。這可讓取用者處理錯誤並於稍後重試。
當您的服務需要限流實作時，請考慮實作權杖儲存貯體演算法 (在此演算法中，權杖對於請求具重要性)。權杖會按每秒的限流率重新填入，並依照每個請求一個權杖的比例非同步清空。
![\[說明權杖儲存貯體演算法的圖表。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) 會根據帳戶和區域限制實作權杖儲存貯體演算法，並且可根據使用計畫對個別用戶端進行設定。此外，[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) 和 [Amazon Kinesis](https://aws.amazon.com/kinesis/) 可以緩衝請求以平滑請求速率，並為可解決的請求提供更高的限流。最後，可以使用 [AWS WAF](https://aws.amazon.com/waf/) 實作速率限制，以針對會產生異常高負載的特定 API 取用者進行限流。
## 實作步驟
可以使用 API 的限流限制來設定 API Gateway，並在超出限制時傳回 `429 Too Many Requests` 錯誤。可以搭配使用 AWS WAF 與 AWS AppSync 和 API Gateway 端點，以按照 IP 位址啟用速率限制。此外，如果您的系統可容忍非同步處理，您可以將訊息放入佇列或串流中，以加快對服務用戶端的回應速度，進而提升到更高的限流率。
透過非同步處理，當您將 Amazon SQS 設定為 AWS Lambda 的事件來源時，可以[設定並行上限](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)，以避免高事件率消耗工作負載或帳戶中其他服務所需的可用帳戶並行執行配額。
雖然 API Gateway 提供了權杖儲存貯體的受管實作，在您無法使用 API Gateway 的情況下，您可以對服務使用權杖儲存貯體的語言特定開放原始碼實作 (請參閱「資源」中的相關範例)。
+ 了解並設定每個區域帳戶層級的 [API Gateway 節流限制](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)、每個階段的 API 以及每個使用方案層級的 API 金鑰。
+ 將 [AWS WAF 速率限制規則](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)套用至 API Gateway 和 AWS AppSync 端點，以防止泛洪並封鎖惡意 IP。此外也可在 A2A 取用者的 AWS AppSync API 金鑰上設定速率限制規則。
+ 考慮您是否需要比 AWS AppSync API 的速率限制更高的限流控制，如果需要，請在 AWS AppSync 端點前面設定 API Gateway。
+ 將 Amazon SQS 佇列設定為 Lambda 佇列取用者的觸發器時，請將[並行上限](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)設定為足以符合服務層級目標的值，但不會消耗影響其他 Lambda 函數的並行限制。當您透過 Lambda 使用佇列時，請考慮在相同帳戶和區域中的其他 Lambda 函數上設定預留並行。
+ 使用 API Gateway 與 Amazon SQS 或 Kinesis 的原生服務整合來緩衝請求。
+ 如果您無法使用 API Gateway，請查看語言特定程式庫，為您的工作負載實作權杖儲存貯體演算法。查看範例區段並自行研究，以尋找合適的程式庫。
+ 測試您預計要設定的限制，或您打算允許增加的限制，並記錄已測試的限制。
+ 請勿將限制提高到您在測試時建立的範圍外。增加限制時，請先確認佈建的資源已等同於或大於測試情境中的資源，然後再套用增加。
## 資源
**相關的最佳實務：**
+ [REL04-BP03 持續工作](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 控制和限制重試呼叫](rel_mitigate_interaction_failure_limit_retries.md)
**相關文件：**
+ [Amazon API Gateway：調節 API 請求以獲得更佳的輸送量](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF：以速率為基礎的規則陳述式](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [導入使用 Amazon SQS 作為事件來源時的 AWS Lambda 並行上限](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda：並行上限](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**相關範例：**
+ [三項最重要的 AWS WAF 以速率為基礎的規則](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [Java Bucket4j](https://github.com/bucket4j/bucket4j)
+ [Python 權杖儲存貯體](https://pypi.org/project/token-bucket/)
+ [節點權杖儲存貯體](https://www.npmjs.com/package/tokenbucket)
+ [.NET 系統執行緒速率限制](https://www.nuget.org/packages/System.Threading.RateLimiting)
**相關影片：**
+ [使用 AWS AppSync 實作 GraphQL API 安全最佳實務](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**相關工具：**
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS](https://aws.amazon.com/sqs/)
+ [Amazon Kinesis](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [AWS 上的虛擬等候室](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 控制和限制重試呼叫
使用指數退避，在每次重試之間的間隔逐漸拉長後重試請求。在重試之間導入抖動以隨機化重試間隔。限制重試次數上限。
**預期結果：**分散式軟體系統中的典型元件包括伺服器、負載平衡器、資料庫和DNS伺服器。在正常操作期間，這些元件可以回應具有暫時性或有限錯誤的請求，以及無論是否重試都將持續存在的錯誤。當用戶端向服務發出請求時，請求會取用資源，包括記憶體、執行緒、連線、連接埠，或任何其他有限的資源。控制和限制重試是釋出資源並將資源耗用量降到最低的策略，可讓處於壓力下的系統元件不致不堪負荷。
當用戶端請求逾時或收到錯誤回應時，他們應該判斷是否要重試。如果執行重試，他們會使用具有抖動和最大重試值的指數退避來執行此作業。因此，後端服務和程序從負載中得到緩解並獲得自我修復的時間，進而更快速地復原和提供成功的請求服務。
**常見的反模式：**
+ 在未新增指數退避、抖動和最大重試值的情況下實作重試。退避和抖動有助於避免因為在共用間隔內無意間進行協調重試而產生人為流量尖峰。
+ 實作重試，而不測試其效果，或假設重試已內建到 中，SDK而不測試重試案例。
+ 未能了解從相依性發布的錯誤代碼，因而重試了所有錯誤，包括有明確原因指出缺少權限的錯誤、組態錯誤，或其他預期必須要手動干預才能解決的狀況。
+ 未解決可觀測性實務，包括對重複的服務失敗進行監控和提醒，使基礎問題廣為人知並且可以解決。
+ 在內建或第三方重試功能堪用時，開發自訂重試機制。
+ 以複合重試的方式在應用程式堆疊的多個層級重試，會嘗試在重試風暴中進一步耗用資源。請務必了解這些錯誤如何影響您所依賴的應用程式，然後僅在一個層級實作重試。
+ 重試不是等冪的服務呼叫，導致非預期的副作用，例如重複的結果。
**建立此最佳實務的優勢：**重試可協助用戶端在請求失敗時獲得所需的結果，但也會耗用更多伺服器的時間來取得他們想要的成功回應。若失敗是罕見或暫時性的，重試可以有效運作。若失敗是由資源超載引起的，重試可能會使情況變得更糟。在用戶端重試中新增具有抖動的指數退避，可讓伺服器在資源超載導致失敗時進行復原。抖動可避免將請求對應到尖峰，而退避會減少將重試新增至正常請求負載所造成的負載上升。最後，請務必設定最大重試次數或經過時間，以避免建立會產生亞穩態失敗的積存。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
控制和限制重試呼叫。使用指數退避以在逐漸延長間隔後重試。引進抖動來隨機化重試間隔，並限制重試次數上限。
有些 AWS SDKs依預設會實作重試和指數退避。在工作負載中適用的情況下，使用這些內建 AWS 實作。在呼叫等冪的服務時，以及重試可改善用戶端可用性時，在您的工作負載中實作類似的邏輯。根據您的使用案例確定逾時時間以及何時停止重試。為那些重試使用案例建置和模擬演練測試情境。
## 實作步驟
+ 確認應用程式堆疊中的最佳層級，以針對您應用程式所依賴的服務實作重試。
+ 請注意，現有的 SDKs 會針對您選擇的語言實作經過驗證的重試策略，並具有指數退避和抖動，並且比編寫您自己的重試實作更有利。
+ 在實作重試之前，請確認[服務是冪等的](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)。實作重試後，請務必在生產環境中加以測試和定期模擬演練。
+ 呼叫 AWS 服務 時APIs，請使用 [AWS SDKs](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)和 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)並了解重試組態選項。確認預設值是否適用於您的使用案例，並視需要進行測試和調整。
## 資源
**相關的最佳實務：**
+ [REL04-BP04 讓變異操作冪等](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 限流請求](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 快速檢錯和限制佇列](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 設定用戶端逾時](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 監控工作負載的所有元件以偵測故障](rel_withstand_component_failures_monitoring_health.md)
**相關文件：**
+ [中的錯誤重試和指數退避 AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon 建置者資料中心：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [指數退避和抖動](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ 以無能方式確保重試安全 APIs ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**相關範例：**
+ [Spring 重試](https://github.com/spring-projects/spring-retry)
+ [Resilience4j 重試](https://resilience4j.readme.io/docs/retry)
**相關影片：**
+ [重試、退避和抖動： AWS re：Invent 2019：介紹 Amazon Builders 程式庫 （DOP328）](https://youtu.be/sKRdemSirDM?t=1884)
**相關工具：**
+ [AWS SDKs 和 工具：重試行為 ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface： AWS CLI 重試 ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 快速檢錯和限制佇列
在服務無法成功回應請求時快速檢錯。如此將可釋出與請求關聯的資源，並且使服務可在資源用盡時復原。快速檢錯是一種完善的軟體設計模式，可用來在雲端中建置高度可靠的工作負載。佇列也是一種完善的企業整合模式，可以平滑負載，並且讓用戶端在可容忍非同步處理時釋出資源。如果服務在正常情況下能夠成功回應，但在請求速率太高時會失敗，請使用佇列來緩衝請求。不過，請勿允許建置長佇列積存，這可能導致用戶端已放棄的過時請求受到處理。
**預期成果：**當系統遇到資源爭用、逾時、例外狀況或灰色失敗而使服務水準目標無法達成時，快速檢錯的策略可加快系統復原速度。必須吸納流量尖峰且能支應非同步處理的系統，可讓用戶端使用佇列緩衝處理後端服務的請求以快速釋出請求，藉此提升可靠性。緩衝處理要排入佇列的請求時，會實作佇列管理策略，以避免發生無法克服的積存。
**常見的反模式：**
+ 在 DLQ 磁碟區上實作訊息佇列，但不設定無效字母佇列 (DLQ) 或警示，以偵測系統失敗。
+ 未測量訊息在佇列中的存留期，這是一種延遲測量，用以了解佇列取用者何時進度落後或發生錯誤導致重試。
+ 當處理這些訊息沒有任何價值，且業務需求已不存在時，未清除佇列中已積存的訊息。
+ 在後進先出 (LIFO) 佇列可更妥善地滿足用戶端需求時設定了先進先出 (FIFO) 佇列，例如，當不需要嚴格排序，以及積存處理延遲了所有新的和時間敏感的請求，導致所有用戶端都經歷違反服務水準的狀況。
+ 將內部佇列公開給用戶端，而不是公開管理工作接受以及將請求放入內部佇列的 API。
+ 藉由將資源需求分攤到不同請求型態，將過多的工作請求類型合併到可能加劇積存條件的單一佇列中。
+ 儘管需要不同的監控、逾時和資源分配，仍在同一佇列中處理複雜而簡單的請求。
+ 不驗證輸入或使用判斷提示在軟體中實作快速檢錯的機制，以對可用正常程序處理錯誤的較高層級元件快顯例外狀況。
+ 不會從請求路由中移除錯誤的資源，特別是在失敗處於灰色地帶，因損毀和重新啟動、間歇性相依性失敗、容量減少或網路封包遺失而導致成功與失敗並存。
**建立此最佳實務的優勢：**快速檢錯的系統更容易偵錯和修正，並且在發佈至生產環境之前，常會出現編碼和組態方面的問題。納入有效佇列策略的系統，可針對流量尖峰和間歇性系統失敗狀況提供更高的恢復能力和可靠性。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
快速檢錯的策略可以編碼為軟體解決方案，並設定到基礎設施中。除了快速檢錯以外，佇列也是一種簡單而強大的架構技術，可將系統元件平滑負載分離。[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 提供監控失敗和發出相關警示的功能。已知系統失敗時，可以叫用緩解策略，包括背離受損的資源。當系統使用 [Amazon SQS](https://aws.amazon.com/sqs/) 和其他佇列技術來實作佇列以平滑負載時，必須考量如何管理佇列積存以及訊息取用失敗。
## 實作步驟
+ 在軟體中實作程式化判斷提示或特定指標，並使用這些提示或指標來明確提醒系統問題。Amazon CloudWatch 可協助您根據應用程式日誌模式和 SDK 檢測來建立指標及提醒。
+ 使用 CloudWatch 指標和警示背離受損的資源，這些資源會增加處理的延遲，或持續無法處理請求。
+ 藉由設計 API 使用非同步處理來接受請求，並使用 Amazon SQS 將請求附加到內部佇列，然後透過成功訊息回應產生訊息的用戶端，讓用戶端可以釋出資源並繼續進行其他工作，同時讓後端佇列取用者處理請求。
+ 藉由比較現在時間與訊息時間戳記，在每次從佇列中取出訊息時產生 CloudWatch 指標，來測量和監控佇列處理延遲。
+ 因失敗而無法成功處理訊息，或無法在服務水準協議內處理磁碟區中的流量尖峰時，請將較舊或過多的流量排除至溢滿佇列。這可讓您優先處理新工作，並且等到有可用的容量時再處理較舊的工作。這種技術類似於 LIFO 處理，方便對所有新工作進行正常的系統處理。
+ 使用無效字母或重新驅動佇列，將無法處理的訊息從積存移到可稍後再研究和解析的位置
+ 進行重試，或在可接受的情況下，藉由比較目前時間與訊息時間戳記，捨棄與請求用戶端不再相關的訊息，將舊訊息捨棄。
## 資源
**相關的最佳實務：**
+ [REL04-BP02 實作鬆散耦合相依性](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 限流請求](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 控制和限制重試呼叫](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 定義和計算指標 (彙總)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 透過您的系統監控請求的端對端追蹤](rel_monitor_aws_resources_end_to_end.md)
**相關文件：**
+ [避免無法處理的佇列積存](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [快速檢錯](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [如何防止 Amazon SQS 佇列中不斷增加的積存訊息？](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [Elastic Load Balancing：區域轉移](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [Amazon 應用程式復原控制器：流量容錯移轉的路由控制](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**相關範例：**
+ [企業整合模式：無效字母通道](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**相關影片：**
+ [AWS re:Invent 2022 - 操作高可用性多可用區域應用程式](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**相關工具：**
+ [ Amazon SQS](https://aws.amazon.com/sqs/)
+ [Amazon MQ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 設定用戶端逾時
在連線和請求上妥善設定逾時、有系統地對其進行驗證，並且不要依賴預設值，因為它們不知道工作負載具體細節。
**預期成果：**用戶端逾時應考量與等待需要花費異常時間才能完成的請求相關的用戶端、伺服器和工作負載成本。由於無法知道任何逾時的確切原因，用戶端必須使用服務知識來找出對可能原因和適當逾時的期望
用戶端連線根據設定的值逾時。經歷逾時後，用戶端決定退回並重試，或開啟[斷路器](https://martinfowler.com/bliki/CircuitBreaker.html)。這些模式可避免發出可能使基礎錯誤情況惡化的請求。
**常見的反模式：**
+ 不知道系統逾時或預設逾時。
+ 不知道正常的請求完成時間。
+ 不知道完成請求異常耗時的可能原因，或是與等待這些作業完成相關聯的用戶端、服務或工作負載效能成本。
+ 不知道受損的網路只有在達到逾時後才會造成請求失敗的可能性，以及未採用較短逾時的用戶端和工作負載效能的成本。
+ 不測試連線和請求的逾時情境。
+ 將逾時設定得太高，這可能會導致較長的等待時間，並增加資源使用率。
+ 將逾時設定得太低，導致人為失敗。
+ 忽略模式以處理遠端呼叫 (例如斷路器和重試) 的逾時錯誤。
+ 不考慮監控服務呼叫錯誤率、延遲的服務水準目標，以及延遲離群值。這些指標可提供對積極或寬鬆逾時的洞見
**建立此最佳實務的優勢：**遠端呼叫逾時已設定，且系統設計為按正常程序處理逾時，以便在遠端呼叫回應異常緩慢，而逾時錯誤由服務用戶端正常處理時，可以保留資源。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
針對任何服務相依性呼叫和任何跨程序的呼叫，同時設定連線逾時和請求逾時。許多架構都提供內建的逾時功能，但請注意，對您的服務目標而言，有些架構具有無限或過高的預設值。太高的值會降低逾時的實用性，因為當用戶端等待逾時發生時，資源會持續耗用。太低的值可能會增加後端流量和延遲，原因是重試的請求過多。在某些情況下，這可能導致完全停機，原因是正在重試所有請求。
決定逾時策略時，請考量下列事項：
+ 由於請求的內容、目標服務受損或聯網分割失敗，處理請求的時間可能會比平常更長。
+ 內容異常昂貴的請求可能會耗用不必要的伺服器和用戶端資源。在此情況下，讓這些請求逾時而不重試，可以保留資源。服務也應透過限流和伺服器端逾時，來保護自己免受異常昂貴的內容影響。
+ 因服務受損而異常耗時的請求可能會逾時並重試。應考量請求和重試的服務成本，但如果原因是當地語系化的損害，則重試應該不會很昂貴，而且將可降低用戶端資源耗用量。逾時也可能會根據損害的性質釋出伺服器資源。
+ 因網路傳遞請求或回應失敗而需要長時間才能完成的請求，可能會逾時並重試。由於請求或回應未傳遞，因此無論逾時長度為何，結果都是失敗。在此情況下，逾時不會釋出伺服器資源，但會釋出用戶端資源並改善工作負載效能。
利用如重試和斷路器等建立良好的設計模式，優雅地處理逾時，並支援快速失敗的方法。[AWS SDKs](https://docs.aws.amazon.com/index.html#sdks) 和 [AWS CLI](https://aws.amazon.com/cli/) 允許設定連線和請求逾時，以及使用指數退避和抖動的重試。 [AWS Lambda](https://aws.amazon.com/lambda/)函數支援逾時組態，而使用 [AWS Step Functions](https://aws.amazon.com/step-functions/)，您可以建置低程式碼斷路器，以利用與服務 AWS 和 預先建置的整合SDKs。 [AWS App Mesh](https://aws.amazon.com/app-mesh/)Envoy 提供逾時和斷路器功能。
## 實作步驟
+ 設定遠端服務呼叫的逾時，並利用內建的語言逾時功能或開放原始碼逾時程式庫。
+ 當您的工作負載使用 呼叫 時 AWS SDK，請檢閱文件，了解語言特定的逾時組態。
+ [Python](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [Java](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [Go](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [Node.js](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ 在工作負載中使用 或 AWS CLI 命令時 AWS SDKs，請設定 `connectTimeoutInMillis`和 的 AWS [組態預設值](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html)，以設定預設逾時值`tlsNegotiationTimeoutInMillis`。
+ 將[命令列選項](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout`和 套用至 AWS 服務`cli-read-timeout`，以控制一次性 AWS CLI 命令。
+ 監控遠端服務呼叫是否有逾時，並對持續性錯誤設定警示，以便您可以主動處理錯誤案例。
+ 對呼叫錯誤率、延遲的服務層級目標和延遲異常值實作[CloudWatch 指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)和[CloudWatch 異常偵測](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)，以深入了解如何管理過度激進或寬鬆的逾時。
+ 設定 [Lambda 函數](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console)的逾時。
+ API Gateway 用戶端在處理逾時時必須實作自己的重試。API Gateway 支援下游[整合的 50 毫秒至 29 秒整合逾時](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table)，在整合請求逾時時不會重試。
+ 實作[斷路器](https://martinfowler.com/bliki/CircuitBreaker.html)模式，以避免在逾時發生時進行遠端呼叫。開啟線路以避免呼叫失敗，並在呼叫正常回應時關閉線路。
+ 對於基於容器的工作負載，請查看 [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) 功能以利用內建的逾時和斷路器。
+ 使用 AWS Step Functions 建置用於遠端服務呼叫的低程式碼斷路器，特別是在呼叫 AWS 原生SDKs和支援的 Step Functions 整合時，以簡化工作負載。
## 資源
**相關的最佳實務：**
+ [REL05-BP03 控制和限制重試呼叫](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 快速檢錯和限制佇列](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 透過您的系統監控請求的端對端追蹤](rel_monitor_aws_resources_end_to_end.md)
**相關文件：**
+ [AWS SDK：重試和逾時](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon 建置者資料中心：逾時、重試、退避與抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Amazon API Gateway 配額和重要備註 ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface：命令列選項](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x：設定API逾時 ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS 使用組態物件和組態參考的 Botocore ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [適用於 .NET 的 AWS SDK：重試與逾時](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda：設定 Lambda 函數選項](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**相關範例：**
+ [ 搭配 AWS Step Functions 和 Amazon DynamoDB 使用斷路器模式 ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler： CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**相關工具：**
+ [AWS SDKs ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 盡可能讓系統處於無狀態
系統不應要求狀態，或應該卸載狀態，以便在不同的用戶端請求之間，不依賴磁碟和記憶體中本機儲存的資料。這允許伺服器任意置換，而不會對可用性造成影響。
當使用者或服務與應用程式互動時，他們通常會執行形成工作階段的一系列互動。工作階段是使用者在使用應用程式時，在不同請求之間持續存在的唯一資料。無狀態應用程式是一種不需要了解先前互動，也不會儲存工作階段資訊的應用程式。
一旦設計為無狀態，您就可以使用無伺服器運算服務，例如 AWS Lambda 或 AWS Fargate。
除了伺服器替換之外，無狀態應用程式的另一個優點是他們可以水平擴展，因為任何可用的運算資源 （例如EC2執行個體和 AWS Lambda 函數） 都可以服務任何請求。
**建立此最佳實務的優勢：**設計為無狀態的系統更適合水平擴展，因此可以根據波動的流量和需求來新增或移除容量。其本質上也具有抵抗故障的能力，並在應用程式開發中提供靈活性和敏捷性。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
讓您的應用程式無狀態。無狀態應用程式支援水平擴展，並且可以容忍單個節點的失敗。分析並了解在架構中維持狀態的應用程式元件。這可協助您評估轉換為無狀態設計的潛在影響。無狀態架構會分離使用者資料並卸載工作階段資料。這提供了獨立擴展每個元件的彈性，以滿足不同的工作負載需求，並最佳化資源使用率。
### 實作步驟
+ 識別並了解應用程式中的有狀態元件。
+ 透過將使用者資料與核心應用程式邏輯進行分離和管理來解耦資料。
+ [Amazon Cognito](https://aws.amazon.com/cognito/) 可以使用[身分池](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html)、[使用者集區](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html)和 [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html) 等功能，將使用者資料與應用程式的程式碼分離。
+ 可以將密碼儲存在安全的集中位置，使用 [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) 來分離使用者資料。這意味著應用程式的程式碼不需要存儲密碼，這使得它更安全。
+ 請考慮使用 [Amazon S3](https://aws.amazon.com/s3/) 來存放大型非結構化資料，例如影像和文件。應用程式可以在需要時擷取此資料，而無需將其存儲在記憶體中。
+ 使用 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 來存放使用者設定檔等資訊。應用程式可以近乎即時的速度查詢這些資料。
+ 將工作階段資料卸載至資料庫、快取或外部檔案。
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/)、Amazon DynamoDB 、[Amazon Elastic File System](https://aws.amazon.com/efs/) （Amazon EFS） 和 [Amazon MemoryDB](https://aws.amazon.com/memorydb/) 是可用來卸載工作階段資料 AWS 的服務範例。
+ 在確定需要使用所選儲存解決方案維持哪些狀態和使用者資料之後，設計一個無狀態架構。
## 資源
**相關的最佳實務：**
+ [REL11-BP03 在所有圖層上自動復原](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**相關文件：**
+ [Amazon 建置者資料中心：避免分散式系統的備用](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon 建置者資料中心：避免無法逾越的佇列待辦項目](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon 建置者資料中心：快取挑戰和策略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [上的無狀態 Web 層最佳實務 AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 實作緊急槓桿
緊急控制桿是可緩解工作負載所受之可用性影響的快速程序。
緊急控制桿的運作方法是使用已知且經過測試的機制來停用、限流或變更元件或相依性的行為。這可以減輕因需求意外增加導致資源耗盡所造成的工作負載受損，並降低工作負載內非關鍵元件的故障影響。
**預期成果：**透過實作緊急控制桿，可以建立已知的良好流程，以維持工作負載中關鍵元件的可用性。在啟用緊急控制桿期間，工作負載應該會適度降級，並繼續執行其業務關鍵功能。如需優雅降級的詳細資訊，請參閱 [REL05-BP01 實作優雅降級，將適用的硬相依性轉換為軟相依性 ](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)。
**常見的反模式：**
+ 非關鍵相依性失敗會影響核心工作負載的可用性。
+ 未在非關鍵元件受損期間測試或驗證關鍵元件的行為。
+ 沒有為啟用或停用緊急控制桿定義明確且決定性的準則。
**建立此最佳實務的優勢：**實作緊急控制桿可透過為解析程式提供已確立的程序來應對意外的需求峰值或非關鍵相依性失敗，從而提高工作負載中關鍵元件的可用性。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
+ 識別工作負載中的關鍵元件。
+ 設計和建構工作負載中的關鍵元件，以承受非關鍵元件的故障。
+ 進行測試以驗證非關鍵元件失敗期間您關鍵元件的行為。
+ 定義和監控相關指標或觸發器以啟動緊急控制桿程序。
+ 定義構成緊急控制桿的程序 (手動或自動)。
### 實作步驟
+ 識別工作負載中的業務關鍵元件。
+ 工作負載中的每個技術元件應對應到其相關業務功能，並將其排名為關鍵或非關鍵。如需 Amazon 關鍵和非關鍵功能的範例，請參閱 [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)。
+ 這同時是技術和業務方面的決策，並且會因組織和工作負載而異。
+ 設計和建構工作負載中的關鍵元件，以承受非關鍵元件的故障。
+ 在相依性分析期間，請考慮所有潛在的故障模式，並驗證您的緊急控制桿機制能為下游元件提供關鍵功能。
+ 進行測試以驗證緊急控制桿啟動期間您關鍵元件的行為。
+ 避免雙模態行為。如需更多詳細資訊，請參閱 [REL11-BP05 使用靜態穩定性來防止雙模式行為 ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)。
+ 定義、監控和警示相關指標，以啟動緊急控制桿程序。
+ 尋找適合監控的指標取決於您的工作負載。一些範例指標是延遲或失敗的相依性請求次數。
+ 定義構成緊急控制桿的程序 (手動或自動)。
+ 這可能包括諸如[降載](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)、[限流請求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)或實作[適度降級](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)等機制。
## 資源
**相關的最佳實務：**
+ [REL05-BP01 實作優雅降級，將適用的硬相依性轉換為軟相依性](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 節流請求](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 使用靜態穩定性來防止雙模式行為](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**相關文件：**
+ [自動化安全、無人為介入的部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [任何一天都可能是黃金日：Amazon.com 搜尋功能如何使用混沌工程每秒處理 84K 以上的請求](https://community.aws/posts/how-search-uses-chaos-engineering)
**相關影片：**
+ [AWS re：Invent 2020：透過不可變性的可靠性、一致性和信心](https://www.youtube.com/watch?v=jUSYnRztttY)