Istio 流量治理实战：镜像、超时重试、熔断与限流，一次讲透

前言

本小节继续来描述istio对于流量的各种操作

流量镜像

对标nginx的mirror功能，复制一份流量到对应的地址去，通常用来做从线上环境引流至其他环境做测试或者分析

/* by 01130.hk - online tools website : 01130.hk/zh/allencrypt.html */ apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com http: - mirror: host: backend-service subset: v1 mirrorPercentage: value: 100 route: - destination: host: backend-service subset: v0

流量先到v0版本，istio-proxy复制一份流量到v1版本。如果不想1比1复刻，可以调整mirrorPercentage百分比功能

如果mirror host的目标不存在，怎么发现该错误及时调整host配置呢？

超时/重试

配置超时/重试的原因主要是为了解决：

• 调用外部网络的接口，很容易产生诸如502、504、499，甚至连接中断等问题，有了重试，可以尽可能的尝试再次发起，而不是直接报错
• 公用云网络抖动，导致客户端收到一堆5xx，从而引起客户产生不适
• 后端服务没有优雅更新，一旦发版，导致大量502，重试可以缓解502，避免告警风暴

/* by 01130.hk - online tools website : 01130.hk/zh/allencrypt.html */ apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: backend-retry spec: hosts: - backend-service http: - route: - destination: host: backend-service timeout: 1s retries: attempts: 3 # 最大重试次数 perTryTimeout: 1s # 每次尝试的超时 retryOn: # 触发重试的条件 - 5xx - gateway-error - connect-failure - refused-stream

有位老哥说了，如果一套qps很高的集群，一旦发生重试，那就意味着短时间之内上游服务的qps至少翻一倍（第一波请求不成功，很快第二波请求就要来了），那这时候上游服务就有被冲垮的风险

说的没错，重试是为了提高请求的成功率，但是不可避免增加系统负载，并且增加请求的响应时间，如果大量重试，那就会导致重试风暴，带来更大的问题

重试次数

为了避免重试风暴，在配置策略的时候应该考虑合理的重试次数

retries: attempts: 3 # 最大重试次数 perTryTimeout: 1s # 每次尝试的超时

重试3次，每次间隔1s，然后就应该报错，介入查看了

级联超时

超时时间逐层递减，前端超时 > 网关超时 > 服务超时
frontend: timeout: 5s
nginx-test: timeout: 3s
backend-service: timeout: 2s

退避策略

简而言之，就是重试失败之后不是马上重试，而是等一段时间再重试

• 固定退避（Fixed Backoff）：每次重试等待固定时间
  • attempt 1: 等待 100ms
  • attempt 2: 等待 100ms
  • attempt 3: 等待 100ms
• 线性退避（Linear Backoff）：等待时间线性增加
  • attempt 1: 等待 100ms
  • attempt 2: 等待 200ms
  • attempt 3: 等待 300ms
• 指数退避（Exponential Backoff）：等待时间按指数增加（乘以系数），最使用也最常用
  • attempt 1: 等待 100ms
  • attempt 2: 等待 200ms
  • attempt 3: 等待 400ms
  • attempt 4: 等待 800ms
  • attempt 5: 等待 1600ms
• 随机退避（Jitter/随机抖动）：在退避时间中加入随机性，打破同一时间重试，避免"惊群效应"
  • attempt 1: 等待 100ms ± 随机时间
  • attempt 2: 等待 200ms ± 随机时间

apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: backend-vs namespace: default spec: hosts: - backend-service - api.wilsontest.com http: - retries: attempts: 10 perTryTimeout: 1s retryOn: 5xx,connect-failure route: - destination: host: backend-service subset: v0

测试istio-proxy的策略

istio-proxy自带了指数退避与随机退避，初始25ms

为了探索istio-proxy是否带有指数退避与随机退避的特点，特意设置attempts: 10（日常用可以设置小一点，比如笔者通常设置为3）

