此页面有用吗?
您对此内容的反馈非常重要。 请告诉我们您的想法。
更多反馈?
1500 个剩余字符
导出 (0) 打印
全部展开

ACS 重试指导原则

发布时间: 2013年1月

更新时间: 2015年7月

应用到: Azure

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

返回 HTTP 500 系列错误代码的令牌请求失败通常对重试做出响应。在某些方案中,客户端是向 ACS 发出自动请求的应用程序或服务。在其他方案(如使用 WS 联合身份验证协议的基于 Web 的联合)中,客户端是 Web 浏览器,最终用户必须手动重试操作。本主题介绍客户端是应用程序或服务的错误处理方案。

这些方案包括:

以下准则说明了如何在错误处理方案中实现重试逻辑。

在 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 服务限制

收到 HTTP 500 系列错误时,客户端应等待指定的一段时间,然后再重试请求。为获得最佳结果,建议对于每次后续重试,增加此时间段的长度。使用此方法可优化需要较长时间解决的暂时性网络或服务器问题的请求速率,并可快速解决暂时性错误。

例如,使用指数退避计时器时,每个实例在重试之前的延迟以指数方式增加,例如,第 1 次重试:1 秒,第 2 次重试:2 秒,第 3 次重试:4 秒,依此类推。

根据用户体验需求调整重试次数和每次重试的间隔时间。但是,我们建议在五分钟的时间内最多重试五次。超时导致的失败需要较长的时间才能解决。

在使用 ACS 管理服务执行创建或删除操作(如创建新的信赖方应用程序或删除某个规则)时,重试逻辑应在执行操作之前查询该项目是否存在。在某些情况下(例如在传送服务器响应时出现暂时性网络故障),创建或删除操作甚至可以在客户端获得错误响应时成功执行。

如果在重试创建操作时没有检查该项目是否存在,则可能创建重复的项目。另外,如果该项目必须唯一,则系统可能会返回 HTTP 400 错误。

如果重试删除操作时没有检查该项目是否存在,则在找不到该项目时,系统可能会返回 HTTP 400 错误。

另请参阅

社区附加资源

添加
显示:
© 2015 Microsoft