如何通过Polly .NET正确实现Retry+Timeout+CircuitBreaker弹性策略

问题1解答 #

最内层（最靠近httpClient.SendAsync的位置）应该放置**Circuit Breaker（熔断器）**策略。
两种放置位置的行为差异如下：

• 熔断器放在TimeoutPolicy内层：
  所有实际发起的HTTP请求（包括每次重试发起的请求）都会先经过熔断器状态检查，熔断器处于打开状态时会直接拒绝请求，不会真正发送流量到下游。且只有实际请求产生的失败（服务端错误、超时异常）才会被计入熔断器的失败统计，完全符合你「连续N+1次重试失败后打开熔断器」的预期目标。
• 熔断器放在TimeoutPolicy外层：
  超时逻辑、重试逻辑都会被包在熔断器的统计范围内，除了实际请求的失败，重试等待过程的异常、外层调用取消的异常都可能被误统计进熔断器的失败计数，甚至可能出现还没走完重试逻辑就触发熔断的情况，不符合你的业务要求。

问题2解答 #

不需要专门给CircuitBreaker配置CancellationToken。
熔断器本身只有状态判断逻辑，没有耗时等待的操作，状态不允许的情况下会直接抛出BrokenCircuitException，无需取消逻辑。你只需要将CancellationToken传递给超时策略、最内层的HTTP请求方法即可，除非有特殊的半开状态测试请求取消需求，常规场景不需要额外配置。

问题3解答 #

除可读性外，Policy Wraps还有以下弹性架构层面的收益：

• 策略可复用：同一个Wrap可以注册到DI容器中，供所有HttpClient、不同的下游服务调用场景共用，不需要每次都编写重复的嵌套逻辑，避免人为写错嵌套顺序的问题。
• 执行顺序强管控：Polly Wrap有明确的「外层到内层」执行规则，比如PolicyWrap.Wrap(重试策略, 超时策略, 熔断器策略)就会严格按照重试→超时→熔断器→请求的顺序执行，团队协作时可以统一规范策略执行顺序，不会出现手动嵌套的顺序混乱问题。
• 上下文统一传递：Wrap包含的所有策略会共享同一个Polly Context对象，你可以在上下文中存储请求ID、链路追踪标识、自定义业务参数，所有策略都能直接读取，比如重试日志、熔断告警都可以复用同一个请求标识，无需手动传递参数。
• 统一运维埋点：可以给Wrap统一配置全局的异常拦截、可观测性埋点，统一统计所有经过该Wrap的请求的重试次数、熔断触发次数、超时次数，不需要给每个单独策略重复编写埋点代码。

补充代码小问题：

1. 变量TIME_TO_WAIT_BETWEEN_RETRIES赋值100秒不符合常规重试间隔的设计，大概率是笔误；
2. HttpClient初始化时用到的MAXSecondsHTTPTimeout没有定义，和你声明的MAX_TIME_FOR_HTTP_REQUEST常量名不统一，会编译报错；
3. return = await httpClient.SendAsync多写了等号，要删掉。

内容的提问来源于stack exchange，提问作者diegobarriosdev