Envoy透明代理流量劫持部署与调试 - 第1节
1.1 Envoy 的发展历史
Envoy 最初由 Lyft 的 Matt Klein 于 2015 年设计并开源，旨在解决微服务架构中日益复杂的网络通信问题。2016 年，Envoy 被捐赠给 Cloud Native Computing Foundation（CNCF），并于 2017 年成为 CNCF 的毕业项目，与 Kubernetes、Prometheus 等并列为核心基础设施。
| 时间节点 | 里程碑事件 | 核心意义 |
|---|---|---|
| 2015 年 | Lyft 内部研发并开源 Envoy | 解决大规模微服务通信的痛点 |
| 2016 年 | 捐赠给 CNCF 基金会 | 进入社区治理，加速生态发展 |
| 2017 年 | 成为 CNCF 毕业项目 | 生产级成熟度得到官方认可 |
| 2019 年至今 | 成为 Istio 默认数据面 | 奠定服务网格数据面标准地位 |
关键洞察： Envoy 的诞生并非从零造轮子，而是对 Nginx、HAProxy 等传统代理在动态配置、可观测性、多协议支持等方面的不足进行系统性重构的结果。
1.2 核心设计理念
Envoy 的设计哲学围绕三个核心原则展开，这些原则直接决定了它在透明代理和流量劫持场景中的卓越表现。
- 透明性（Transparency）： 对应用层代码零侵入，通过 iptables、eBPF 或逻辑劫持机制将流量透明地导入代理。
- 可编程性（Programmability）： 提供 xDS 动态配置 API，支持运行时热更新路由、监听器、集群等所有配置。
- 可观测性（Observability）： 内置分布式追踪、全量访问日志、Prometheus 指标，无需额外埋点。
透明代理基础： Envoy 的透明劫持能力依赖于操作系统层面的流量重定向（如 iptables REDIRECT/TPROXY），Envoy 本身只负责处理被劫持后的 L4/L7 流量，不参与内核包过滤。
1.3 在服务网格中的角色定位
在服务网格架构中，Envoy 作为 数据面（Data Plane） 的核心组件，承担所有服务间通信的代理职责。控制面（如 Istiod）通过 xDS 协议向 Envoy 下发配置，Envoy 则负责执行实际的流量转发、负载均衡、健康检查、熔断限流等策略。
注意： 在透明代理场景中，Envoy 通常以 Sidecar 模式部署，应用容器完全不知道 Envoy 的存在。所有出站和入站流量通过 iptables 规则被透明地劫持到 Envoy 的监听端口，Envoy 再根据控制面下发的路由规则进行转发。
1.4 Envoy 与传统代理的对比
| 特性维度 | Envoy | Nginx / HAProxy |
|---|---|---|
| 配置方式 | 动态 xDS API，运行时热更新 | 静态文件，需 reload 或重启 |
| 多协议支持 | HTTP/1.1、HTTP/2、gRPC、TCP、UDP、MongoDB、Redis 等 | 以 HTTP/TCP 为主，扩展性有限 |
| 可观测性 | 内置分布式追踪、全量日志、Prometheus 指标 | 需额外插件或模块 |
| 透明劫持 | 原生支持 TPROXY、ORIGINAL_DST 等透明代理模式 | 需复杂配置，部分模式不支持 |
| 社区生态 | CNCF 毕业项目，Istio 默认数据面 | 独立项目，非服务网格原生 |