Envoy 详解：云原生时代的高性能网络代理
文章目录
- [Envoy 详解：云原生时代的高性能网络代理](#Envoy 详解：云原生时代的高性能网络代理)
前言
Envoy 是由 Lyft 开发并于 2016 开源的高性能网络代理，现已成为 CNCF（云原生计算基金会）的毕业项目。在云原生生态中，尤其是在 Istio 等服务网格架构里，Envoy 扮演着数据平面的核心角色。本文将详细介绍 Envoy 的核心特性、架构设计、关键组件、使用场景及与其他代理的对比。
核心特性
Envoy 的设计目标是「网络对应用程序透明」，并在此指导下实现了一系列强大的功能：
- 进程外架构：Envoy 作为独立进程运行，与应用（无论使用何种语言编写）并行。这使得它可以独立升级，同时构成透明的服务通信网络。
- 强大的可观测性：原生集成丰富的指标、日志和分布式追踪能力，帮助用户了解每个请求的完整行为路径。
- 先进的流量管理：支持复杂请求匹配（路径、Header 等），实现 A/B 测试、灰度发布（金丝雀发布）、重试、超时和熔断等策略。
- 广泛的协议支持：原生支持 HTTP/1.1、HTTP/2、gRPC 和 HTTP/3，其中 HTTP 连接管理器是核心组件，负责管理 HTTP 流量的生命周期。
- 智能负载均衡与健康检查：内置多种负载均衡算法（Round Robin、Random 等），同时支持主动和被动健康检查，自动摘除不健康实例。
- 灵活的可扩展性：通过 L3/L4 过滤器（Filter）和 L7 HTTP 过滤器处理具体任务；并支持通过 WebAssembly（Wasm）或 Lua 脚本集成自定义逻辑。
架构与设计哲学
Envoy 的核心设计哲学是「数据平面与控制平面分离」。Envoy 自身只专注于高性能的数据转发，而所有配置下发和策略管理都通过标准化的 xDS API 由独立的控制平面完成。这种架构使 Envoy 极为灵活，并能适应动态的云原生环境。
Envoy 使用现代 C++ 编写，采用事件驱动、非阻塞 I/O 模型（如 epoll），从而保证了高并发下的处理性能。
核心组件与术语
理解 Envoy 需要熟悉以下几个核心抽象概念，它们共同构成了 Envoy 处理流量的完整路径。
- Downstream / Upstream（下游/上游）：发送请求的客户端称为下游，接收请求的服务称为上游。
- Listener（监听器）：Envoy 暴露的端口，负责监听并接收下游请求。
- Filter（过滤器）：插入监听器链中的可插拔逻辑单元。网络层面（L3/L4）包括 TCP/UDP 代理过滤器，以及用于 L7 入口的 HTTP 连接管理过滤器；L7 HTTP 层则包含路由、限流、认证、缓存等丰富的过滤器。
- Cluster（集群）：一组逻辑上相同的上游服务器，负责实际执行业务请求。
- Route（路由规则）：用于匹配 HTTP 请求并将其转发到对应集群的规则。
- xDS（X Discovery Service） ：一套动态获取配置的 API，是 Envoy 动态配置能力的基石。主要包括：
- LDS（Listener Discovery Service）：动态发现监听器
- RDS（Route Discovery Service）：动态发现路由规则
- CDS（Cluster Discovery Service）：动态发现上游集群
- EDS（Endpoint Discovery Service）：动态发现集群中的具体服务实例地址
- SDS（Secret Discovery Service）：动态获取 TLS 证书
xDS 协议：动态配置的基石
xDS 协议使 Envoy 能在不重启的情况下完成几乎所有配置更新，这是服务网格实现动态流量治理的基础。
- SotW（State of the World）：基础模式，控制平面发送完整的配置快照。
- Delta xDS（增量 xDS）：更高效的机制，只发送发生变化的资源，通过资源版本号和名称进行引用，大幅减少网络开销。
主要使用场景
- 服务网格数据平面：这是 Envoy 最核心的身份。作为 Istio 的默认数据平面，Envoy 以 Sidecar 形式拦截服务间流量，实现流量管理、mTLS 安全等功能。
- 边缘代理（南北向）：可作为 API 网关或 Kubernetes Ingress Controller，处理进入集群的外部流量。
- 微服务通信总线：代理微服务间的所有网络通信，提供负载均衡、服务发现、重试等能力。
- 高级负载均衡器：利用强大的流量切分和路由能力，实现 A/B 测试、蓝绿部署和灰度发布。
Sidecar 是一种分布式架构中的部署模式。它将应用程序的辅助功能（如网络代理、日志收集、监控、配置中心客户端等）以独立的进程或容器形式，与主应用部署在同一台主机（或同一个 Pod）上，共享资源（如网络栈、文件系统），并为应用提供增强能力。
这个名字来源于摩托车旁边的边斗------边斗本身不提供动力，但依附于摩托车，可以携带额外物品，扩展摩托车的功能。
1. 核心特征
共存：Sidecar 与主应用运行在相同的主机环境（例如 Kubernetes 中的同一个 Pod），共享网络命名空间和存储卷。
独立：它是独立的进程/容器，与主应用解耦，可以独立升级、重启，不影响主应用逻辑。
透明：主应用通常无需感知 Sidecar 的存在，Sidecar 通过拦截流量（例如配置 iptables）或读取共享配置来工作。
2. 在服务网格中的典型实现（Istio + Envoy）
在云原生领域，Sidecar 最著名的应用是服务网格的数据平面。以 Istio 为例：
- 每个应用 Pod 中会自动注入一个 Envoy 代理容器作为 Sidecar。
- 这个 Envoy Sidecar 负责：
- 拦截所有进出应用的流量（HTTP、gRPC、TCP 等）。
- 实现服务发现、负载均衡、熔断、重试、超时等流量治理。
- 自动启用 mTLS 加密和认证。
- 生成详细的遥测数据（指标、日志、追踪）。
- 应用容器只需要关心业务逻辑，完全不需要修改代码，即可获得完整的服务网格能力。
与其他代理的对比（Envoy vs Nginx）
| 特性维度 | Envoy | Nginx |
|---|---|---|
| 架构理念 | 数据/控制平面分离，动态、云原生，配置实时推送 | 传统单体、基于静态文件，配置更新较慢 |
| 可扩展性 | 原生支持 Wasm/Lua，内置 JWT 验证等过滤器 | 依赖模块，复杂逻辑常用 Lua 或第三方模块 |
| HTTP 吞吐量 | 约 8 万 RPS（启用七层处理后差距缩小） | 约 10 万 RPS，经典代理吞吐稍占优势 |
| P99 延迟 | 约 2 ms（多线程及无锁设计优势） | 约 5 ms |
| 内存占用 | 约 150 MB/Pod，资源受限环境需注意 | 约 50 MB/Pod |
| 服务网格集成 | 原生支持，是 Istio 等主流服务网格的数据平面 | 非原生，需复杂工具集成 |
部署模式与未来演进
- Sidecar 模式与 Ambient Mesh ：在 Istio 中，Envoy 最常见的部署方式是 Sidecar 模式，即每个应用 Pod 内注入一个独立的 Envoy 容器。如今也出现了 Ambient Mesh 模式，旨在减少 Sidecar 资源开销，通过节点级的四层代理（ztunnel）和可选命名空间的七层代理（Waypoint Proxy）实现服务网格功能。
- 最新版本与演进：Envoy 保持快速迭代，持续强化如 WebAssembly（Wasm）扩展、HTTP/3 性能优化以及对 Kafka、MongoDB 等更多 L7 协议的深度支持。
总结
Envoy 不仅仅是传统的反向代理，而是为云原生时代设计的通信总线和网络架构中心。它通过数据/控制平面分离、动态配置、强大的可观测性和灵活的可扩展性，成为构建现代化大规模分布式系统不可或缺的基石。无论作为服务网格的数据平面、边缘网关还是高级负载均衡器，Envoy 都展现出了卓越的性能和适应性。
如果你正考虑在实际环境中使用 Envoy，可以结合自己的云环境（例如 Kubernetes）进一步探索其具体配置和最佳实践。