1. Envoy 概述：诞生背景、核心特性与云原生定位

1.1 诞生背景：从单体到微服务的代理困境

在微服务架构大规模普及之前，应用流量管理通常由硬件负载均衡器（F5、A10）或软件负载均衡（Nginx、HAProxy）承担。随着服务拆分粒度变细、容器化与编排平台（Kubernetes）成为主流，传统代理暴露出以下痛点：

• 配置静态化：Nginx/HAProxy 依赖静态配置文件，无法动态响应后端实例的频繁扩缩容。
• 可观测性缺失：传统代理缺乏分布式追踪、结构化日志和细粒度指标输出，故障定位困难。
• 协议支持有限：对 HTTP/2、gRPC、MongoDB、Redis 等现代协议的支持不完善或性能不佳。
• 重启中断流量：配置变更或版本升级需要重启进程，导致连接断开，无法满足高可用要求。

Lyft 公司在 2016 年开源了 Envoy，旨在解决上述问题。Envoy 被设计为面向服务网格（Service Mesh）的通用数据平面，以 sidecar 模式与每个服务实例一同部署，接管所有进出流量。

1.2 核心特性

Envoy 的核心特性可归纳为三大支柱：L4/L7 代理能力、可观测性和热重启。下表对比了 Envoy 与传统代理在这些维度的差异：

1.3 可观测性详解

Envoy 将可观测性作为一等公民，无需额外插件即可输出三类关键数据：

• 指标（Metrics）：通过 /stats/prometheus 端点暴露 Prometheus 格式指标，涵盖请求总数、延迟分布、错误码、连接池状态、熔断器状态等。
• 日志（Logging）：支持自定义访问日志格式，可记录请求路径、响应码、上游主机、请求头、耗时等字段，输出到标准输出或文件。
• 分布式追踪（Tracing）：原生支持 Zipkin、Jaeger、Datadog、OpenTelemetry 等协议，通过 x-request-id 和 x-b3-traceid 等头部传递上下文。

1.4 热重启机制

Envoy 的热重启（Hot Restart）是其高可用设计的核心。它允许在不丢失任何已建立连接的情况下，完成配置更新或二进制升级。其工作原理如下：

1. 共享内存：旧进程和新进程通过共享内存区域交换监听套接字和连接状态。
2. Unix Domain Socket：新进程启动后，通过 UDS 向旧进程发送信号，请求接管监听套接字。
3. 连接迁移：旧进程将活跃连接的文件描述符传递给新进程，新进程继续处理这些连接。
4. 旧进程退出：当所有连接迁移完毕或超时后，旧进程优雅关闭。

1.5 在云原生架构中的定位

Envoy 在云原生生态中扮演数据平面（Data Plane）的核心角色，与控制平面（Control Plane）（如 Istio Pilot、Consul Connect、Kuma）配合，构成完整的服务网格。其定位可概括为：

• Sidecar 代理：以 sidecar 容器形式与业务容器同 Pod 部署，拦截所有进出流量，实现流量治理、安全策略和可观测性。
• API 网关/入口代理：作为集群入口（Ingress Gateway），处理南北向流量，支持 TLS 终止、路由、限流、认证等。
• 边缘代理：部署在集群边界，作为负载均衡器或反向代理，连接外部客户端与内部服务。
• 通用数据平面：通过 xDS 协议与控制平面交互，动态获取路由、监听器、集群、端点、密钥等配置。

下图展示了 Envoy 在云原生架构中的典型部署位置与数据流：

1.6 关键设计原则

Envoy 的架构设计遵循以下原则，使其在云原生环境中具备独特优势：