- 立即重试不要超过一次 。
- 【有“韧性”才能更“任性”| 微软云原生韧性设计指南】避免使用常规重试间隔 ， 特别是当访问Azure中的服务和资源时 ， 有大量的重试尝试时 。 在这种情况下 ， 最优的方法是采用具有断路能力的指数后退策略 。
- 防止同一客户端的多个实例或不同客户端的多个实例在同一时间发送重试 。 如果可能发生这种情况 ， 请在重试间隔中引入随机化 。
确保在尽可能广泛的情况下全面测试重试策略实现 ， 特别是当应用程序和它使用的目标资源或服务都处于极端负载下时 。 要在测试期间检查行为 ， 可以：
- 将瞬态和非瞬态故障注入服务 。 例如 ， 发送无效请求或添加检测测试请求的代码 ， 并使用不同类型的错误进行响应 。
- 创建资源或服务的模拟 ， 该模拟返回真实服务可能返回的一系列错误 。 确保覆盖了重试策略旨在检测的所有类型的错误 。
- 如果是自己创建和部署的自定义服务 ， 则通过临时禁用或重载该服务来强制发生瞬态错误(当然 ， 我们不应该尝试重载Azure中的任何共享资源或共享服务) 。
- 对于基于HTTP的API ， 可以考虑在自动化测试中使用FiddlerCore库 ， 通过添加额外的往返时间或更改响应（如HTTP状态代码、头、正文或其他因素）来更改HTTP请求的结果 。 这样就可以对故障条件的子集进行确定性测试 ， 无论是瞬时故障还是其他类型的故障 。
- 执行高负载系数和并发测试 ， 以确保重试机制和策略在这些条件下正确工作 ， 并且不会对客户机的操作产生不利影响或导致请求之间的交叉污染 。
- 重试策略是重试策略的所有元素的组合 。 它定义了确定故障是否可能是暂时的检测机制、要使用的间隔类型（如常规、指数后退和随机化）、实际间隔值和重试次数 。
- 即使是最简单的应用程序 ， 也必须在许多地方实现重试 ， 更复杂的应用程序的每一层都必须实现重试 。 考虑使用一个中心点来存储所有策略 ， 而不是在多个位置硬编码每个策略的元素 。 例如 ， 将间隔和重试计数等值存储在应用程序配置文件中 ， 在运行时读取它们 ， 并以编程方式构建重试策略 。 这使得管理设置、修改和微调值以响应不断变化的需求和场景变得更加容易 。 但是 ， 要设计系统来存储这些值 ， 而不是每次都重新读取配置文件 ， 并确保在无法从配置中获得这些值时使用合适的默认值 。
- 在Azure云原生应用程序中 ， 考虑将用于构建运行时重试策略的值存储在服务配置文件中 ， 这样就可以在不重启应用程序的情况下更改它们 。
- 利用客户端API中提供的内置或默认重试策略 ， 但只在它们适合的场景使用 。 这些策略通常是通用的 。 在某些场景中 ， 它们可能是所有必需的 ， 但在其他场景中 ， 它们可能不会提供所有选项来满足特定需求 。 通过测试确定最合适的值 ， 我们必须了解设置将如何影响应用程序 。
- 作为重试策略的一部分 ， 包括异常处理和记录重试尝试时的其他检测 。 虽然偶尔出现短暂的故障和重试是可以预期的 ， 并且并不表明有问题 ， 但定期的和不断增加的重试次数通常是一个可能导致故障的问题的指示器 ， 或者当前正在降低应用程序的性能和可用性 。
- 将瞬态故障记录为警告项而不是错误项 ， 以便监控系统不会将它们检测为可能触发错误警报的应用程序错误 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。