Envoy 网关深度性能调优：内核参数・连接池・过滤器链三层落地指南

最近啃了两周 Envoy 网关性能的硬骨头。线上 4 台 8C16G 物理机（Intel Xeon Gold 6248，万兆网卡），跑 Envoy 1.29.3，业务高峰时单实例 QPS 卡在 1.2 万上不去，P99 延迟飙到 180ms，软中断占 CPU 直奔 38%。从内核协议栈、Envoy 线程与连接模型到过滤器链路逐层扒下来，最终单实例稳定跑 2.8 万 QPS，P99 压到 42ms，整体吞吐提升 133%。

很多团队用 Envoy 只堆路由和过滤器配置，默认参数直接上线，最后瓶颈卡在哪都找不到。这篇把完整调优路径沉淀下来，三大核心维度，每一条都是压测 5 轮以上、线上跑过一周验证过的干货。

一、内核层调优：先拆掉操作系统的性能天花板

Envoy 本质是用户态转发代理，所有网络 IO 最终都落在内核协议栈上。80% 的网关性能瓶颈，根源不在 Envoy 本身，而在内核参数把上限锁死了。这一层调优性价比最高，改完重启服务立竿见影。

1. 基础资源限制：先把文件描述符拉满

高并发下每条 TCP 连接占一个文件描述符，系统默认 1024 的软限制在网关场景等于裸奔。

# /etc/security/limits.conf  
envoy  soft  nofile  1048576
envoy  hard  nofile  1048576
envoy  soft  nproc   65535
envoy  hard  nproc   65535

踩坑提醒：systemd 启动的服务会忽略 limits.conf，必须在 service 单元里显式加 LimitNOFILE=1048576；容器环境还要检查宿主机的全局 limit，容器内的配置不会突破宿主机上限。

2. TCP 协议栈核心参数：万级并发必调项

这组参数是反复压测后敲定的最优值，适配 API 网关短请求、高并发的场景，CentOS 7.9 / 内核 5.4 验证通过：

# /etc/sysctl.conf
# 1. 端口池：保证源端口足够，避免端口耗尽
net.ipv4.ip_local_port_range = 1024 65535
# 2. TIME_WAIT 复用：网关场景必开，端口快速回收
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
# 3. 连接队列：应对突发流量，避免 SYN 丢包
net.ipv4.tcp_max_syn_backlog = 16384
net.core.somaxconn = 16384
# 4. 连接跟踪表：NAT/容器环境必调，否则连接数上去直接丢包
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
# 5. 收发缓冲区：适配万兆网卡，平衡内存与吞吐
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 6. 关闭时间戳：减少内核计算开销，NAT 场景无副作用
net.ipv4.tcp_timestamps = 0
# 7. TCP Keepalive：配合 Envoy 连接池，提前清理死连接
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

避坑：别开 tcp_tw_recycle，NAT 网络下会导致大量客户端连接失败，这个参数在内核 4.10 之后已经被废弃，老教程别再信。

3. 网卡中断亲和性：解决单核软中断瓶颈

默认下单队列网卡的中断全打在 0 号 CPU 核上，流量一高软中断直接把核打满，成为整条链路的瓶颈。

# 查看网卡队列数，万兆网卡一般支持多队列
ethtool -l eth0
# 开启 8 队列，对应 8 核 CPU
ethtool -L eth0 combined 8

# 中断亲和性绑定：每个队列对应一个 CPU 核，避免中断争抢
for i in $(seq 0 7); do
  irq_num=$(cat /proc/interrupts | grep "eth0-$i" | awk '{print $1}' | tr -d ':')
  [ -n "$irq_num" ] && echo $((1 << i)) > /proc/irq/$irq_num/smp_affinity
done

优化效果：做完内核层这三件事，我们当场复测，软中断 CPU 占比从 38% 降到 11%，单实例 QPS 直接从 1.2 万冲到 1.8 万，P99 延迟下降 40%。

二、Envoy 核心层：线程模型与连接池深度调优

内核打通了底层瓶颈，接下来要把 Envoy 本身的转发效率拉满。Envoy 单进程多线程模型和 Nginx 类似，但配置体系更复杂，默认值偏保守，不适合高并发网关场景。

1. Worker 线程与 CPU 绑定：别让线程来回切换

Envoy 通过 --concurrency 控制 worker 线程数，每个线程跑一个独立事件循环。官方建议等于 CPU 核数，但实测网关场景设为物理核数 - 1 最优——留 1 个核给内核软中断和管理线程，避免 worker 和中断抢 CPU。

# 启动参数显式指定，8 核机器设 7
--concurrency 7

