EnvoyProxy性能优化实践：解决高并发场景下的CPU与连接数问题

背景概述

在将边缘负载均衡从Nginx迁移到EnvoyProxy的过程中，某团队遇到了显著的性能挑战。当流量达到约20k请求/秒时，EnvoyProxy表现出以下问题：

1. CPU使用率比Nginx高2-5倍
2. 连接数激增导致系统文件描述符耗尽
3. 启用HTTP keep-alive时出现约6-9k后端连接（针对3k Kubernetes Pods）

问题分析

核心性能瓶颈

1. 线程模型问题：默认配置下Envoy会创建与CPU核心数相等的worker线程（128核机器产生128个worker），每个worker独立维护连接池，导致后端连接数呈倍数增长。
2. 协议选择影响：使用HTTP/1.1协议时，每个活跃请求都需要独立连接，而HTTP/2可以实现多路复用。
3. 资源限制：系统默认的文件描述符限制无法支撑大规模连接场景。

性能对比数据

在AMD EPYC 7713P 64核处理器（128线程）环境下的测试显示：

• 128线程：基准100% CPU使用率
• 32线程：CPU使用率降至75%
• 8线程：CPU使用率降至66%，但吞吐量只有25%

优化方案

关键配置调整

1. Worker线程调优：

   # 建议将并发数设置为物理核心数的1/4到1/2
   --concurrency=32
   

2. 连接池管理：

   circuit_breakers:
     thresholds:
       - max_connections: 256  # 限制每个worker的最大连接数
   

3. 协议升级：

   typed_extension_protocol_options:
     envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
       explicit_http_config:
         http2_protocol_options: {}  # 启用HTTP/2多路复用
   

4. 系统级优化：

   # 调整系统文件描述符限制
   ulimit -n 1000000
   sysctl -w fs.file-max=2000000
   

实施效果

经过优化后：

• CPU使用率从50%降至20%
• 保持HTTP keep-alive的情况下稳定处理20k RPS
• 连接数控制在合理范围内，避免系统资源耗尽

经验总结

1. 线程数不是越多越好：需要根据实际吞吐量和CPU使用率找到平衡点
2. 协议选择至关重要：HTTP/2能显著减少连接数
3. 系统参数需要配套调整：特别是文件描述符限制
4. 监控指标关注点：需要密切监控envoy_cluster_upstream_cx_total等连接相关指标

对于大规模Kubernetes集群的入口网关场景，建议采用渐进式迁移策略，同时保留新旧系统的并行运行能力，以便进行性能对比和快速回滚。