Envoy 流量治理实战：熔断、限流与流量分发配置详解

在前面的小节中，我们已经详细介绍了Envoy作为反向代理、服务发现、流量劫持以及自动注入Sidecar的能力。可以看出，Envoy远不止是一个简单的HTTP代理工具，它还集成了众多强大且实用的高级功能。本小节将重点探讨Envoy在微服务架构中核心的流量治理能力。

熔断

在分布式系统中，最危险的往往不是立即失败的错误，而是响应变慢。当下游某个服务性能下降时，可能会导致：

• 上游请求不断积压
• 线程、连接等资源被逐渐耗尽
• 最终引发整个系统的级联故障，即“雪崩效应”

Envoy的熔断机制目标非常明确：在下游服务资源被完全耗尽之前，主动拒绝部分请求，从而保护系统的整体稳定性。

Envoy 的熔断配置

Envoy的熔断机制基于对资源使用情况的硬性限制，而非基于错误率的统计判断。其核心限制指标包括：

• 最大连接数 (max_connections)
• 最大并发请求数 (max_requests)
• 最大等待请求数 (max_pending_requests)
• 最大重试请求数 (max_retries)

配置示例如下：

clusters:
  - name: app_service
    ...
    circuit_breakers:
      thresholds:
      - priority: DEFAULT
        max_connections: 1000
        max_pending_requests: 100
        max_requests: 5
        max_retries: 50

当任意一个指标超过设定的阈值时，Envoy会直接返回 503 状态码，请求将不会被转发至上游服务。

验证熔断效果

为了验证配置是否生效，我们可以将 max_requests 设置为一个较小的值，例如5。这意味着只要并发请求数超过5，超出的部分就会立刻被熔断。

使用 ApacheBench 工具进行测试：

ab -n 10 -c 10 10.22.12.178:30785/test

从测试结果可以看到，确实出现了4次失败。同时，查看Envoy的访问日志（access_log）也能与之对应：

[2025-12-30T08:03:41.267Z] "GET /test HTTP/1.0" 200 40 0 aecc99c3-4649-478e-8610-79e1b86c6338 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 503 81 0 98609f61-60cf-4522-96c6-e0eb51743791 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service UO
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 503 81 0 0b244330-25bd-48e9-b9fc-a0b7f5846e17 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service UO
...

日志中状态码为 503 且包含 UO (Upstream Overflow) 标识的记录，即为被熔断的请求。

核心要点：熔断关注的是对并发资源的保护（如连接数、并发请求数），而非简单的QPS（每秒查询率）控制。

限流

如果说熔断解决的是“服务被拖慢”的问题，那么限流解决的则是“服务被打爆”的风险。Envoy限流的目标是控制单位时间内的请求速率，常用于应对以下场景：

• 突发流量冲击
• 单一IP或用户的恶意请求
• 上游服务Bug导致的请求风暴

限流配置

Envoy可以通过本地限流过滤器轻松实现限流功能：

listeners:
- name: ingress_listener
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 10000
  filter_chains:
  - filters:
    - name: envoy.filters.network.http_connection_manager
      typed_config:
        ...
        http_filters:
        - name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            stat_prefix: local_rate_limiter
            token_bucket:
              max_tokens: 100
              tokens_per_fill: 100
              fill_interval: 1s
            filter_enabled:
              default_value:
                numerator: 100
                denominator: HUNDRED
            filter_enforced:
              default_value:
                numerator: 100
                denominator: HUNDRED
        - name: envoy.filters.http.router

以上配置定义了一个令牌桶：每秒补充100个令牌（tokens_per_fill: 100， fill_interval: 1s），桶容量为100（max_tokens: 100）。这意味着每秒最多允许100个请求通过。当请求速率超过阈值时，Envoy将直接返回 429 (Too Many Requests) 状态码。

为了方便测试，将阈值改为5后再次进行压测：

ab -n 10 -c 10 10.22.12.178:30785/test

查看日志，可以清晰地看到被限流的请求：

[2025-12-30T09:58:43.655Z] "GET /test HTTP/1.0" 200 40 1 f775154c-898e-46b2-99d5-b5629493834c "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 429 18 0 fde80049-a2df-473e-9f96-08a1526352ce "ApacheBench/2.3" "-" - app_service RL
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 429 18 0 85d3f948-eb71-4304-88ae-ab1dc29e42b7 "ApacheBench/2.3" "-" - app_service RL
...