致命坑点：K8s 容器里绝对不能让 Envoy 自动探测核数。如果 Pod limit 设 4 核，但节点是 32 核，Envoy 会启动 32 个 worker 线程，大量上下文切换直接把性能拖垮，必须显式指定 concurrency。

进阶可以配合 cpuset 把 Envoy worker 线程和网卡中断绑定在不同核上，进一步降低争抢。

2. 上游连接池：网关性能的命门

连接池配置直接决定了建连开销和上游稳定性。配小了频繁建连握手，配大了浪费内存还会把上游服务打挂。

clusters:
  - name: upstream_service
    connect_timeout: 1s
    type: EDS
    lb_policy: LEAST_REQUEST
    # 核心连接池参数
    max_connections: 2048          # TCP 最大连接数
    max_pending_requests: 4096    # 等待连接的排队请求数
    max_requests: 10240           # 总并发请求数（HTTP/2 场景核心参数）
    max_requests_per_connection: 0 # 单连接最大请求数，0=不限制，长连接复用
    # 空闲连接回收
    idle_timeout: 300s
    # TCP Keepalive，和内核参数呼应
    tcp_keepalive:
      keepalive_time: 300
      keepalive_interval: 30
      keepalive_probes: 3
    # 开启 HTTP/2 多路复用
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options:
            max_concurrent_streams: 100
            initial_stream_window_size: 65536

调优经验公式：

• HTTP/1.1 场景：max_connections = 峰值并发连接数 × 1.5，max_pending_requests = max_connections × 2
• HTTP/2 场景：单连接可承载多路并发，max_connections 可以降到原来的 1/10，靠 max_requests 控制总并发

我们把上游从 HTTP/1.1 切到 HTTP/2 后，上游活跃连接数从 1800+ 降到 87，建连带来的 CPU 开销直接下降 65%。

3. 连接缓冲区：按需分配，别浪费内存

per_connection_buffer_limit_bytes 控制每条连接的读写缓冲区，默认 1MB。API 网关场景请求体大多在几十 KB，1MB 缓冲纯属浪费内存。

listeners:
  - name: listener_80
    per_connection_buffer_limit_bytes: 32768  # 32KB，API 场景推荐值

实测数据：1 万活跃连接下，缓冲区从 1MB 调到 32KB，Envoy 内存占用从 12GB 降到 1.8GB；仅超过 32KB 的请求会触发流式转发，CPU 上升约 3%，API 场景完全值得。如果是文件上传/下载网关，建议调到 256KB 以上。

三、过滤器链层：裁剪执行路径，砍掉无效计算

Envoy 的 HTTP 过滤器是线性执行的，每多一个过滤器，请求就多一层处理开销。很多团队配置时一股脑堆 JWT、限流、Lua、WASM、全量日志，请求在过滤器链里绕一圈，延迟自然就上去了。

1. 过滤器排序：越早拒绝，浪费越少

过滤器顺序不是随便排的，核心原则：能拒绝请求的过滤器越靠前越好，非法请求在入口就被打掉，不会浪费后续计算资源。

通用排序规则（请求从外到内）：

1. 协议适配类：proxy_protocol、original_src
2. 安全鉴权类：jwt_authn、rbac（第一道关卡）
3. 流量治理类：ratelimit、fault
4. 业务扩展类：wasm、lua
5. 统计日志类：stats、access_log
6. 最后必须是 router

http_filters:
  - name: envoy.filters.http.jwt_authn
  - name: envoy.filters.http.ratelimit
  - name: envoy.filters.http.wasm
  - name: envoy.filters.http.router

优化效果：我们把 JWT 鉴权从 Lua 后面移到链首，在遭遇恶意刷接口时，CPU 占用直接下降 40%——大部分非法请求在鉴权层就被拒绝了，没走到后面的业务逻辑。

2. 扩展选型：Lua 慎用，优先原生/WASM

自定义逻辑的性能差距非常大，我们压测过同一段 Header 处理逻辑，三种实现方式的延迟开销对比：

• 原生 C++ 过滤器：基准延迟 0.3ms
• WASM（C++/Rust 编译）：额外开销 ~0.1ms，比基准慢 33%
• Lua：额外开销 ~0.8ms，比基准慢 167%

选型建议：

• 简单逻辑优先用原生过滤器能力解决，别上来就写扩展
• 性能敏感、逻辑固定的场景，用 WASM 实现
• 迭代频繁、逻辑复杂的场景，再用 Lua，且严格控制脚本复杂度

Lua 优化铁则：别在脚本里读 Body、别做阻塞 IO、别用全局变量（每个 worker 有独立 Lua VM），复杂计算全部下沉到业务服务。

3. 可观测性裁剪：全量日志是性能杀手

1 万 QPS 下全开访问日志，CPU 占用能涨 20% 以上，磁盘 IO 也会成为瓶颈。生产环境必须做采样，异常请求全量记录，正常请求按比例采样。

