流量治理双雄记：Nginx 守门，Envoy 巡城！

各位技术小伙伴，大家好，我是妍妍。
今天想和大家聊一个很有意思的话题——流量治理工具的变化。如果你维护过线上服务，大概率对 Nginx 不陌生。但最近几年，Envoy 的名字越来越频繁地出现在架构图里。有人说 Nginx 老了，有人说 Envoy 太复杂。到底该怎么看？
我们不堆术语，就用“朝代更替”的视角，把这件事捋清楚。

1. 先看“旧朝”Nginx：稳如老狗，但有点“倔”
   Nginx 生于 2004 年，那个年代互联网流量远没有今天这么“花哨”。它的核心模型是 事件驱动 + 多进程，擅长做几件事：
   静态文件服务
   反向代理和负载均衡
   简单的流量分发（基于 URL、IP 等）
   它的优点是 极其稳定、内存占用低、配置语法直观。到今天，你依然可以用它轻松扛住万级并发。
   但问题也出在这里：它的配置是静态的。
   每次修改路由规则，要么 reload，要么重启。在大规模微服务场景下，这就像“每次改红绿灯都要修路”，代价太高。
2. “新朝”Envoy：为云原生而生的“智能交警”
   Envoy 在 2016 年由 Lyft 开源，初衷就是为了解决 微服务间通信的复杂性。它的几个关键设计，直接对标了 Nginx 的痛点：
   动态配置（xDS 协议）：可以通过控制平面实时下发路由、超时、重试等规则，无需重启。
   L3/L4/L7 全层支持：不仅能处理 HTTP，还能处理 TCP、UDP、gRPC 等。
   丰富的可观测性：默认自带详细的统计数据、访问日志和链路追踪能力。
   Sidecar 模式：可以和服务部署在一起，实现精细化的流量治理（比如灰度、熔断、故障注入）。
   打个比方：Nginx 像一位经验丰富的“老门卫”，能认人、能挡人，但换岗要提前通知；Envoy 更像一位“智能调度员”，随时根据大厅里的人数、每个人的身份，动态调整放行策略。
3. “朝代更替”的本质：需求变了，工具跟着变
   不是 Nginx 不行了，而是 业务场景变了：
   以前：单体架构，流量入口相对固定，Nginx 刚好胜任。
   现在：微服务 + Kubernetes，服务实例随时扩缩容，IP 频繁变化，静态配置根本跟不上。
   所以，“更替”不是取代，而是分工：
   Nginx 依然适合做 边缘网关（处理南北流量），面对公网，简单、高效、安全。
   Envoy 更适合做 内部服务网格的数据平面（处理东西流量），配合 Istio 等控制平面，实现细粒度的流量治理。

4. 代码模块看差异（8 个核心对比）
   模块 1：静态路由 vs 动态路由

   # Nginx 静态路由
   location /api/ {
    proxy_pass http://backend-service:8080;
   }

# Envoy 动态路由（通过控制平面下发）
routes:
- match:
    prefix: "/api/"
  route:
    cluster: backend_service

Envoy 的路由可以随时通过 API 更新，而 Nginx 需要 reload。
模块 2：健康检查方式

# Nginx 被动健康检查
proxy_next_upstream error timeout;

# Envoy 主动健康检查
health_checks:
  - timeout: 2s
    interval: 5s
    unhealthy_threshold: 3

Envoy 支持主动探测，Nginx 更依赖被动判断。
模块 3：负载均衡算法

# Nginx 加权轮询
upstream backend {
    server 10.0.0.1 weight=3;
    server 10.0.0.2 weight=1;
}

# Envoy 支持一致性哈希、随机、最小请求等多种策略
load_assignment:
  cluster_name: backend
  endpoints:
    - lb_endpoints:
      - endpoint:
          address:
            socket_address:
              address: 10.0.0.1
              port_value: 8080

模块 4：超时与重试

# Nginx 超时配置
proxy_connect_timeout 5s;
proxy_read_timeout 10s;

# Envoy 超时 + 重试策略
timeout: 10s
retry_policy:
  retry_on: 5xx
  num_retries: 3

模块 5：流量镜像（灰度发布）

# Nginx 需要借助第三方模块或复杂配置
# 原生不支持镜像

# Envoy 原生支持流量镜像
request_mirror_policies:
  - cluster: mirror_cluster
    runtime_fraction:
      default_value:
        numerator: 50

模块 6：访问日志格式

# Nginx 日志格式
log_format main '$remote_addr - $remote_user [$time_local] "$request"';

# Envoy 结构化 JSON 日志
access_log:
  - name: envoy.access_loggers.file
    typed_config:
      format: '{"time":"%START_TIME%","method":"%REQ(:METHOD)%"}'

模块 7：配置生效方式

# Nginx 重新加载
nginx -s reload

# Envoy 动态更新（无需重启）
# 通过控制平面推送新的配置，热生效

模块 8：可观测性集成# Nginx 依赖第三方模块（如 lua）来上报指标

# Envoy 内置 Prometheus 统计
stats_config:
  stats_tags:
    - tag_name: cluster
      regex: ^cluster\.((.+?)\..*)$

5. 问答环节（2 个典型问题）
   问 1：我是一家中小型公司，还在用 Nginx，有必要换 Envoy 吗？
   答： 看你的痛点。如果你们服务数量不超过 20 个，变更不频繁，Nginx 完全够用。Envoy 的优势在频繁变更、多协议、细粒度治理的场景下才明显。别为了新技术而技术，合适比先进更重要。
   问 2：Envoy 的学习曲线很陡，团队怎么平滑过渡？
   答： 建议分两步走：
   先在非核心环境用 Envoy 作为 Sidecar，只做流量观察，不实际调度。
   等团队熟悉了 xDS 概念和配置结构，再逐步替换部分路由。
   同时，可以借助 Istio 这类控制平面，降低裸用 Envoy 的复杂度。
6. 我的观点：不是“改朝换代”，而是“各安其位”
   我更愿意把这次变化看作 分工细化，而不是谁取代谁。
   如果你的业务需要极致的性能、简单的配置、稳定的运行，Nginx 依然是最优解。
   如果你在构建云原生微服务，需要动态调度、深度观测、多协议支持，Envoy 是更合适的选择。
   未来很长一段时间，两者会共存。边缘用 Nginx，内部用 Envoy，是很多成熟企业的实践模式。
   写在最后
   技术选型没有“最好”，只有“最合适”。希望这篇文章能帮你快速看清 Nginx 和 Envoy 的定位差异，不再被各种概念绕晕。
   我是妍妍，不写代码，但爱琢磨技术背后的逻辑。如果觉得有用，欢迎转发给身边正在纠结的小伙伴。
   更多经验分享：
   https://segmentfault.com/a/1190000047845237
   https://www.71wa.com/quanwei/95.html
   https://www.kkkmir.com/bbdq/364.html
   https://segmentfault.com/a/1190000047812147