Envoy 详解：云原生时代的高性能网络代理

Envoy 详解云原生时代的高性能网络代理文章目录Envoy 详解云原生时代的高性能网络代理前言核心特性架构与设计哲学核心组件与术语xDS 协议动态配置的基石主要使用场景与其他代理的对比Envoy vs Nginx部署模式与未来演进总结前言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 过滤器处理具体任务并支持通过 WebAssemblyWasm或 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 请求并将其转发到对应集群的规则。xDSX Discovery Service一套动态获取配置的 API是 Envoy 动态配置能力的基石。主要包括LDSListener Discovery Service动态发现监听器RDSRoute Discovery Service动态发现路由规则CDSCluster Discovery Service动态发现上游集群EDSEndpoint Discovery Service动态发现集群中的具体服务实例地址SDSSecret Discovery Service动态获取 TLS 证书xDS 协议动态配置的基石xDS 协议使 Envoy 能在不重启的情况下完成几乎所有配置更新这是服务网格实现动态流量治理的基础。SotWState 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特性维度EnvoyNginx架构理念数据/控制平面分离动态、云原生配置实时推送传统单体、基于静态文件配置更新较慢可扩展性原生支持 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 保持快速迭代持续强化如 WebAssemblyWasm扩展、HTTP/3 性能优化以及对 Kafka、MongoDB 等更多 L7 协议的深度支持。总结Envoy 不仅仅是传统的反向代理而是为云原生时代设计的通信总线和网络架构中心。它通过数据/控制平面分离、动态配置、强大的可观测性和灵活的可扩展性成为构建现代化大规模分布式系统不可或缺的基石。无论作为服务网格的数据平面、边缘网关还是高级负载均衡器Envoy 都展现出了卓越的性能和适应性。如果你正考虑在实际环境中使用 Envoy可以结合自己的云环境例如 Kubernetes进一步探索其具体配置和最佳实践。