access_log:
  - name: envoy.access_loggers.file
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
      path: /var/log/envoy/access.log
    filter:
      or_filter:
        filters:
          # 异常请求全量记录
          - response_flag_filter:
              flags: [UH, UF, UO, DC]
          # 正常请求 10% 采样
          - runtime_filter:
              runtime_key: access_log_sampling
              percent:
                numerator: 10
                denominator: HUNDRED

Tracing 同理，生产环境设 1%~5% 采样率足够定位问题；Stats 指标用 stats_matcher 做白名单，关掉不需要的细分维度，减少内存和计算开销。

附：Envoy 性能诊断工具（优化版 Python 脚本）

调优过程中需要频繁对比指标变化，重写了一版诊断脚本，直接对接 Envoy Admin API，支持单次快照、连续监控、异常告警，不用依赖 Prometheus 就能快速定位瓶颈。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Envoy 网关性能诊断工具
功能：
1. 单次性能快照：连接数、QPS、延迟分布、连接池水位、异常告警
2. 连续监控模式：间隔采样，输出实时吞吐与延迟趋势
3. 自动识别性能瓶颈：连接池满、排队溢出、错误率超标等
用法：
  单次诊断: python envoy_perf_diag.py --admin 127.0.0.1:9901
  连续监控: python envoy_perf_diag.py --admin 127.0.0.1:9901 --interval 2
  指定监听器: python envoy_perf_diag.py --admin 127.0.0.1:9901 --listener ingress_http
