弹性与熔断

分布式系统里，短暂故障若被 无限重试、同步阻塞 放大，会引发级联崩溃（见 rel-cascade）。熔断 在失败达阈值时 停止调用 或 隔离流量；弹性可在 应用库 与 服务网格 两层实现，需避免重复冲突。

学习目标

• 理解网格 outlier detection 与 Resilience4j 断路器的对应关系
• 知道连接池、并发限制在 DestinationRule 中的配置思路
• 决定「网格管什么、应用管什么」

应用层熔断回顾

sc-circuit-breaker 中 Resilience4j 三状态：

状态	行为
Closed	正常调用，统计失败
Open	直接 fallback
Half-Open	试探恢复

逻辑在 调用方 JVM 内，对 HTTP 客户端生效；每个语言栈各配一套。

网格层「熔断」

Istio 常用 异常实例摘除（outlier detection）：

trafficPolicy:
  outlierDetection:
    consecutive5xxErrors: 5
    interval: 30s
    baseEjectionTime: 30s
    maxEjectionPercent: 50

Sidecar 把连续 5xx 的 Pod 地址 临时移出负载均衡池——针对 实例级 故障，而非整个服务名 Open。

另有 连接池 / 并发限制：

connectionPool:
  tcp:
    maxConnections: 100
  http:
    http1MaxPendingRequests: 50
    maxRequestsPerConnection: 2

类似 舱壁（rel-circuit），防止单下游拖垮 Sidecar 连接。

两层如何分工

场景	建议
单 Pod 坏掉	网格 outlier detection 足够
下游全挂 / 业务需兜底 JSON	应用 fallback（Feign / WebClient）
gRPC deadline	客户端 deadline + 网格 timeout 对齐（grpc-error）
重试	只在一层配，避免网格 × 应用双重重试

迁移期常见坑：Feign 3 次重试 + VirtualService 3 次重试 = 最多 9 次，易触发 retry storm。

与超时、限流联动

• timeout：VirtualService / route 级（见 mesh-traffic）