Envoy 与 Nginx：区别、分工与选型

Envoy 和 Nginx 常被放在一起比，但本质不是”同类竞品”——Nginx 是通用 Web 服务器 + 反向代理，Envoy 是给服务网格 / 微服务治理量身造的 L7 代理。本文从配置模型、可观测性、L7 能力、扩展架构、服务网格角色、性能六个维度拆解差异，并结合 K8s / Cilium / LLM 服务化讲清它们各自的边界。

---

一、一句话定位

	Nginx	Envoy
诞生	2004（Igor Sysoev），解决 C10K	2016（Lyft），解决微服务东西向通信
原始问题	”一台服务器前面怎么高性能挡流量"	"成百上千服务之间怎么动态发现、可观测、带 mTLS”
身份	通用 Web 服务器 + 反代 + L4/L7 LB	边车代理（sidecar）+ 网关，服务网格数据面
实现语言	C	C++

关键认知：Nginx 的主战场是南北向（入口 / 边缘），Envoy 的主战场是东西向（服务间）。 两者在 K8s Ingress 层是竞品，在服务网格层 Envoy 是事实标准、Nginx 已退场。

---

二、六个核心差异维度

2.1 配置模型（最本质差异）

	Nginx	Envoy
配置来源	静态 .conf（include 多文件）	动态 xDS API（gRPC 流式：LDS/RDS/CDS/EDS/SDS/ADS）
变更生效	nginx -s reload（优雅重载，短暂双进程并存；upstream/map 变更需 reload）	运行时热更新，无需 reload、不丢连接
控制面耦合	无（纯静态文件驱动）	强（依赖控制面如 Istio 下发 xDS）

动态配置是 Envoy 能做服务网格数据面的前提——控制面改一条路由规则，Envoy 秒级生效、正在飞的请求不受影响。Nginx 做不到无感变更，每次 reload 都有个短暂的双 master 过渡期，大规模 upstream 频繁变化时运维成本陡增。

2.2 可观测性：原生 vs 外挂

• Envoy 开箱即用：内建 stats（每个集群 / 路由 / 监听器维度的指标）、access log 自定义格式、原生 tracing 集成（OpenTelemetry / Jaeger / Zipkin）、:9901/admin 接口（看配置、热重启、drain）。
• Nginx 开源版：只有 access/error log；指标要 stub_status 或第三方 nginx-prometheus-exporter；分布式追踪需 OpenTracing 模块或上 Nginx Plus（收费）。

对 SRE 来说，Envoy 的 upstream_rq_time / downstream_rq_time / rq_retry / cx_active 这类指标天生就能进 Prometheus，不用额外折腾。

2.3 L7 治理能力

能力	Nginx（开源）	Envoy
协议	HTTP/1.1、HTTP/2、HTTP/3(较新)、gRPC、WebSocket	HTTP/1.1/2/3 双向、gRPC 原生、WebSocket、MongoDB/Redis/Dubbo 协议嗅探
负载均衡算法	round-robin / least_conn / ip_hash	round-robin、least-request、一致性哈希(Maglev)、zone-aware、subset、优先级 localityLB
熔断	仅 max_fails / fail_timeout（被动、粗粒度）	异常检测被动熔断（连续 5xx 率、连接失败率）、主动健康 + 驱逐
重试	proxy_next_upstream（有限）	重试预算(retry budget)、可重试 4xx/5xx、per-try 超时、对冲(hedging)
限流	limit_req（本地漏桶，无全局）	本地 + 全局限流（RateLimit 服务集成）
流量切分	split_clients（粗略）	权重路由、金丝雀、故障注入、镜像(mirror)

一致性哈希、全局限流、故障注入、流量镜像这些”服务治理”能力，在 Nginx 开源版里要么没有、要么要 Nginx Plus。

2.4 扩展架构

• Nginx：事件驱动，单 master + 多 worker，模块必须编译进二进制（C 写、静态链接）。动态模块后来有，但生态仍以编译期为准。缺点：加个自定义逻辑要重编 + reload。
• Envoy：多线程 worker（每连接 pin 到一个 worker）、基于 libevent；可扩展 filter chain——L4 listener filters + L7 network/http filters，支持 C++ 编译进二进制或 WASM 扩展。现代设计，扩展点清晰，是 Istio 的自定义 filter 基础。

2.5 在服务网格里的角色

• Envoy：Istio / Linkerd2 / Consul Connect / 各大云 ASM 的数据面事实标准。负责 sidecar 注入、mTLS 自动、流量切分、故障注入、L7 策略执行。
• Nginx：NGINX Service Mesh 2021 推出、2023 年 F5 宣布停止维护。之后 Nginx 基本只作为 nginx-ingress（K8s 入口控制器）存在，不再做东西向数据面。