设置后端报错代码，只要报错5xx即可，所以我直接将代码的关键字改错，应该会报语法错误或者方法找不到之类的

Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute result = method(*self.path_args, **self.path_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/test.py", line 9, in get self.writ(ret) ^^^^^^^^^ AttributeError: 'TestFlow' object has no attribute 'writ'

都准备好了，开始测试：

• curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test
• 查看日志，有11条日志，符合预期：第1次访问+attempts: 10

  [2026-02-05T06:51:41.322Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.332Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.369Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default [2026-02-05T06:51:41.441Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.463Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default [2026-02-05T06:51:41.480Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.660Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.787Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.804Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:41.978Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=1ms route=default [2026-02-05T06:51:42.116Z] "GET /test HTTP/1.1" 500 - upstream=10.244.0.73:10000 duration=2ms route=default

• 分析下时间

  序号	时间戳	与上一次间隔
  1	41.322	—
  2	41.332	+10ms
  3	41.369	+37ms
  4	41.441	+72ms
  5	41.463	+22ms
  6	41.480	+17ms
  7	41.660	+180ms
  8	41.787	+127ms
  9	41.804	+17ms
  10	41.978	+174ms
  11	42.116	+138ms

• 从日志看来确实满足了指数+随机，初始 backoff：~25ms、指数增长、加入 jitter（随机抖动）
  • 10ms → 37ms → 72ms → 180ms → 127ms → 174ms → 138ms

经过这次简单的测试：

• 配置重试应该要针对幂等的request，非幂等是绝对不能使用重试的
• retries应该要配置小一些，否则就会出现重试风暴，就像测试中10次，相当于原请求放大了10倍

熔断

熔断是为了保护后端服务不被流量风暴淹没，保护系统整体稳定

• 目标：如果后端检测5xx，超过3次，就将该pod踢下线，30s之后又加回来

  apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: backend-dr namespace: default spec: host: backend-service subsets: - labels: version: v0 name: v0 trafficPolicy: outlierDetection: baseEjectionTime: 30s consecutive5xxErrors: 3 interval: 5s maxEjectionPercent: 100

  • baseEjectionTime： 30s：服务被下线的时间，30s
  • consecutive5xxErrors: 3：触发熔断的条件，有3次5xx
  • interval: 5s：检测间隔，5s
  • maxEjectionPercent： 100，被下线的服务比例，100%

• 后端backend服务依然会报错500，先访问3次，curl -s -H 'host: api.wilsontest.com' 10.22.12.178:30785/test

  Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/tornado/web.py", line 1846, in _execute result = method(*self.path_args, **self.path_kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/test.py", line 9, in get self.writ(ret)

• 第四次再访问

  no healthy upstream

• 符合预期，第四次服务直接被熔断了，并且由于backend的pod只有1个，istio下线了，导致nginx没有upstream

限流

首先基于http1.1，每次发起http并不是短链了，而是长连接。为了不让每次都产生3次握手与4次挥手的连接消耗，istio-proxy与后端服务backend之间会维护一个长连接

• 配置在DestinationRule上

  apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: backend-dr namespace: default spec: host: backend-service subsets: - labels: version: v0 name: v0 trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 5

  • http1MaxPendingRequests: 1与maxRequestsPerConnection: 5是为了方便测试，改得非常的小
  • http1MaxPendingRequests: 1：等待“可用连接”的 HTTP 请求数量，如果没有可用连接，最多允许1个，超出就报503
  • maxRequestsPerConnection: 5：一条 TCP 连接上最多处理多少个 HTTP 请求

• 使用wrk压测工具，用20个并发，同时发送20个连接，向目标url发送请求，持续1s

  ▶ wrk -t20 -c20 -d1s -H 'Host: api.wilson.com' http://10.22.12.178:30785/test Running 1s test @ http://10.22.12.178:30785/test 20 threads and 20 connections Thread Stats Avg Stdev Max +/- Stdev Latency 10.66ms 3.18ms 21.85ms 76.73% Req/Sec 93.55 16.33 171.00 80.75% 1990 requests in 1.10s, 650.09KB read Non-2xx or 3xx responses: 92 Requests/sec: 1808.21 Transfer/sec: 590.70KB

  • 可以看到，1秒之内有1990个请求发送至目标url
  • 其中有92个请求有问题

• 检查日志

  ... [2026-02-06T07:37:08.168Z] "GET /test HTTP/1.1" 200 - upstream=10.244.0.73:10000 duration=5ms route=default [2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 503 UO upstream=- duration=0ms route=default [2026-02-06T07:37:08.169Z] "GET /test HTTP/1.1" 0 DC upstream=10.244.0.73:10000 duration=4ms route=default ...

  • http_code是200是正常请求，503就是熔断保护的结果，触发了istio熔断保护而返回客户端503
  • http_code是0，通常意味着 连接在 HTTP 响应头完整返回之前就已经断开了，这非常类似于nginx的499。他们本质都描述了一个问题，客户端没有等到结果就终止连接了，这应该和我们压测只持续了1s有关系

联系我

• 联系我，做深入的交流

至此，本文结束
在下才疏学浅，有撒汤漏水的，请各位不吝赐教...