在上一篇中，我们学习了如何使用 VirtualService 控制流量的流向。但服务网格的价值远不止于此，它还提供了强大的网络弹性（Resilience） 能力。当服务间调用出现延迟或失败时，Istio 可以自动执行超时、重试、熔断等策略，防止故障在系统中蔓延。这些策略主要通过在 DestinationRule（目标规则） 中配置 trafficPolicy 来实现。本文将深入讲解 DestinationRule 的配置，并通过实战演练，带你掌握如何为服务添加超时、重试、熔断和故障注入能力。
一、DestinationRule 的核心作用
DestinationRule 定义了在路由发生后，发往目标服务的流量策略。它主要负责配置“流量到达后如何处理”，其核心功能包括：
负载均衡策略：指定使用轮询（Round Robin）、最少请求（Least Request）等算法。
连接池管理：限制与目标服务的最大连接数、请求数等。
异常点检测（熔断） ：自动检测并隔离不健康的主机实例。
TLS 设置：配置服务间通信的 mTLS 模式。
二、定义服务子集（Subset）：版本管理的基础
在配置流量策略前，我们通常需要在 DestinationRule 中定义服务的“子集”（Subset），以区分不同的版本。VirtualService 正是通过引用这些 Subset 来实现精准路由的。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: my–service
spec:
host: my–service
subsets:
– name: v1
labels:
version: v1
– name: v2
labels:
version: v2
trafficPolicy:
# 全局策略…
subsets 字段下的 name 是子集的标识符，labels 用于选择具有对应标签的 Pod。
三、配置负载均衡与连接池
3.1 负载均衡策略
DestinationRule 支持多种负载均衡算法：
示例：将订单服务（order-service）的负载均衡策略改为“最少请求”
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order–service
spec:
host: order–service
trafficPolicy:
loadBalancer:
simple: LEAST_REQUEST
3.2 连接池管理（Connection Pool）
连接池配置可以限制服务与上游目标之间建立的连接数，防止服务被突发流量压垮。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order–service
spec:
host: order–service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100 # 最大连接数
connectTimeout: 30ms # 连接超时时间
http:
http1MaxPendingRequests: 10 # HTTP/1.1 最大待处理请求数
http2MaxRequests: 1000 # HTTP/2 最大并发请求数
maxRetries: 3 # 最大重试次数
四、熔断与异常点检测（Outlier Detection）
熔断是微服务架构中防止“雪崩效应”的重要机制。Istio 的熔断通过异常点检测（Outlier Detection） 实现。它会持续观察服务实例的请求情况，一旦发现某个实例持续返回错误，就会将其从负载均衡池中驱逐（Ejection） 一段时间。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order–service
spec:
host: order–service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
outlierDetection:
consecutiveErrors: 5 # 连续错误次数阈值
interval: 10s # 检查间隔
baseEjectionTime: 30s # 基础驱逐时间
maxEjectionPercent: 50 # 最大驱逐比例
参数解读：
consecutiveErrors: 5：如果某个实例连续返回 5 次 5xx 错误，就会触发驱逐。
interval: 10s：每 10 秒进行一次异常检测扫描。
baseEjectionTime: 30s：被驱逐的实例至少 30 秒后才能重新回到负载均衡池。
maxEjectionPercent: 50：最多允许驱逐 50% 的实例，防止过度驱逐导致服务完全不可用。
五、在 VirtualService 中配置超时与重试
虽然超时和重试也可以在 DestinationRule 中配置，但更推荐在 VirtualService 中配置，因为它属于路由逻辑的一部分。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order–service
spec:
hosts:
– order–service
http:
– route:
– destination:
host: order–service
subset: v1
weight: 100
timeout: 5s # 请求总超时时间设置为 5 秒
retries:
attempts: 3 # 最多重试 3 次
perTryTimeout: 2s # 每次重试的超时时间
retryOn: "5xx" # 仅在返回 5xx 错误时重试
解释：当请求 order-service 时，Istio 会在总耗时超过 5 秒时返回超时错误。如果请求失败（返回 5xx），它会最多重试 3 次，每次重试的超时时间为 2 秒。
六、故障注入（Fault Injection）：主动制造“混乱”
故障注入是测试系统弹性的重要手段，可以在不修改业务代码的情况下，人为地引入延迟或错误。这通常在 VirtualService 中配置。
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: my–service
spec:
hosts:
– my–service
http:
– match:
– headers:
end-user:
exact: "test-user"
fault:
delay:
percentage:
value: 50.0
fixedDelay: 5s
abort:
percentage:
value: 25.0
httpStatus: 500
route:
– destination:
host: my–service
subset: v2
规则解读：当 end-user: test-user 的请求访问 v2 版本时，有 50% 的概率会引入 5 秒的延迟，有 25% 的概率会直接返回 HTTP 500 错误。
七、小结
DestinationRule 是 Istio 流量管理的“执行者”，定义了“流量到达后如何处理”的策略。
它的核心配置包括 负载均衡、连接池管理 和 异常点检测（熔断） 。
VirtualService 则负责定义 超时、重试 和 故障注入 等路由层面的策略。
异常点检测 是实现服务熔断的关键机制，能自动隔离不健康的服务实例。
故障注入 是一种主动的混沌工程实践，用于验证系统的韧性。