状态码 429 和标识 RL (Rate Limited) 表明请求已被限流过滤器拦截。

关键参数解析：filter_enabled 与 filter_enforced

这两个参数共同决定了限流器的行为模式：

• filter_enabled: 控制是否对请求进行限流评估。
• filter_enforced: 控制是否对评估后应被限流的请求执行真正的拦截。

例如，配置为“仅观察”模式：

filter_enabled:
  default_value:
    numerator: 100
    denominator: HUNDRED
filter_enforced:
  default_value:
    numerator: 0
    denominator: HUNDRED

此模式下，Envoy会记录哪些请求应该被限流，但并不会实际拒绝它们。这类似于AWS WAF的“观察者模式”，常用于上线前验证限流规则是否正确。可以通过Envoy的管理接口查看统计信息：

curl "http://10.244.0.221:9901/stats?filter=local_rate_limit"
local_rate_limiter.http_local_rate_limit.enabled: 11
local_rate_limiter.http_local_rate_limit.enforced: 0
local_rate_limiter.http_local_rate_limit.ok: 6
local_rate_limiter.http_local_rate_limit.rate_limited: 5

其中，ok 表示通过的请求数，rate_limited 表示被识别为应限制的请求数。由于未执行拦截，所有请求最终都成功了。

如果两者均配置为 100，则代表严格强制执行限流策略。

不同配置组合下的行为可参考下表：

配置	enabled 计数	enforced 计数	ok 计数	rate_limited 计数
enabled=100%, enforced=100%	增加	增加	正常请求增加	超限请求增加
enabled=100%, enforced=0%	增加	不增加	总是增加	不增加
enabled=50%, enforced=100%	50% 请求增加	50% 请求增加	变化	变化
enabled=0%, enforced=任意	不增加	不增加	不增加	不增加

流量分发

流量分发是实现灰度发布、金丝雀发布、A/B测试等功能的核心。在微服务架构中，它主要用于安全地将流量引导至不同版本的服务实例。

按权重比例分发

这是最常见的场景，根据预设的权重将流量分配到不同的服务集群。

route_config:
  name: local_route
  virtual_hosts:
  - name: app
    domains: ["*"]
    routes:
    - match: {prefix: "/test"}
      route:
        weighted_clusters:
          clusters:
          - name: service-v1
            weight: 9
          - name: service-v2
            weight: 1

这里的 service-v1 和 service-v2 需要在 clusters 部分预先定义：

clusters:
  - name: service-v1
    ...
  - name: service-v2
    ...

按请求路径前缀分发

常用于API版本升级（如v1到v2）或路由结构变更。

route_config:
  name: local_route
  virtual_hosts:
  - name: app
    domains: ["*"]
    routes:
    - match:
        prefix: "/test/v1"
      route:
        cluster: app_service_v1
        prefix_rewrite: "/test"
    - match:
        prefix: "/test"
      route:
        cluster: app_service

重要提示：Envoy的匹配规则与Nginx不同，它没有复杂的优先级规则（如精确匹配优先）。Envoy的匹配是简单按配置顺序执行的。它支持以下几种匹配方式：

关键字	例子	解释
path	path: "/test/v1"	精确匹配，只匹配路径完全为 /test/v1 的请求。
prefix	prefix: "/test/v1"	前缀匹配，匹配以 /test/v1 开头的所有路径，如 /test/v1/anything。
safe_regex	regex: "^/test/v1(/.*)?$"	正则匹配，功能更强大灵活。

总结

Envoy提供的上述能力，共同构成了其强大的流量治理体系。这远超出了简单的服务代理范畴，使其成为微服务治理的核心组件。

• 熔断：专注于并发资源保护，防止级联故障。
• 限流：实施速率控制，保护服务免于过载。
• 流量分发：实现安全、可控的发布策略。
• 透明代理：提供对应用无侵入的接入方式。

在服务网格化日益普及的今天，服务的可观测性变得至关重要。当我们为微服务引入Envoy作为边车代理后，需要额外关注代理层自身的指标，例如：Envoy处理的请求延迟、错误率、资源消耗等。这些将是保障整个系统稳定性的关键，也构成了我们后续探讨的主题。