kaikai's wiki

Envoy 官方文档：设计哲学与核心特性

7分钟阅读

核心要点

Envoy 的设计哲学可以用一句话概括：让网络对应用透明，并在出问题时有能力定位根因。这个目标的实现方式不是给每个应用语言写一个库，而是提供一个独立的、语言无关的、可独立升级的网络代理进程。

进程外架构：为什么不是库

Envoy 选择作为独立进程运行在每个应用服务器旁边，所有 Envoy 共同构成一个透明通信网格：应用只与 localhost 通信，对网络拓扑一无所知。

这个决策的两个关键收益：

  1. 语言无关：一个 Envoy 部署可以同时桥接 Java、C++、Go、PHP、Python 等服务。在现代多语言、多框架的服务架构中，这是巨大的简化。
  2. 独立升级：任何维护过大型服务架构的人都知道，库升级的痛苦。Envoy 作为独立进程，可以在整个基础设施上快速、透明地部署和升级，无需协调各应用团队的发布节奏。

这个选择也有代价：进程间通信的额外开销、sidecar 模式带来的资源消耗、运维复杂度的增加。但 Envoy 的赌注是：网络行为的统一治理比节省一点 CPU 更重要。

过滤器架构：L3/L4 与 L7 的分层扩展

Envoy 的核心是一个可插拔过滤器链：

  • L3/L4 网络过滤器：支持 TCP/UDP 代理、TLS 客户端证书认证、Redis、MongoDB、Postgres 等协议代理
  • HTTP L7 过滤器：在 HTTP 连接管理子系统中插入，支持缓冲、速率限制、路由/转发、DynamoDB 嗅探等

这种分层设计让 Envoy 既能作为通用网络代理，又能针对 HTTP 生态做深度优化。同一套过滤器机制被复用到完全不同的协议层，降低了扩展的心智负担。

协议支持：HTTP/2、gRPC 与 HTTP/3

Envoy 对 HTTP/2 的一流支持是其作为服务网格基础设施的关键：

  • 支持 HTTP/1.1 与 HTTP/2 的双向透明桥接
  • 服务间通信推荐使用 HTTP/2，建立持久连接池，请求和响应可以多路复用
  • gRPC 天然兼容：gRPC 基于 HTTP/2，Envoy 提供所有必要的路由和负载均衡能力
  • HTTP/3（基于 QUIC）从 1.19.0 开始支持上游和下游，尚处于 alpha

HTTP/2 多路复用在微服务场景中的价值被低估：它减少了 TCP 连接数，降低了延迟抖动，让负载均衡决策可以在请求级别而非连接级别进行。

服务发现与动态配置

Envoy 支持分层动态配置 API：

  • 后端集群内的主机列表
  • 后端集群本身
  • HTTP 路由规则
  • 监听端口
  • 加密材料

最简单的部署可以用 DNS 做后端发现（或完全跳过服务发现，使用静态配置），复杂的部署可以用 xDS API（ADS/CDS/EDS/LDS/RDS/SDS）实现完全动态、中心化管理。

Envoy 的推荐做法是把服务发现视为最终一致的过程，结合主动健康检查和异常检测（outlier detection）来确定真正可用的负载均衡目标。

高级负载均衡与弹性

Envoy 在单一位置实现了多种高级负载均衡技术，对所有接入应用透明可用：

  • 自动重试：按配置条件自动重试失败请求
  • 熔断：当后端错误率或延迟超过阈值时自动停止发送流量
  • 全局速率限制：通过外部限速服务（如 RLS）实现跨集群配额
  • 请求镜像：复制流量到影子集群做测试
  • 异常检测：被动健康检查，自动驱逐异常实例

未来还计划支持 request racing（同时向多个后端发送请求，取最快响应）。

可观测性：Envoy 真正的差异化

Envoy 的所有子系统都暴露统计指标（statsd 兼容），并支持分布式追踪。但它的可观测性设计有一个深层假设：网络问题可能是应用问题，应用问题可能表现为网络症状。通过统一的代理层收集指标和追踪，可以在网络行为和应用行为之间建立关联，这是”让网络透明”目标的最终实现。

实践启示

  • Envoy 不是”比 Nginx 更快的反向代理”，它是一个服务到服务通信的基础设施抽象。选择 Envoy 意味着你愿意为统一治理付出 sidecar 的运维成本。
  • 如果你已经在用 Kubernetes，Istio/Envoy 的 sidecar 模式是常见组合，但也在向 ambient mesh（无 sidecar）演进。Envoy 本身的定位不限定于任何部署模式。
  • Envoy 的 xDS API 是控制面的标准接口，理解 xDS（ADS/CDS/EDS/LDS/RDS/SDS）是操作 Envoy 集群的基础。

来源信息

相关页面

关系图谱

反向链接