1. 服务网格与Envoy概述

1.1 服务网格架构演进

服务网格（Service Mesh）是云原生时代处理服务间通信的基础设施层。其架构演进经历了从“硬编码通信”到“透明代理”的四个关键阶段：

1.2 Envoy 作为数据平面的核心角色

Envoy 是一个高性能、可编程的 L7 代理，由 Lyft 于 2016 年开源，现为 CNCF 毕业项目。在服务网格中，Envoy 承担以下核心职责：

• 流量拦截与转发： 通过 iptables 或 eBPF 透明劫持 Pod 内所有入站/出站流量，基于动态路由规则转发到目标服务。
• 协议解析与治理： 原生支持 HTTP/1.1、HTTP/2、gRPC、TCP、MongoDB 等协议，可执行请求头修改、重定向、限速、熔断等策略。
• 可观测性数据采集： 自动生成访问日志、分布式追踪（Trace）、Prometheus 指标（Metrics），为延迟水位和异常事件分析提供原始数据。
• TLS 终止与 mTLS： 在 Sidecar 层面完成证书交换和双向认证，业务容器无需感知加密逻辑。
• 负载均衡与健康检查： 支持加权轮询、最少请求、一致性哈希等算法，结合主动/被动健康检查剔除异常端点。

1.3 Sidecar 代理模式

Sidecar 模式是服务网格的核心部署形态：在每个业务 Pod 中，额外运行一个 Envoy 容器作为“边车”，与主业务容器共享网络命名空间。其工作原理如下：

1. 流量劫持： Pod 启动时，Init 容器配置 iptables 规则，将所有进出流量重定向到 Envoy 的 15001（出站）和 15006（入站）端口。
2. 透明代理： 业务容器完全感知不到 Envoy 的存在，所有 HTTP/gRPC 请求被 Envoy 拦截后，根据动态路由规则转发到目标服务。
3. 双向观测： Envoy 在请求经过时记录延迟、状态码、请求大小等指标，并生成分布式追踪 Span，上报到 Prometheus 和 Jaeger/Zipkin。
4. 策略执行： 熔断、重试、超时、限速、流量镜像等策略在 Envoy 层执行，业务代码无需任何改动。

1.4 Envoy 在可观测性中的关键价值

作为服务网格的数据面，Envoy 天然处于所有服务间流量的“必经之路”，这使得它成为构建流量拓扑、延迟水位和异常事件观测系统的理想数据源：

• 流量拓扑自动发现： Envoy 通过 CDS/EDS 获取集群和端点信息，结合访问日志中的 source/destination 字段，可自动绘制服务依赖关系图。
• 延迟水位实时监控： Envoy 内置的 upstream_rq_time 直方图指标按百分位（P50/P90/P99）统计上游请求延迟，配合 Istio 的 Telemetry v2 可生成服务级别的延迟热力图。
• 异常事件关联分析： 当 Envoy 返回 5xx、连接超时、熔断打开等事件时，其访问日志和指标可精确关联到故障端点、路由规则和 TLS 握手状态，大幅缩短排障 MTTR。