2.6 性能

	Nginx	Envoy
内存/CPU 开销	极低、成熟稳定	稍高（per-route 配置、统计开销、filter 链）
单连接吞吐	极致	略低但差距在缩小
运维复杂度（大规模动态）	高（reload 频繁）	低（xDS 动态）

结论不绝对：小流量简单反代 Nginx 更轻；大规模微服务动态拓扑下，Envoy 的”动态 + 可观测”省下的运维人天远超那点性能开销。

---

三、与你知识库的连接：Envoy × Cilium 分工

这是最值得记的一点（结合你 cilium/ 系列）：

• Cilium：用 eBPF 在 L3/L4 做服务发现、KPR、NetworkPolicy——不解析 L7 应用协议。Hubble 的 L7 可见性要靠挂 Envoy sidecar / proxy 才拿得到。
• Envoy：在 L7 做路由、熔断、重试、mTLS、协议转换。
• 典型组合：Cilium 管 L3/L4 南北向 + Envoy 管 L7 七层策略。Cilium 的 L7 NetworkPolicy（HTTP/gRPC/Kafka FQDN）本质就是靠内嵌 Envoy 执行的——你在 Cilium 网络策略与零信任 里看到的 L7 策略，底层执行引擎就是 Envoy。

---

四、反向代理配置对比（SSE / 流式场景）

呼应 HTTP 与 WebSocket 连接模型与超时 那篇：流式（SSE）反代最易踩的坑是缓冲 + 读取超时。两边正确写法：

Nginx（关闭缓冲 + 放宽读取超时）

location /v1/stream {
    proxy_pass http://upstream;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;        # 关键：关闭缓冲，SSE 逐字节透传
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 3600s;   # 覆盖"等响应头 + 流内空闲"
}

Envoy（route 级 timeout + idle）

route_config:
  virtual_hosts:
  - name: stream
    routes:
    - match: { prefix: "/v1/stream" }
      route:
        cluster: upstream
        timeout: 3600s          # 整体超时
        idle_timeout: 3600s     # 流内空闲不断连

两边的核心都是：关缓冲 + 给”等首字节/流内空闲”一个合理上限，否则就会复现那篇帖子的”首包卡死”。

---

五、选型决策

• 边缘静态资源 / 简单反代 / 极致 L4 吞吐 → Nginx（或 nginx-ingress）
• 服务网格 / 微服务东西向 / mTLS / L7 流量治理 / 强可观测 / 动态配置 → Envoy
• 现代 K8s 入口控制器：Envoy 系（Gloo / Contour / Emissary）vs nginx-ingress，本质是在”L7 治理能力”和”极致简单”之间取舍。
• 两者并用：Cilium(eBPF L3/L4) + Envoy(L7 sidecar) 是当前很多生产集群的”黄金组合”。

---

关联知识

• HTTP 与 WebSocket 连接模型与超时 — 流式(SSE)反代的正确配置(proxy_read_timeout/buffering)在此呼应
• ../cilium/Cilium 网络策略与零信任 — Envoy 是 Cilium L7 策略的执行引擎；对比其与传统 Nginx 反代
• ../cilium/Cilium 架构与数据面组件 — Cilium 内嵌 Envoy 实现 L7 可见性/策略
• ../cilium/Cilium 知识总览 — 东西向流量治理全景
• ../k8s/网络架构/K8s 网络架构总览 — L3/L4 网络底座；本文是 L7 代理层
• ../k8s/特性详解/Istio 服务网格详解 — Envoy 作为 Istio 数据面
• ../llm-serving/生产部署与运维 — LLM 网关的反代选型(Nginx/Envoy)、鉴权限流、监控

参考资源

• Envoy Proxy 官方文档 - xDS / Architecture
• CNCF Envoy
• Nginx Admin Guide - Reverse Proxy
• Nginx Service Mesh EOL 公告 (2023)

学习时间

阶段	时间	备注
内容创建	2026-07-21	应知识库整理需求，从 Nginx/Envoy 对比切入：定位、六维度差异、与 Cilium 分工、SSE 反代配置、选型

状态标记

📖 已掌握 — 两者定位差异、配置模型(xDS vs reload)、可观测性、L7 能力、服务网格角色、与 Cilium 分工 📝 待补充 — Envoy filter chain 自定义开发、Nginx Unit/NGINX Ingress Controller 源码级、两者压测数据对比