istio熔断本质是通过destinationrule配置connectionpool与outlierdetection，由envoy自动限连、驱逐异常实例防雪崩；需设tcp.maxconnections=2048、http1maxpendingrequests=1024、maxrequestsperconnection=128、consecutive5xxerrors=3、interval=10s、baseejectiontime=30s、maxejectionpercent=50。
在Istio中为后端服务配置熔断器，本质是通过DestinationRule定义连接池容量与异常检测策略，让Envoy Sidecar自动拦截异常实例、限制并发连接、防止级联故障——不配熔断的后端，在大促或依赖抖动时，3秒内就可能被拖垮。
创建带熔断能力的DestinationRule
执行以下YAML创建名为order-service-resilience的DestinationRule，作用于order-service.prod.svc.cluster.local：
kubectl apply -f destinationrule-cb.yaml
该文件必须包含trafficPolicy.connectionPool和outlierDetection两个关键区块，缺一不可；否则Envoy不会启用熔断逻辑。
设置连接池上限防打穿
在trafficPolicy.connectionPool下配置TCP与HTTP层连接约束：
tcp.maxConnections: 设为【2048】——这是单个Sidecar到目标服务所有Pod实例的总连接上限，超过则新请求直接失败（503），避免耗尽上游资源。
http.http1MaxPendingRequests: 设为1024——当所有连接繁忙时，最多排队1024个请求；设太高会导致请求在队列里积压数秒才超时，用户体验断崖式下跌。
maxRequestsPerConnection: 必须显式设为128——强制复用长连接，防止高频短连接触发TCP TIME_WAIT风暴，引发“connection refused”错误。
配置异常检测与驱逐策略
outlierDetection控制何时将故障实例从负载均衡池中剔除：
consecutive5xxErrors: 设为3——连续3次收到5xx响应即判定为异常，不能设为1，否则网络瞬时抖动就会误驱逐健康实例。
interval: 设为10s——每10秒扫描一次各实例的错误计数，太短会放大噪声，太长则故障发现滞后。
baseEjectionTime: 设为30s——首次驱逐持续30秒，后续每次驱逐时间按指数退避增长（如第二次60s、第三次120s），防止刚恢复又立刻被踢出。
maxEjectionPercent: 严格限制为【50】——即使100%实例都报错，也最多驱逐一半，保留底线服务能力，避免全量隔离导致服务彻底不可用。
验证熔断是否生效
方法一：手动触发异常
向order-service发起连续请求，用curl -I http://order-service/health反复调用，人为制造5xx响应（如临时注入返回500的mock）。
方法二：查看驱逐日志
执行kubectl logs -n istio-system deploy/istiod | grep "eject"，若看到类似"ejected host order-service-xxx:8080 due to consecutive 5xx"的日志，说明驱逐已触发。
方法三：检查Endpoint状态
运行kubectl get endpoints order-service -n prod -o wide，观察SUBSETS.ADDRESSES字段是否减少——被驱逐的Pod IP会从列表中消失，直到baseEjectionTime到期后自动回归。
