当前位置：首页 > news >正文

istio流量治理——重试

news 来源：原创 2025/8/22 15:57:31

Istio 的重试功能的底层原理主要依赖于其数据平面组件 Envoy 代理（Sidecar 或 Gateway）的实现。Envoy 是一个高性能的代理服务器，负责处理所有流入和流出的流量，并在 Istio 的服务网格中执行流量管理策略，包括重试逻辑。以下是对重试底层原理的详细解析，涵盖其工作机制、核心组件和实现细节。

注意！！！当服务A配置了重试后，其他注入了sidecar的服务在访问服务A的时候，若A发生了5xx等错误，则会触发重试，必须是已注入了sidecar的服务调用才会触发。

1. Envoy 的角色

Istio 通过将 Envoy 注入到每个 Pod 作为 Sidecar 代理，或者部署为 Ingress/Egress Gateway，来拦截和控制服务之间的网络流量。重试功能是 Envoy 的路由和故障处理能力的一部分，由 Istio 的控制平面（例如 Pilot）通过配置下发给 Envoy。

配置来源：Istio 的 VirtualService 和 DestinationRule 定义了重试策略（例如 attempts、retryOn、perTryTimeout），这些配置被转换为 Envoy 的内部数据结构（xDS 协议）。
执行主体：Envoy 在收到这些配置后，负责在流量转发过程中执行重试逻辑。

2. 重试的核心原理

Envoy 的重试机制是在其 HTTP 路由器过滤器（HTTP Router Filter） 和 故障注入/重试策略 中实现的。以下是底层工作原理的逐步分解：

(1) 请求拦截与路由

当客户端发起请求时，请求首先到达源 Pod 的 Envoy Sidecar。
Envoy 根据路由规则（基于 VirtualService 配置）将请求转发到目标服务（例如 gindemo.demo-bookinfo.svc.cluster.local）。
在转发之前，Envoy 会检查是否有重试策略绑定到该路由。

(2) 重试策略的解析

重试触发条件（retryOn）：Envoy 检查配置中的 retryOn 字段，例如 5xx、connect-failure 等。这些条件被映射为具体的错误类型：
- 5xx：HTTP 响应状态码 500-599。
- connect-failure：TCP 连接失败。
- reset：连接被上游服务重置。
- gateway-error：网关相关的错误（如 502、503、504）。
重试次数（attempts）：Envoy 从配置中读取最大重试次数（例如 attempts: 10），并将其作为计数器。
每次重试超时（perTryTimeout）：为每次尝试设置独立的超时时间，避免单次重试耗时过长。

(3) 请求执行与失败检测

Envoy 将请求发送到上游服务（Upstream），并等待响应。
如果上游服务返回符合 retryOn 条件的错误（例如 500 错误），或者发生网络错误（例如连接超时），Envoy 标记该请求为“失败”。

(4) 重试逻辑的执行

计数器检查：Envoy 检查当前已尝试的次数是否小于配置的 attempts 值。
延迟（如果有）：如果配置了重试间隔（例如 Istio 支持通过 retryBudget 或自定义策略间接控制），Envoy 会在重试前等待一段时间。默认情况下，Envoy 不引入额外延迟，直接重试。
重新发送请求：Envoy 构造一个新的请求（通常与原始请求相同，除非配置了特殊头或参数），并再次发送到上游服务。
负载均衡：如果上游有多个实例（由 DestinationRule 定义的 subset 或负载均衡策略），Envoy 可能在每次重试时选择不同的实例（取决于负载均衡策略，如 Round Robin）。

(5) 结果返回

如果某次重试成功（例如返回 200 OK），Envoy 将响应返回给客户端，终止重试流程。
如果所有重试次数耗尽仍未成功，Envoy 将最后一次失败的响应（或错误信息）返回给客户端。

3. 底层实现细节

Envoy 的重试功能是在其 C++ 代码库中实现的，主要涉及以下模块：

(1) HTTP 路由器过滤器

文件：source/extensions/filters/http/router/router.cc
功能：解析路由配置，执行重试策略。
逻辑：当上游返回错误时，过滤器检查重试策略（RetryPolicy），决定是否触发重试。

(2) 重试策略（RetryPolicy）

数据结构：Envoy 使用 envoy.config.route.v3.RetryPolicy（通过 xDS 协议接收）存储重试配置。
参数：
- retry_on：触发条件（例如 5xx）。
- num_retries：重试次数。
- per_try_timeout：单次重试超时。
实现：过滤器根据 RetryPolicy 判断是否需要重试，并更新内部状态（如重试计数器）。

(3) Upstream 管理

文件：source/common/upstream/upstream_impl.cc
功能：管理与上游服务的连接池和负载均衡。
重试时，Envoy 从连接池中选择新的上游实例（如果可用），确保重试不会始终打到同一个失败节点。

(4) 时间管理

Envoy 使用事件循环（基于 libevent）来调度重试请求。如果配置了 perTryTimeout，会在超时后取消当前尝试并进入下一次重试。

4. 数据流示例

假设你的配置是 attempts: 10, retryOn: 5xx，服务返回 500 错误：

客户端发送请求 → 源 Envoy。
源 Envoy 转发请求到目标服务 → 返回 500。
Envoy 检查 retryOn: 5xx，匹配条件，计数器从 0 增至 1。
Envoy 重发请求 → 返回 500，计数器增至 2。
重复此过程，直到：
- 上游返回非 5xx 响应（成功，结束）。
- 重试 10 次仍失败，返回最后一次响应。

5. 与你的问题关联

在你的场景中（即使不设置 retries，仍重试 3 次），底层原理提示可能存在以下情况：

Envoy 默认配置：某些全局配置（通过 EnvoyFilter 或 Istio 默认设置）可能启用了重试。
Gateway 层重试：Ingress Gateway 的 Envoy 实例可能独立执行了重试逻辑，未受 VirtualService 控制。
日志显示限制：Envoy 可能执行了更多重试，但日志级别不足以显示完整过程。

6. 扩展与限制

幂等性：Envoy 默认假设请求是幂等的，重试不会检查请求的具体语义（如 POST 是否安全）。
性能开销：重试会增加网络和上游服务的负载，尤其在高并发场景下。
超时协调：全局超时（如 timeout）必须大于 perTryTimeout × attempts，否则重试可能被截断。

总结

Istio 的重试功能底层由 Envoy 的 HTTP 路由器过滤器和重试策略实现，通过拦截请求、检测失败并重新发送来完成。它的核心是一个基于配置驱动的循环机制，依赖上游状态和负载均衡。