"""

import argparse
import requests
import time
import sys
from typing import Dict, List


class EnvoyPerfDiag:
    def __init__(self, admin_addr: str, listener: str = "ingress_http"):
        self.base_url = f"http://{admin_addr}"
        self.listener = listener
        self._prev_stats: Dict[str, int] = {
   }
        self._prev_ts: float = 0
        self._session = requests.Session()
        self._session.timeout = 5

    def _request(self, path: str) -> dict:
        """统一请求封装，带异常处理"""
        try:
            resp = self._session.get(f"{self.base_url}{path}")
            resp.raise_for_status()
            return resp.json()
        except Exception as e:
            print(f"[ERROR] 请求 Envoy Admin 失败: {str(e)}")
            sys.exit(1)

    def fetch_stats(self) -> Dict[str, int]:
        """拉取扁平化统计指标"""
        data = self._request("/stats?format=json")
        stats = {
   }
        for item in data.get("stats", []):
            if "value" in item:
                stats[item["name"]] = item["value"]
        return stats

    def calc_delta_rate(self, curr_stats: Dict[str, int], keys: List[str]) -> Dict[str, float]:
        """计算两次采样间的速率（QPS）"""
        now = time.time()
        delta = now - self._prev_ts
        result = {
   }
        if delta <= 0 or not self._prev_stats:
            return result

        for key in keys:
            curr = curr_stats.get(key, 0)
            prev = self._prev_stats.get(key, 0)
            result[key] = round((curr - prev) / delta, 2)
        return result

    def get_latency_percentiles(self, stats: Dict[str, int]) -> Dict[str, int]:
        """提取延迟分位数据，单位毫秒"""
        prefix = f"http.{self.listener}.downstream_rq_time"
        percentiles = ["0.5", "0.9", "0.99", "0.999"]
        result = {
   }
        for p in percentiles:
            result[f"P{p}"] = stats.get(f"{prefix}.p{p}", 0)
        return result

    def get_server_info(self) -> dict:
        """获取服务基础信息"""
        return self._request("/server_info")

    def get_cluster_health(self) -> List[dict]:
        """获取上游集群健康状态与连接池水位"""
        data = self._request("/clusters?format=json")
        return data.get("cluster_statuses", [])

    def check_bottlenecks(self, stats: Dict[str, int], qps: Dict[str, float]) -> List[str]:
        """自动检测性能瓶颈点，返回告警列表"""
        warnings = []
        prefix = f"http.{self.listener}"

        # 5xx 错误率超过 1% 告警
        total_qps = qps.get(f"{prefix}.downstream_rq_total", 0)
        err_qps = qps.get(f"{prefix}.downstream_rq_5xx", 0)
        if total_qps > 100 and err_qps / total_qps > 0.01:
            err_rate = round(err_qps / total_qps * 100, 2)
            warnings.append(f"5xx 错误率超标: {err_rate}%")

        # 连接池溢出检测
        cx_overflow = stats.get(f"{prefix}.downstream_cx_overflow", 0)
        if cx_overflow > 0:
            warnings.append(f"连接队列溢出累计: {cx_overflow} 次，建议调大 max_connections")

        # 排队请求堆积
        rq_pending = stats.get(f"{prefix}.downstream_rq_pending_overflow", 0)
        if rq_pending > 0:
            warnings.append(f"请求排队溢出累计: {rq_pending} 次，建议调大 max_pending_requests")

        return warnings

    def print_snapshot(self):
        """输出一次完整性能快照"""
        curr_stats = self.fetch_stats()
        prefix = f"http.{self.listener}"

        print("=" * 65)
        print(f"Envoy 网关性能快照  {time.strftime('%Y-%m-%d %H:%M:%S')}")
        print("=" * 65)

        # 基础信息
        info = self.get_server_info()
        print(f"版本: {info['version']}  |  状态: {info['state']}")
        print()

        # 连接指标
        print("[连接指标]")
        print(f"  总连接数累计: {curr_stats.get('server.total_connections', 0)}")
        print(f"  当前活跃连接: {curr_stats.get('server.active_connections', 0)}")
        print(f"  连接失败累计: {curr_stats.get(f'{prefix}.downstream_cx_destroy_remote_with_active_rq', 0)}")
        print()

        # QPS 指标
        qps_keys = [
            f"{prefix}.downstream_rq_total",
            f"{prefix}.downstream_rq_2xx",
            f"{prefix}.downstream_rq_5xx",
        ]
        qps_data = self.calc_delta_rate(curr_stats, qps_keys)
        if qps_data:
            print("[实时 QPS]")
            print(f"  总请求: {qps_data.get(f'{prefix}.downstream_rq_total', 0)} req/s")
            print(f"  2xx  : {qps_data.get(f'{prefix}.downstream_rq_2xx', 0)} req/s")
            print(f"  5xx  : {qps_data.get(f'{prefix}.downstream_rq_5xx', 0)} req/s")
            print()

        # 延迟分布
        latency = self.get_latency_percentiles(curr_stats)
        print("[请求延迟 (ms)]")
        for label, val in latency.items():
            print(f"  {label.ljust(5)}: {val}")
        print()

        # 上游集群状态
        clusters = self.get_cluster_health()
        print("[上游集群状态]")
        for cluster in clusters:
            name = cluster["name"]
            hosts = cluster.get("host_statuses", [])
            healthy = sum(1 for h in hosts if h.get("healthy", {
   }).get("healthy", False))
            print(f"  {name}: {healthy}/{len(hosts)} 健康")
        print()

        # 瓶颈告警
        warnings = self.check_bottlenecks(curr_stats, qps_data)
        if warnings:
            print("[⚠️  性能告警]")
            for w in warnings:
                print(f"  - {w}")
        else:
            print("[✅  无明显性能瓶颈]")

        # 更新历史状态
        self._prev_stats = curr_stats
        self._prev_ts = time.time()
        print("=" * 65)
        print()

    def run_continuous(self, interval: int):
        """连续监控模式"""
        print(f"启动连续监控，采样间隔 {interval} 秒，Ctrl+C 停止\n")
        # 先采一次作为基线
        self._prev_stats = self.fetch_stats()
        self._prev_ts = time.time()
        time.sleep(interval)

        try:
            while True:
                self.print_snapshot()
                time.sleep(interval)
        except KeyboardInterrupt:
            print("\n已停止监控")


def main():
    parser = argparse.ArgumentParser(description="Envoy 网关性能诊断工具")
    parser.add_argument("--admin", default="127.0.0.1:9901", help="Envoy Admin 地址")
    parser.add_argument("--listener", default="ingress_http", help="HTTP 监听器名称")
    parser.add_argument("--interval", type=int, default=0, help="连续监控间隔(秒)，0表示单次诊断")
    args = parser.parse_args()

    diag = EnvoyPerfDiag(args.admin, args.listener)

    if args.interval <= 0:
        diag.print_snapshot()
    else:
        diag.run_continuous(args.interval)


if __name__ == "__main__":
    main()

脚本使用很简单，默认对接本地 9901 管理端口，单次执行直接看全量快照；加 --interval 参数就能持续刷新，调优的时候改完参数马上能看到数值变化。脚本内置了瓶颈检测，连接池溢出、错误率超标都会自动提示，不用自己对着指标逐个排查。

最后：调优不是一劳永逸

整个调优做下来最深的体会是：没有万能的最优参数，只有适配业务场景的配置。小请求高并发场景要收缓冲、开长连接、压短过滤器链；大文件传输场景要扩缓冲、调窗口、保连接稳定。

三层优化的优先级非常明确：内核调优 > 连接管理 > 过滤器链。底层参数的天花板决定了上层能跑到的上限，地基没打牢，上层怎么调都是杯水车薪。

建议大家调优前先跑一轮基准测试拿到基线，每改一组参数就复测一次，用数据说话，别凭感觉调。