REL05-BP05 設定用戶端逾時
在連線和請求上妥善設定逾時、有系統地對其進行驗證，並且不要依賴預設值，因為它們不知道工作負載具體細節。
預期成果：用戶端逾時應考量與等待需要花費異常時間才能完成的請求相關的用戶端、伺服器和工作負載成本。由於無法知道任何逾時的確切原因，用戶端必須使用服務知識來找出對可能原因和適當逾時的期望
用戶端連線根據設定的值逾時。經歷逾時後，用戶端決定退回並重試，或開啟斷路器
常見的反模式：
-
不知道系統逾時或預設逾時。
-
不知道正常的請求完成時間。
-
不知道完成請求異常耗時的可能原因，或是與等待這些作業完成相關聯的用戶端、服務或工作負載效能成本。
-
不知道受損的網路只有在達到逾時後才會造成請求失敗的可能性，以及未採用較短逾時的用戶端和工作負載效能的成本。
-
不測試連線和請求的逾時情境。
-
將逾時設定得太高，這可能會導致較長的等待時間，並增加資源使用率。
-
將逾時設定得太低，導致人為失敗。
-
忽略模式以處理遠端呼叫 (例如斷路器和重試) 的逾時錯誤。
-
不考慮監控服務呼叫錯誤率、延遲的服務水準目標，以及延遲離群值。這些指標可提供對積極或寬鬆逾時的洞見
建立此最佳實務的優勢：遠端呼叫逾時已設定，且系統設計為按正常程序處理逾時，以便在遠端呼叫回應異常緩慢，而逾時錯誤由服務用戶端正常處理時，可以保留資源。
未建立此最佳實務時的曝險等級：高
實作指引
針對任何服務相依性呼叫和任何跨程序的呼叫，同時設定連線逾時和請求逾時。許多架構都提供內建的逾時功能，但請注意，對您的服務目標而言，有些架構具有無限或過高的預設值。太高的值會降低逾時的實用性，因為當用戶端等待逾時發生時，資源會持續耗用。太低的值可能會增加後端流量和延遲，原因是重試的請求過多。在某些情況下，這可能導致完全停機，原因是正在重試所有請求。
決定逾時策略時，請考量下列事項：
-
由於請求的內容、目標服務受損或聯網分割失敗，處理請求的時間可能會比平常更長。
-
內容異常昂貴的請求可能會耗用不必要的伺服器和用戶端資源。在此情況下，讓這些請求逾時而不重試，可以保留資源。服務也應透過限流和伺服器端逾時，來保護自己免受異常昂貴的內容影響。
-
因服務受損而異常耗時的請求可能會逾時並重試。應考量請求和重試的服務成本，但如果原因是當地語系化的損害，則重試應該不會很昂貴，而且將可降低用戶端資源耗用量。逾時也可能會根據損害的性質釋出伺服器資源。
-
因網路傳遞請求或回應失敗而需要長時間才能完成的請求，可能會逾時並重試。由於請求或回應未傳遞，因此無論逾時長度為何，結果都是失敗。在此情況下，逾時不會釋出伺服器資源，但會釋出用戶端資源並改善工作負載效能。
利用完善的設計模式 (例如重試和斷路器)，按正常程序處理逾時並支援快速檢錯方法。AWSSDK 和 AWS CLI
實作步驟
-
設定遠端服務呼叫的逾時，並利用內建的語言逾時功能或開放原始碼逾時程式庫。
-
當您的工作負載使用 AWS SDK 進行呼叫時，請檢閱文件以了解語言特定的逾時組態。
-
在工作負載中使用 AWS SDK 或 AWS CLI 命令時，請設定預設逾時值，方法是設定
connectTimeoutInMillis和tlsNegotiationTimeoutInMillis的 AWS 組態預設值。 -
套用命令列選項
cli-connect-timeout和cli-read-timeout來控制 AWS 服務的一次性 AWS CLI 命令。 -
監控遠端服務呼叫是否有逾時，並對持續性錯誤設定警示，以便您可以主動處理錯誤案例。
-
對於呼叫錯誤率、延遲的服務水準目標以及延遲離群值實作 CloudWatch Metrics 和 CloudWatch 異常偵測，讓您能夠深入了解如何管理過於激進或寬鬆的逾時。
-
設定 Lambda 函數的逾時。
-
API Gateway 用戶端在處理逾時期間必須實作本身的重試。API Gateway 對於下游整合支援 50 毫秒到 29 秒的整合逾時，而且在整合請求逾時後不會重試。
-
實作斷路器
模式，以避免在逾時發生時進行遠端呼叫。開啟線路以避免呼叫失敗，並在呼叫正常回應時關閉線路。 -
對於基於容器的工作負載，請查看 App Mesh Envoy 功能以利用內建的逾時和斷路器。
-
使用 AWS Step Functions 為遠端服務呼叫建置低程式碼斷路器，尤其是在呼叫 AWS 原生 SDK 和支援的 Step Functions 整合以簡化工作負載的情況下。
資源
相關的最佳實務：
相關文件：
相關範例：
相關工具：
