反向代理的进化史：从 nginx 到 Envoy

反向代理是互联网架构里最不起眼但最关键的一层。它从早期的"静态文件服务器"演化到今天的"service mesh data plane"，背后是三次范式转移。

第一代：Web Server 兼代理

2000 年代，Apache 和 nginx 是绝对主流。它们的角色是"Web Server 兼做反向代理"：提供静态文件服务；用 proxy_pass 把动态请求转发给后端；用 vhost 在一台机器上承载多个域名。nginx 的成功在于"事件驱动 + 简单配置"。它用极低的内存占用处理了海量并发连接，把 Apache 的 prefork 模型彻底比下去。但这一代代理的局限是："它不懂应用协议"。

第二代：API Gateway

2014 年左右微服务兴起，反向代理开始"懂业务"。Kong、Tyk、APISIX 这一代开始内置认证（JWT、OAuth）、限流（按 user、按 IP、按 API）、插件机制（用 Lua 或 Go 扩展）、API 管理（路由、文档、版本）。这一代的本质是"把通用业务逻辑从应用里剥离"。应用不再写认证、限流、监控上报，全部下沉到 gateway。代价是：gateway 成了新的单点与瓶颈。

API Gateway 是"集中式智能"的产物。它好用，但所有流量都要过它，所以它必须超稳定。

第三代：Service Proxy / Sidecar

2017 年后，Service Mesh 把"代理"拆到了每个服务旁边。Envoy、Linkerd、Cilium 成为这一代代表。这一代的核心是"把流量治理变成基础设施"。应用代码不再关心"调用 B 服务要走哪条路、要不要重试、超时多少"——这些都在 sidecar 里配置。

Envoy 为什么赢了半个世界

Envoy 的成功有几个具体原因：配置热加载（xDS 协议让配置变更不需要 reload）；可观测性原生支持（内置 stats、logging、tracing）；协议丰富（HTTP/2、gRPC、Redis、MongoDB 都支持）；L7 路由（可以按 header、path、percentage 做精细路由）。但 Envoy 不是没有代价：它的配置极度复杂，YAML 嵌套十几层是常态。所以 Istio、APISIX 等控制面都在它之上做了抽象。

第四代：eBPF 代理

2023 年后，eBPF 开始接管部分代理能力。Cilium 用 eBPF 在内核做 L4/L7 路由，绕过 sidecar。没有 sidecar，应用 pod 直接走 eBPF 程序，延迟降低、资源开销降低。但 eBPF 代理的能力边界比 Envoy 窄——复杂 L7 路由、协议解析仍不如 Envoy。所以当下的实践是"eBPF 做 L4 + Envoy 做 L7"。

三代共存的现实

真实的架构里三代是共存的：边缘入口用 nginx / API Gateway（高吞吐、强管控）；东西向流量用 Service Mesh sidecar（细粒度治理）；节点内部用 eBPF（高性能 L4）。不要把"用 Envoy"当成银弹。每一代都有它解决的问题与代价。

选型的几个判断维度

• 变更频率：频繁变更路由选 Envoy（热加载），稳定路由选 nginx。
• 协议复杂度：gRPC/HTTP3 多选 Envoy，纯 HTTP 选 nginx。
• 团队规模：小团队选 nginx，大团队选 Envoy + 控制面。
• 可观测性要求：需要细粒度 trace 选 Envoy。

代理的进化史本质上是"对流量理解加深"的历史。从"转发字节"到"理解协议"再到"治理服务"，每一代都让架构更清晰。但工具是工具，理解是理解——没有理解就用 Envoy，只会把复杂度从代码搬到 YAML。