共用方式為

ACS 重試方針

  • 發行項

更新日期：2015 年 7 月 6 日

適用對象：Azure

Microsoft Azure Active Directory 存取控制 (也稱為 存取控制 Service 或 ACS) 支援數個不同的權杖發行和管理端點，用戶端可以傳送權杖要求。 本主題定義當權杖要求失敗時實作重試邏輯的指導方針。

錯誤處理案例

傳回 HTTP 500 系列錯誤碼的權杖要求失敗通常可回應重試。 在某些情況下，用戶端是對 ACS 提出自動化要求的應用程式或服務。 在其他案例中，例如使用 WS-同盟通訊協定的 Web 型同盟，用戶端是網頁瀏覽器，使用者必須手動重試作業。 本主題涵蓋用戶端是應用程式或服務時的錯誤處理案例。

這些案例包括：

重試指導方針

下列指導方針說明如何在錯誤處理案例中實作重試邏輯。

指導方針 #1：根據 HTTP 500 系列錯誤回應實作重試邏輯

當 ACS 傳回 HTTP 500 系列錯誤時，強烈建議使用重試邏輯。 下列清單包含一般 HTTP 500 系列錯誤的範例。

  • HTTP 錯誤 500 - 內部伺服器錯誤

  • HTTP 錯誤 502 - 錯誤的閘道

  • HTTP 錯誤 503 - 服務無法使用

  • HTTP 錯誤 504 – 閘道逾時

雖然可以在重試邏輯中列舉個別的 HTTP 代碼，但只要傳回任何 HTTP 500 系列錯誤，就足夠叫用重試邏輯。

重試邏輯應該由 HTTP 錯誤碼觸發，例如 HTTP 504 (外部伺服器逾時) ，而不是由 ACS 錯誤碼觸發，例如 ACS90005。 ACS 錯誤碼可供參考，而且可能隨時變更。

通常，傳回 HTTP 400 系列錯誤碼時不建議使用重試邏輯。 來自 ACS 的 400 系列 HTTP 錯誤回應碼表示要求無效，而且需要修訂。 例外的是錯誤碼 429 (「太多要求」)，表示命名空間已有一段很長時間超出權杖要求率限制。 對於 429 錯誤，以倒數計時器重試可以消除當前的權杖要求積存，直到系統管理員有空檢閱並修正命名空間工作量分配為止。 如需詳細資訊，請參閱 ACS 服務限制。

指導方針 #2：重試應該使用退場計時器進行最佳流程式控制制

當用戶端收到 HTTP 500 系列錯誤時，用戶端應該等待一段指定的時間再重試要求。 為了獲得最佳結果，建議對每個後續的重試增加此期間。 這個方法可讓您快速地解決暫時性錯誤，同時最佳化需要較長時間才能解決的暫時性網路或伺服器問題的要求率。

例如，使用指數型倒數計時器，其中，重試會隨著每個執行個體以指數方式增加，例如重試 1：1 秒，重試 2：2 秒、重試 3：4 秒等等。

根據您的使用者經驗需求調整重試次數和每次重試之間的時間。 不過，我們建議在五分鐘的時段中最多五個重試。 逾時所造成的失敗需要較長時間才能解決。

指導方針 #3：嘗試建立或刪除該專案之前，請先確認該專案不存在

使用 ACS 管理服務執行建立或刪除作業時，例如建立新的信賴憑證者應用程式或刪除規則，重試邏輯應該在執行作業之前查詢專案是否存在。在某些情況下，例如傳遞伺服器回應時發生的暫時性網路失敗，即使用戶端收到錯誤回應，建立或刪除作業仍可能會成功。

如果未檢查項目是否存在就重試建立作業，則可能會建立重複的項目。 此外，如果項目必須是唯一的，系統可能會傳回 HTTP 400 錯誤。

如果未檢查項目是否存在就重試刪除作業，則系統找不到項目時可能會傳回 HTTP 400 錯誤。

另請參閱

概念

ACS 錯誤碼
ACS 服務限制
ACS 管理服務
如何：透過 OAuth WRAP 通訊協定向 ACS 要求權杖
程式碼範例：OAuth 2.0 憑證驗證
ACS 指導方針索引