文档
前言
在微服务架构中，服务间通信变得极其复杂。Envoy 扮演着"透明的中间人"角色——它不改变你的代码，但完全接管了网络层。理解 Envoy 是理解 Service Mesh 的关键。
第一章：Sidecar 模式
1.1 什么是 Sidecar
传统架构：
Service A → 直接 → Service B
Service Mesh（Sidecar）：
Service A → Envoy Sidecar → mTLS → Envoy Sidecar → Service B
(outbound) (inbound)
每个服务实例旁边（同一个 Pod/VM）都有一个 Envoy，拦截所有进出流量。
1.2 为什么用 Sidecar
| 方面 | 传统 SDK | Sidecar (Envoy) |
|---|---|---|
| 语言绑定 | 每种语言都需 SDK | 零侵入，任何语言 |
| 升级 | 更新所有服务 | 只升级 Sidecar |
| 故障隔离 | 库 bug 影响服务 | 独立进程，故障隔离 |
| 治理能力 | SDK 决定 | Envoy 统一提供 |
第二章：Envoy 核心概念
2.1 四大组件
┌─────────────────────────────────┐
│ Listener（监听器） │
│ ↓ 接收连接，应用 Filter Chain │
├─────────────────────────────────┤
│ Filter（过滤器） │
│ ↓ HTTP/Router/RBAC/限流... │
├─────────────────────────────────┤
│ Route（路由表） │
│ ↓ 匹配规则 → 选择 Cluster │
├─────────────────────────────────┤
│ Cluster（集群） │
│ ↓ 负载均衡 + 熔断 → Endpoint │
└─────────────────────────────────┘
2.2 xDS 协议
Envoy 配置通过 xDS（Discovery Service）动态下发：
| xDS | 全称 | 功能 |
|---|---|---|
| LDS | Listener DS | 监听器配置 |
| RDS | Route DS | 路由表 |
| CDS | Cluster DS | 后端集群 |
| EDS | Endpoint DS | 具体实例地址 |
| SDS | Secret DS | TLS 证书 |
2.3 两种配置模式
静态配置（static_resources）
→ 适合开发/简单场景
→ 修改需重启
动态配置（dynamic_resources + xDS）
→ 适合生产/Service Mesh
→ 控制平面（Istio/自定义）实时下发
第三章：Envoy 高级负载均衡
3.1 负载均衡策略
# 加权轮询（默认）
lb_policy: ROUND_ROBIN
# 最少请求
lb_policy: LEAST_REQUEST
# 随机
lb_policy: RANDOM
# 一致性哈希（会话保持）
lb_policy: RING_HASH
hash_policy:
- header: { header_name: "X-User-Id" }
# 区域感知（优先同区域）
lb_policy: ROUND_ROBIN
locality_weighted_lb_config: {}
3.2 异常检测（主动健康检查）
outlier_detection:
consecutive_5xx: 5 # 连续 5 次 5xx → 剔除
interval: 10s # 每 10s 检查一次
base_ejection_time: 30s # 剔除 30s
max_ejection_percent: 50 # 最多剔除 50%
3.3 优先级路由
P0: 本地 zone 的实例（低延迟）
P1: 同 region 的实例
P2: 其他 region（降级）
当 P0 健康比例 < threshold 时自动降级到 P1
第四章：可观测性
4.1 内置统计
# 查看所有指标
curl http://localhost:9901/stats
# 关键指标
cluster.backend_v1.upstream_rq_total # 请求总数
cluster.backend_v1.upstream_rq_2xx # 2xx 数量
cluster.backend_v1.upstream_rq_time # 请求耗时直方图
cluster.backend_v1.upstream_cx_connect_fail # 连接失败
4.2 Prometheus 集成
# 在 admin 下配置（注意：仅在纯 Envoy 模式下）
stats_sinks:
- name: envoy.stat_sinks.metrics_service
typed_config:
"@type": type.googleapis.com/envoy.config.metrics.v3.MetricsServiceConfig
transport_api_version: V3
grpc_service:
envoy_grpc:
cluster_name: prometheus_stats
第五章：Envoy vs Nginx vs HAProxy
| 特性 | Envoy | Nginx | HAProxy |
|---|---|---|---|
| 动态配置 | ✅ xDS 原生 | ❌ 需 Plus 版 | ✅ Runtime API |
| gRPC 代理 | ✅ 原生 | ❌ 需 Plus | ❌ 有限 |
| Service Mesh | ✅ Istio 默认 | ❌ | ❌ |
| 可观测性 | ✅ 极其丰富 | ⭐ 基础 | ⭐⭐ |
| C++ 实现 | ✅ | ✅ | ✅ |
| Lua 扩展 | ❌（WASM） | ✅ | ✅ Lua |
| 学习曲线 | 陡峭 | 中等 | 低 |
思考题
- Envoy 为什么要用 xDS 动态配置而不是配置文件热加载？xDS 有什么独特优势？
- Sidecar 模式增加了网络链路（多一跳），如何最小化这个延迟开销？
- Istio 使用 Envoy 作为 Sidecar，但 Envoy 也可以独立作为 API 网关使用。这两种场景下配置有什么不同？
- Envoy 的异常检测和熔断有什么区别？为什么需要两个独立的机制？
下一步
- 学习 Istio + Envoy 搭建完整 Service Mesh
- 学习 Envoy WASM 插件开发
- 学习 Envoy 作为 Kubernetes Ingress Controller