不止是代理：Envoy 在微服务中的熔断、限流与流量治理实战

前言

之前的小节，已经详细介绍了envoy做反向代理、服务发现、流量劫持以及自动注入envoy的sidecar，可以发现envoy不光是一个普通的http代理工具，它还有很多非常强大的功能，本小节就来介绍一下envoy其他强大且实用的功能

Envoy 核心流量治理能力实践：熔断、限流、流量分发、透明代理

熔断

在分布式系统中，最危险的不是错误，而是慢。当某个下游服务变慢时：

• 上游请求不断堆积
• 线程、连接被耗尽
• 最终引发级联故障（雪崩）

Envoy 的熔断机制，目的非常明确：在下游资源耗尽之前，主动拒绝请求，保护系统整体稳定

Envoy 的熔断配置

Envoy 的熔断是基于资源使用情况的硬限制，而不是基于错误率的统计判断。

核心限制指标包括：

• 最大连接数

• 最大并发请求数

• 最大等待请求数

• 最大重试请求数

  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，就会立刻报错。用ab来测试一下

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
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 503 81 0 09906490-1916-4e26-bc9f-85d830e1f219 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service UO
[2025-12-30T08:03:41.271Z] "GET /test HTTP/1.0" 503 81 0 a77bc60a-5cdc-4340-8969-9ce2a1b6206d "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service UO
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 200 40 2 550dc619-6002-4bd6-9b36-3fe1a2b2b3e3 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 200 40 3 da2a001c-3dc0-4afb-ae0a-a09b78642890 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T08:03:41.269Z] "GET /test HTTP/1.0" 200 40 3 3a7f7ec4-42c1-48d3-acf5-190a81439d84 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 200 40 4 3bcd9947-e4c2-43c8-84de-12bd551af590 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T08:03:41.270Z] "GET /test HTTP/1.0" 200 40 4 f5f5f231-1079-4abf-8d72-56617d43cc03 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -

熔断关注的是 并发资源保护，而不是 QPS

限流

熔断解决的是"服务被拖慢"，那么限流解决的是"服务被打爆"，Envoy 的限流目标是：控制单位时间内的请求速率。常见触发场景：

• 突发流量
• 单 IP / 单用户恶意请求
• 上游 Bug 导致请求风暴

限流配置

      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 个请求，当超过阈值，Envoy 直接返回 429，请求不会进入上游，为了方便测试，将阈值改为5，再次进行ab测试

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
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 429 18 0 11c01a56-46f1-4bc0-a611-4d32d32e3440 "ApacheBench/2.3" "-" - app_service RL
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 429 18 0 53d14770-b89a-48ec-a430-a10d28849ccd "ApacheBench/2.3" "-" - app_service RL
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 429 18 0 2bcfd5d9-bfba-4bda-b178-aaf85389a5c6 "ApacheBench/2.3" "-" - app_service RL
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 200 40 2 1c56e4ec-b463-4a89-bdcb-978d81ec5826 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 200 40 2 989c07b8-1af3-48f1-9398-fb28ad1ad0bd "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 200 40 2 ba224777-066d-4fae-b7e3-e5461c94b236 "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -
[2025-12-30T09:58:43.658Z] "GET /test HTTP/1.0" 200 40 2 7db78d9a-9a4e-4b41-8f13-6597e28946ce "ApacheBench/2.3" "-" 10.244.0.203:10000 app_service -

重要参数

filter_enabled与filter_enforced，简而言之如果配置了前者，而没有配置后者（其中数字代表百分比）

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

那就会启动观察者模式（相信玩过AWS WAF的老哥对观察者模式应该非常熟悉了），envoy会记录哪些记录是应该被拦截的，但不会真正拦截，可以从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是被限制的请求，由于是观察者模式，只会记录，并不会真正限制

如果两者都配置为numerator: 100，那就代表会严格执行了，一旦超过阈值，会立刻触发429

这里给一个配置表与接口统计信息的表

配置	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

这里的name，是配置在cluster里面的

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

按header分发

按前缀分发

常见于api结构变更，或者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就是简单粗暴的按照顺序来

envoy有一套自己的匹配规则

关键字	例子	解释
path	path: "/test/v1"，只匹配 "/test/v1"， 多一个字母都会报404	精确匹配（失去了nginx的最高优先级）
prefix	prefix: "/test/v1"，匹配 "/test/v1/anything"	最大前缀匹配
safe_regex	regex: "^/test/v1(/.*)?$"，匹配 /test/v1 和 /test/v1/*	正则匹配

透明代理

这部分在之前的文章已经详细描述，使用iptables做流量劫持，这里就不赘述了

总结

Envoy 提供的这些能力，本质上都围绕一件事，Envoy不光是做服务代理，而是做服务治理

• 熔断：并发保护
• 限流：速率控制
• 流量分发：安全发布
• 透明代理：零侵入接入

在微服务中，特别是服务网格化的今天，越来越强调服务的可观测性，特别是当我们的微服务加上了一层envoy代理之后，对一些非常重要的指标需要更加的关注，比如：envoy层的延时、envoy层是否报错、envoy层的资源消耗等等，这就是下一期的内容了

联系我

• 联系我，做深入的交流

---

至此，本文结束

在下才疏学浅，有撒汤漏水的，请各位不吝赐教...