在微服务架构中，服务的可用性和稳定性至关重要。当某个下游服务出现延迟或故障时，如果不加以控制，可能会引发“雪崩效应”，导致整个系统瘫痪。熔断（Circuit Breaker） 和 连接限制（Connection Limit） 是两种关键的容错机制，能够有效防止故障扩散，提升系统的韧性。
本文将基于 Envoy Gateway，展示如何在 Kubernetes 环境中配置这两种策略，并通过实际示例验证其效果。通过这篇实战指南，你将掌握如何在生产环境中为你的服务保驾护航。
核心概念解析
在开始动手配置之前，我们先来统一理解这两个核心概念。
熔断 (Circuit Breaker)
熔断机制的核心思想借鉴了电路保险丝：当检测到下游服务失败率超过预设阈值时，主动“熔断”，暂时停止向其发送请求。经过一段冷却时间后，再尝试小流量恢复，若恢复成功则关闭熔断器。这既能防止故障服务被持续不断的请求压垮，也为它争取了宝贵的恢复时间。
在 Envoy 的实现中，熔断行为主要通过以下几个关键参数控制：
maxConnections：到上游主机的最大并发连接数。maxPendingRequests：等待就绪连接池分配连接的最大请求数。maxRequests：上游主机能同时处理的最大请求数（并发请求数）。maxRetries：在指定时间窗口内，上游主机允许的最大重试次数。
当流量超过这些阈值时，Envoy 将立即返回 503（Service Unavailable）状态码，快速失败，避免请求堆积。
连接限制 (Connection Limit)
连接限制则用于控制客户端与网关（或网关与后端服务）之间的最大并发连接数。它的主要目的是防止来自单一客户端或某些异常流量占用过多的连接资源，从而保障其他正常请求的可用性，实现资源的公平调度和隔离。
熔断配置示例
让我们通过一个具体的例子，看看如何配置并验证熔断策略。
1. 配置前基准测试
首先，我们在未配置熔断的情况下，使用 hey 压力测试工具发起请求，建立一个性能基准。这里模拟上游服务处理较慢的情况（延迟5秒响应）。
$ hey -c 100 -n 100 --host www.simple.com http://172.139.20.19:30874/ping?delay=5s
Summary:
Total: 5.0312 secs
Slowest: 5.0244 secs
Fastest: 5.0053 secs
Average: 5.0129 secs
Requests/sec: 19.8759
Total data: 500 bytes
Size/request: 5 bytes
Response time histogram:
5.005 [1] |■■
5.007 [5] |■■■■■■■■
5.009 [17] |■■■■■■■■■■■■■■■■■■■■■■■■■■■
5.011 [25] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
5.013 [8] |■■■■■■■■■■■■■
5.015 [11] |■■■■■■■■■■■■■■■■■■
5.017 [10] |■■■■■■■■■■■■■■■■
5.019 [9] |■■■■■■■■■■■■■■
5.021 [8] |■■■■■■■■■■■■■
5.022 [3] |■■■■■
5.024 [3] |■■■■■
Latency distribution:
10% in 5.0080 secs
25% in 5.0095 secs
50% in 5.0118 secs
75% in 5.0163 secs
90% in 5.0195 secs
95% in 5.0209 secs
99% in 5.0244 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0027 secs, 5.0053 secs, 5.0244 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0013 secs, 0.0000 secs, 0.0083 secs
resp wait: 5.0086 secs, 5.0024 secs, 5.0191 secs
resp read: 0.0002 secs, 0.0000 secs, 0.0015 secs
Status code distribution:
[200] 100 responses
提示：此时未达到 Envoy 默认的熔断阈值（例如maxPendingRequests默认是1024）。因此，所有100个并发请求都被正常代理到上游服务，客户端和Envoy都等待了大约5秒，全部成功（200状态码）。
2. 配置熔断策略
接下来，我们创建一个 BackendTrafficPolicy 资源，对指定的 HTTPRoute 启用熔断。这里我们将最大等待请求数(maxPendingRequests)设为5，最大并行请求数(maxParallelRequests)设为10。
$ cat <<EOF | kubectl apply -f -
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
name: circuitbreaker-for-route
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: HTTPRoute
name: simple
circuitBreaker:
maxPendingRequests: 5
maxParallelRequests: 10
EOF
backendtrafficpolicy.gateway.envoyproxy.io/circuitbreaker-for-route created
提示：如果将 maxPendingRequests 参数设置为 0，你会观察到所有请求几乎都会立即触发熔断（overflow）。
3. 验证熔断效果
再次使用相同的参数进行压力测试，观察熔断机制是否生效。
$ hey -c 100 -n 100 --host “www.simple.com” http://172.139.20.19:30874/ping?delay=5s
Summary:
Total: 5.0218 secs
Slowest: 5.0216 secs
Fastest: 0.0010 secs
Average: 0.5096 secs
Requests/sec: 19.9130
Total data: 7340 bytes
Size/request: 73 bytes
Response time histogram:
0.001 [1] |
0.503 [89] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
1.005 [0] |
1.507 [0] |
2.009 [0] |
2.511 [0] |
3.013 [0] |
3.515 [0] |
4.018 [0] |
4.520 [0] |
5.022 [10] |■■■■
Latency distribution:
10% in 0.0024 secs
25% in 0.0042 secs
50% in 0.0093 secs
75% in 0.0145 secs
90% in 5.0144 secs
95% in 5.0191 secs
99% in 5.0216 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0009 secs, 0.0010 secs, 5.0216 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0010 secs, 0.0000 secs, 0.0126 secs
resp wait: 0.5055 secs, 0.0007 secs, 5.0160 secs
resp read: 0.0014 secs, 0.0000 secs, 0.0083 secs
Status code distribution:
[200] 10 responses
[503] 90 responses
效果对比：测试结果清晰地展示了熔断的作用。在100个请求中，只有10个请求成功（200），其余90个请求因为触发了熔断而被快速拒绝（503）。平均响应时间从5秒大幅降至约0.5秒，这是因为绝大多数请求没有等待就被快速失败了。这成功模拟并防止了上游服务因并发过大而崩溃的场景。
连接限制配置示例
现在，我们来看看如何配置客户端连接限制。
1. 配置前基准测试
我们使用 hey 工具模拟一个持续的负载：10个并发，每个并发每秒1个请求（QPS），持续10秒，总共约100个请求。
$ hey -c 10 -q 1 -z 10s --host www.simple.com http://172.139.20.19:30874/ping
Summary:
Total: 10.0131 secs
Slowest: 0.0117 secs
Fastest: 0.0021 secs
Average: 0.0040 secs
Requests/sec: 9.9869
Total data: 500 bytes
Size/request: 5 bytes
Response time histogram:
0.002 [1] |■
0.003 [43] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.004 [32] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.005 [8] |■■■■■■■
0.006 [4] |■■■■
0.007 [2] |■■
0.008 [1] |■
0.009 [1] |■
0.010 [2] |■■
0.011 [1] |■
0.012 [5] |■■■■■
Latency distribution:
10% in 0.0023 secs
25% in 0.0027 secs
50% in 0.0032 secs
75% in 0.0040 secs
90% in 0.0076 secs
95% in 0.0108 secs
99% in 0.0117 secs
Status code distribution:
[200] 100 responses
可以看到，在无限制的情况下，所有100个请求都成功完成。
2. 配置连接限制策略
我们创建一个 ClientTrafficPolicy 资源，在 Gateway 级别设置连接限制为 5。
$ cat <<EOF | kubectl apply -f -
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: ClientTrafficPolicy
metadata:
name: connection-limit-ctp
namespace: default
spec:
targetRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: simple-gw
connection:
connectionLimit:
value: 5
EOF
3. 验证连接限制效果
使用同样的参数再次进行测试。
$ hey -c 10 -q 1 -z 10s --host “www.simple.com” http://172.139.20.19:30874/ping
Summary:
Total: 10.0120 secs
Slowest: 0.0123 secs
Fastest: 0.0023 secs
Average: 0.0042 secs
Requests/sec: 9.9880
Total data: 285 bytes
Size/request: 5 bytes
Response time histogram:
0.002 [1] |■
0.003 [27] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.004 [16] |■■■■■■■■■■■■■■■■■■■■■■■■
0.005 [3] |■■■■
0.006 [0] |
0.007 [6] |■■■■■■■■■
0.008 [0] |
0.009 [1] |■
0.010 [1] |■
0.011 [1] |■
0.012 [1] |■
Latency distribution:
10% in 0.0028 secs
25% in 0.0030 secs
50% in 0.0034 secs
75% in 0.0042 secs
90% in 0.0071 secs
95% in 0.0110 secs
0% in 0.0000 secs
Status code distribution:
[200] 57 responses
Error distribution:
[23] Get “http://172.139.20.19:30874/ping”: EOF
[1] Get “http://172.139.20.19:30874/ping”: read tcp 10.244.217.181:35958->172.139.20.19:30874: read: connection reset by peer
...
(更多连接被重置的错误)
效果对比：配置生效后，成功的请求数从 100 次下降到了 57 次。错误分布中出现了大量的 EOF 和 connection reset by peer 错误，这正是 Envoy 在连接数超过限制（5个）后，拒绝新连接的表现。这说明连接限制策略成功地对客户端并发连接数进行了控制。
结语
在现代云原生架构中，熔断和连接限制是保障系统韧性与稳定性的两大基石技术。通过 Envoy Gateway，我们可以以声明式的、云原生友好的方式轻松集成这些能力，无需侵入业务代码，真正实现了 运维 与开发的解耦。
本文通过具体的配置实例和对比测试，直观展示了这两种机制的工作效果。无论是防止下游服务故障引发的雪崩，还是限制异常客户端的资源占用，这些策略都是构建高可用 微服务 系统不可或缺的部分。希望这篇实战指南能帮助你在自己的 Kubernetes 环境中更好地理解和应用 Envoy Gateway。
如果你对云原生网关、服务治理有更多兴趣，欢迎在云栈社区交流讨论，这里聚集了许多正在探索前沿技术的开发者。
发表于 13 小时前
|
查看: 1|
回复: 0
