通过

ACS 重试指导原则

  • 项目

更新时间：2015 年 7 月 6 日

适用于：Azure

Microsoft Azure Active Directory 访问控制 (也称为访问控制服务或 ACS) 支持客户端可以向其发送令牌请求的许多不同的令牌颁发和管理终结点。 本主题定义的准则用于实现在令牌请求失败时的重试逻辑。

错误处理方案

返回 HTTP 500 系列错误代码的令牌请求失败通常对重试做出响应。 在某些情况下，客户端是向 ACS 发出自动请求的应用程序或服务。 在其他方案（如使用 WS 联合身份验证协议的基于 ?eb 的联合）中，客户端是 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 准则索引