Service Mesh 超时重试救服务也可能放大故障一、重试不是免费的稳定性Service Mesh 让超时、重试、熔断、限流变成配置项看起来很优雅。但重试不是免费的稳定性。一次请求失败后自动重试短期可能救回偶发错误如果下游已经过载重试会把更多流量打过去故障被放大。很多线上事故不是没有重试而是重试太激进。调用方、网格代理、SDK、业务代码都在重试最终一个用户请求变成多次下游压力。稳定性配置如果不统一救火工具会变成加压器。二、超时和重试要一起设计只配置重试不配置超时很容易拖垮调用链。flowchart TD A[上游请求] -- B[Mesh 代理] B -- C[调用下游] C -- D{是否超时或失败} D --|是| E[按策略重试] E -- C D --|否| F[返回结果] E -- G{达到重试上限} G --|是| H[失败返回]整体超时时间要小于用户可接受时间。每次重试的超时、重试次数和退避策略都要在总预算里。三、策略要按接口类型区分下面是一个简化配置思路。retries: attempts: 2 perTryTimeout: 300ms retryOn: gateway-error,connect-failure,refused-stream timeout: 900ms读接口、幂等接口、短耗时接口更适合重试。写接口、支付接口、外部副作用接口必须非常谨慎。不能因为 Mesh 支持配置就把所有接口套同一个模板。四、重试要配合熔断和限流如果下游已经过载上游继续重试只会让队列更长。熔断可以快速失败限流可以保护下游重试则只处理短暂失败。三者要组合使用。还要观察重试率。成功率稳定但重试率升高是早期风险信号。用户还没感知失败系统内部已经开始用额外成本维持表面稳定。这个阶段不处理后面很可能直接雪崩。重试预算也要跨层统一。业务 SDK 重试两次Mesh 再重试两次上游网关再重试一次乘起来就很吓人。架构上要明确哪一层负责重试其他层尽量只做超时和失败透传。最后灰度上线策略要小流量验证。超时重试配置影响面很大一条规则可能改变整个服务拓扑的压力分布。先观察 P95、P99、错误率、重试率和下游 CPU再逐步放大。还要把超时预算从入口一路分配到下游。用户请求最多等 2 秒网关、BFF、核心服务、数据库和外部接口就不能各自设置 2 秒。上游超时早于下游超时才能避免无意义的后台工作继续消耗资源。幂等键是重试的底线。写请求如果必须重试就要让下游能识别重复请求返回同一个结果或安全拒绝。没有幂等保护的重试会把偶发网络抖动变成重复扣费、重复创建和重复通知。可观测性也要跟上。每次重试都应该打上 attempt、upstream、原因和耗时标签。否则看到一次成功响应时根本不知道背后已经重试了几轮。没有重试指标团队会错过故障前奏。最后重试策略要有禁用开关。发现下游异常时可以快速关闭某条路径的重试只保留短超时和失败返回。没有开关只能改配置发布会拖慢止损速度。还要把配置变更纳入审计。谁改了重试次数、超时时间、匹配路径和生效范围都应该能查到。网格配置一旦出错影响的不只是单个服务而是整条调用链的压力分布。故障演练也很必要。可以在测试环境模拟下游 500、慢响应、连接拒绝和部分超时观察重试是否符合预期。没演练过的策略上线后就是盲盒。五、总结Service Mesh 的超时和重试能提升稳定性也可能放大故障。重试必须受总超时、接口幂等性、熔断限流和跨层预算约束。配置越简单越要清楚它在故障时会制造多少额外流量。
