服务网格通过在基础设施层注入重试能力，无需修改业务代码即可实现可靠的通信重试。其核心机制依赖于 sidecar 代理和控制平面的协同工作。
重试策略由服务网格自动管理
在微服务架构中，服务间调用可能因网络抖动、瞬时故障或依赖服务短暂不可用而失败。服务网格将重试逻辑从应用代码中剥离，交由 sidecar 代理（如 Envoy）统一处理。每次请求经过本地代理时，代理会根据预设规则判断是否需要重试。
控制平面（如 Istio 的 Pilot）负责下发重试配置，确保策略在整个网格中一致生效。开发者只需在配置中声明“什么条件下重试”、“最多几次”，实际执行由数据面完成。
基于 HTTP 状态码和异常类型的条件重试
服务网格支持按响应状态码决定是否触发重试，例如仅对 5xx 或网关超时（504）进行重试。这种方式避免对客户端错误（如 404）无效重试。
可配置重试针对特定错误类型，比如连接拒绝、超时或 TLS 握手失败 支持 gRPC 状态码匹配，适用于非 HTTP 协议场景 允许设置重试条件表达式，实现细粒度控制可调节的重试参数与退避机制
为防止雪崩效应，服务网格提供多种参数来优化重试行为：
最大重试次数：限制尝试总次数，避免无限循环 重试超时时间：每次重试请求必须在此时间内完成，否则视为失败 基数退避（Jitter）：在固定间隔上增加随机延迟，分散重试洪峰 全局限流配合：结合熔断和限流策略，保护后端服务不被压垮通过声明式配置启用重试
以 Istio 为例，使用 VirtualService 可定义路由级别的重试策略：
apiVersion: networking.istio.io/v1beta1kind: VirtualService
metadata:
name: product-retry-policy
spec:
hosts:
- product-service
http:
- route:
- destination:
host: product-service
retries:
attempts: 3
perTryTimeout: 2s
retryOn: gateway-error,connect-failure,refused-stream
该配置表示当发生网关错误或连接失败时，最多重试两次（共三次请求），每次尝试最长等待 2 秒。
基本上就这些。服务网格让重试变得更安全、更可控，同时减轻了开发者的负担。关键在于合理设置阈值，避免加重系统压力。
