Envoy 与 L7 代理工程

• Listener、Route、Cluster、Endpoint 四层抽象
• xDS 各子协议的作用
• 转发链路协同

Envoy 的转发链路由四层抽象构成：Listener（监听器）定义监听的端口与过滤链，Route（路由）定义请求如何匹配与分发，Cluster（集群）定义上游服务组及其负载均衡策略，Endpoint（端点）是集群中的具体实例。协同通过 xDS 完成：LDS 下发监听器，RDS 下发路由，CDS 下发集群，EDS 下发端点。工作流程：请求到达 Listener，经过滤链匹配 HTTP 路由（RDS），路由指向 Cluster（CDS），Cluster 通过负载均衡选择 Endpoint（EDS），把请求转发到具体实例。四层通过 xDS 动态更新，任意一层变化都会实时下发，实现配置与流量的动态协同。

理解四层抽象是理解 Envoy 的钥匙：Listener 是"入口"，Route 是"判断"，Cluster 是"目标组"，Endpoint 是"具体实例"。xDS 让这四层都能动态更新，驱动了服务网格的声明式配置。排障时也用这四个维度（listener/route/cluster/endpoint）定位。

• 网络过滤器与 HTTP 过滤器
• dynamic metadata 共享上下文
• 自定义过滤器开发（C++/Wasm/Lua）

Envoy 的过滤器链分为网络过滤器（L3/L4，处理 TCP 连接层）与 HTTP 过滤器（L7，处理 HTTP 请求/响应），两者串联处理流量。过滤器通过 dynamic metadata（动态元数据）共享请求上下文：任何一个过滤器可以在 request/connection 的 metadata 中写入数据（如路由结果、鉴权结果、自定义属性），后续过滤器（如日志、限流、统计）可读取该 metadata，实现过滤器间的数据传递，无需修改报文。自定义过滤器开发：可用 C++ 编写原生过滤器（性能最好但需编译），或用 Lua 脚本（轻量快速，用于简单逻辑），或用 Wasm（跨语言、隔离、可热更新，但有一定性能与调试开销）。自定义过滤器通过 EnvoyFilter 或编程式接入并挂载到过滤器链。

过滤器链是 Envoy 可扩展性的核心，dynamic metadata 是其协作机制。理解"过滤器串联 + metadata 共享"模型，才能实现复杂处理（如鉴权后把结果传给日志、限流）。自定义过滤器选型要权衡性能、开发成本与维护性，多数场景用 Lua/Wasm 更合适。

• 熔断（circuit breaker）阈值
• 重试策略（retry policy）
• 超时（timeout）配置

三级防护从不同层面保护系统：熔断（circuit breaker）：在 cluster 配置连接池与熔断阈值（如 max_connections、max_pending_requests、max_requests），当后端故障导致阈值超限时，Envoy 直接快速失败（503）而不进入后端，保护后端不被压垮。重试（retry policy）：在 route 配置 retry_on（如 connect-failure、5xx）、retries 次数与 per-try timeout，当请求失败时按策略重试，提高成功率。超时（timeout）：在 route 配置请求超时（timeout）与每次重试的 per-try timeout，避免请求无限等待。协同逻辑：超时兜底（不无限等待）→ 重试提升成功率 → 熔断保护后端，三者结合形成"快速失败 + 有限重试 + 后端保护"的弹性体系。注意重试需配合幂等性，避免重试风暴，熔断需配置合理的探测阈值。

三级防护是"按需组合"的弹性设计：超时设上限、重试提高成功率、熔断保护后端。配置时需平衡：重试过多会放大压力，超时过短会导致误失败，熔断过严会拒绝正常流量。理解三者关系，才能配置出"既高可用又保护后端"的策略。

• 全量（SotW）与增量（delta）xDS
• ACK/NACK 机制
• 下发失败的降级行为

xDS 支持全量（State of the World，SotW）与增量（delta）两种推送方式：全量推送每次下发完整配置，增量推送只下发变化部分，减少带宽与处理开销。Envoy 收到配置后返回 ACK（确认成功）或 NACK（校验失败），控制面依据 ACK/NACK 判断配置是否被接受。缓存与降级：Envoy 会缓存最后成功下发的配置，当控制面下发失败（如配置校验不通过、连接中断）时，Envoy 保留并使用最后的好配置继续转发，不会因坏配置导致流量中断；同时 NACK 会让控制面知道配置被拒绝，避免重复下发错误配置。控制面长时间不可用时，Envoy 基于缓存配置继续运行，但新配置无法生效。

ACK/NACK 是 xDS 的"校验反馈"机制，缓存是"降级兜底"机制。Envoy 对坏配置 NACK 并保留旧配置，保证配置变更不破坏现有流量。理解这一机制，才能理解为什么"配置错了但流量还在"以及"配置变更未生效"这类现象。

• Listener/Cluster/Endpoint 的职责
• Filter 在监听器中的挂载
• 配置层级关系

Envoy 的配置层级关系：最外层是 Listener（监听器），它定义端口与处理链，在其过滤链中挂载 Network Filter（L3/L4）与 HTTP Filter（L7）；路由通过 HTTP 路由（Route）匹配后把请求导向 Cluster（集群）；Cluster 定义上游服务集、负载均衡与连接池，并引用 Endpoint（端点）作为具体实例。因此层级为：Listener → Filter 链 → Route → Cluster → Endpoint。Filter 属于 Listener 的过滤链，在请求到达路由前处理；Cluster 是路由的目标，Endpoint 是 Cluster 的成员。配置可通过静态文件或 xDS 动态下发。

理解层级关系是配置 Envoy 的基础：Listener 是"入口+处理链"，Filter 是"处理器"，Route 是"分发器"，Cluster 是"目标池"，Endpoint 是"实例"。排障时按这个层级（listener→route→cluster→endpoint）逐层定位，与 xDS 治理的维度一致。

• 各算法原理
• 适用场景
• 与一致性/容缓存的关系

轮询（Round Robin）：将请求均匀分配到各端点，适合各端点能力相近、无状态的服务，简单但无法感知端点负载差异。最少请求（Least Request）：优先选择当前请求数最少的端点，适合端点处理能力或负载不均的场景，能更好平衡动态负载。一致性哈希（Consistent Hashing）：基于请求哈希（如 hash_key、cookie）把相同 key 的请求固定到同一端点，适合需要会话保持（session affinity）或缓存本地化的场景，且在端点变化时只影响少量 key。Maglev：一种快速一致性哈希，哈希表查找 O(1)，性能优于普通一致性哈希，适合高 QPS、需要一致性哈希且追求性能的场景。选型依据：是否需要会话保持/缓存亲和（选哈希类）、负载是否动态不均（选最少请求）、吞吐要求高（选 Maglev/RoundRobin）。

负载均衡算法选型取决于"是否需要一致性"与"负载是否均衡"。无状态高吞吐用轮询；负载动态不均用最少请求；会话保持/缓存亲和用一致性哈希，高吞吐场景用 Maglev。选型要与业务特性匹配，避免盲目追求高级算法。

• 过滤器链的扩展点
• 限流过滤器（本地/全局限流）
• 鉴权过滤器（ext_authz）

Envoy 的过滤器链是扩展机制的核心：接入点（filter chain）中可挂载各种过滤器，内置了限流与鉴权等扩展。限流：内置 rate_limit 过滤器，可对接本地限流（local rate limit）或全局限流服务（RLS，Rate Limit Service），在请求路径上按规则限流。鉴权：内置 ext_authz 过滤器，把请求转发给外部鉴权服务（如 OPA、自定义服务）做授权检查，返回允许/拒绝决定，也可用 JWT 过滤器在内置 JWT 校验。此外可通过 Lua/Wasm 自定义过滤器实现任意业务逻辑。这些过滤器按顺序挂载在过滤链上，协同完成限流、鉴权、路由等处理。

过滤器链的"可插拔"让 Envoy 具备丰富的扩展能力：内置限流与鉴权过滤器可声明式启用，external 服务可接入复杂鉴权逻辑，Wasm/Lua 可自定义。理解扩展机制，才能按需组合出符合业务的安全与治理能力。

• 路由规则
• 本地与全局限流
• 重试策略协同

在 HTTP 路由（Route）上可叠加多种 L7 能力：路由规则定义请求如何匹配与分发（前缀、Header、权重）；本地限流（rate_limit 的 local_rate_limit）在代理本地按阈值限流，适合简单场景与边缘保护；全局限流（rate_limit 对接 RLS 服务）基于全局统计（如按用户/IP 维度）限流，适合多实例共享额度；重试策略（retry）在请求失败时重试。协同配置：限流在前（防止过载），路由决定分发，重试在后（失败提升成功率）。组合时注意：限流与重试可能冲突（限流触发后重试会放大压力），需合理配置重试预算与限流阈值。

L7 能力组合的关键是"顺序与目标"：限流保护入口、路由决定去向、重试保障成功率。三者协同可构建既有防护又高可用的一层。配置时需平衡限流与重试的相互作用，避免限流引发的重试风暴。

• config dump 的获取与结构
• bootstrap/listener/cluster 配置
• 定位异常

Envoy 的 config dump 可通过 admin 接口（/config_dump）或 istioctl proxy-config all <pod> 获取，包含 bootstrap（启动配置）、listeners（监听器）、routes（路由）、clusters（集群）、endpoints（端点）、secrets（证书）等部分。定位异常：先看 clusters 的动态配置（dynamic_active_clusters）确认集群是否被正确创建、端点是否健康（endpoints 的 healthy 状态）；再看 listeners 确认监听器与路由是否正确下发；看 routes 确认路由匹配是否符合预期；看 secrets 确认证书状态。若某资源缺失或 health 状态异常，即可定位到对应配置问题。格式通常为 JSON，可配合 jq 解析。

config dump 是"代理实际运行态"的窗口，反映 xDS 下发的最终配置。排障时用它确认"预期的配置是否真的在代理上生效"，与预期配置对比即可发现配置缺失、端点不健康、证书异常等问题。是判断"配置 vs 实际"的最直接手段。

• worker 线程（concurrency）配置
• 连接池大小
• buffer 限制

worker 线程数：Envoy 用 --concurrency 或 concurrency 配置 worker 线程数（默认与 CPU 核数一致），用于处理并发连接与事件；线程过多会导致上下文切换开销，过少会限制吞吐，需按实际并发与 QPS 调整。连接池大小：在 cluster 的 connection_pool 配置 TCP/HTTP 连接池的最大连接数（max_connections、max_requests_per_connection），控制与上游的连接规模，避免连接过多导致资源消耗。buffer 限制：监听器与 cluster 的 per_connection_buffer_limit_bytes 配置单连接缓冲区上限，防止大数据量导致内存膨胀。调优需结合压测（QPS、P99、内存）确定最优参数，避免盲目调整。

性能调优是"资源与吞吐的平衡"：worker 线程匹配并发处理能力，连接池控制上游连接规模，buffer 限制内存占用。三者结合压测结果调整，才能即满足吞吐又不过度占用资源。是网关/代理性能优化的重要维度。

• admin 接口的端点
• config_dump 与 stats
• 健康检查

Envoy 的 admin 接口（默认 15000 端口）提供多个诊断端点：/config_dump 输出当前生效配置（listener/cluster/route/endpoint），用于对比预期配置；/stats 输出运行时统计（连接数、请求数、重试、熔断、超时等），用于观察运行时行为；/clusters 展示各集群的端点健康状态与负载均衡统计；/healthcheck 可触发健康检查；/server_info 显示版本与运行信息。排障流程：先看 /clusters 确认端点健康、再看 /stats 看错误指标（如重试、熔断、超时计数）、必要时用 /config_dump 对比配置。三者结合：健康状态定位"后端是否可用"，stats 定位"发生了什么"，config_dump 定位"配置是否正确"。

admin 接口是 Envoy 的"控制台"，config_dump 看配置、stats 看运行、clusters 看健康。用这三个维度组合，能快速区分"配置问题、后端问题、运行时问题"。是代理排障的核心入口。

• access log 的格式与字段
• 日志输出配置
• Trace 传播集成

Envoy 的访问日志通过 access_log 配置，每个 Listener 或 HTTP 过滤器可设置 access log，包含格式（format）与输出（file/grpc/自定义）。格式用格式化指令（如 %REQ(:METHOD)%、%RESPONSE_CODE%、%UPSTREAM_CLUSTER%、%DURATION% 等）定义字段，可输出到 stdout 文件或 grpc 服务并接入日志采集。Trace 传播集成：Envoy 会在请求中生成/保留 trace 头（如 x-b3-*、traceparent），并可通过 access log 的 %REQ(X-B3-TRACEID)% 等字段输出 trace id，使访问日志与追踪链路（Jaeger/OTel）通过 trace id 关联，实现日志与链路追踪的打通。配置是在 access log 中加载 trace 相关字段，实现排障时从日志跳转到对应链路。

访问日志是"每请求的可观测性"，接入点是在 Envoy 的 access_log 中定义格式与输出。通过输出 trace id（和 trace 系统共享同一上下文），实现日志与链路追踪的关联，是"日志+追踪"协同排障的关键。

• 热重启机制
• 优雅排空与新旧进程过渡
• 配置变更无损

Envoy 的进程热重启（hot restart）允许在不停机的情况下升级二进制或重启进程：新进程启动后通过共享内存与旧进程协商，旧进程把对监听器/连接的所有权移交（handoff）给新进程，新进程接管后旧进程再退出，期间已建立的连接不中断。热重启配合优雅排空（drain）：配置变更时，新配置先加载，旧监听器/连接在排空（drain-time）完成后才关闭，保证正在处理的请求完成。高可用方面，Envoy 通常多副本部署，配合健康检查由负载均衡/调度器感知故障，实现故障转移。配置变更无损的核心是"新接旧、先建后删、排空过渡"。

热重启与优雅排空是 Envoy"无损变更"的两大机制：热重启让进程升级不中断，排空让配置变更平滑过渡。理解"所有权移交 + 排空"机制，才能在做代理升级或配置变更时保证不丢连接。

• virtual host 的职责
• 路由匹配（前缀/正则/路径）
• 优先级与顺序

Envoy 的路由组织分层：virtual host 按域名（Host）分组，每个 virtual host 包含一组路由（routes）。路由匹配有多种方式：前缀匹配（prefix，如 /api/）、精确路径（path）、正则（regex，如 safe_regex）、Header 匹配与查询参数匹配。匹配优先级：路由按在 virtual host 中的顺序评估，先匹配先命中；若未指定顺序，则按类型优先级（精确路径 > 前缀 > 正则）处理。virtual host 之间通过请求的 Host 头选择。组织上，一个 Listener 的 HTTP 过滤链加载 virtual host 集合，virtual host 内按规则顺序评估路由，匹配后分发到对应 cluster。

路由匹配的本质是"按 Host 选 virtual host，按规则顺序/优先级选 route"。理解"virtual host 归组 + 路由匹配顺序（精确>前缀>正则）"才能正确配置路由，避免规则顺序导致误匹配。排障时也是检查 Host 与路由顺序。

• Lua 过滤器的特点
• Wasm 过滤器的特点
• 开发与维护取舍

Lua 过滤器：用 Lua 脚本实现，开发简单、无需编译、加载快，适合实现简单逻辑（如请求头处理、简单鉴权、日志定制）；但每次请求执行脚本解释成本较高，性能一般，且调试能力有限，复杂逻辑难以维护。Wasm 过滤器：用 WebAssembly 编译（Rust/C++/Go 等），运行在沙箱中，隔离性好、可热更新、性能较好、跨语言；但开发需要编译链、调试相对复杂、Wasm 运行时有一定内存与开销。取舍：简单逻辑优先 Lua（开发快、成本低）；复杂逻辑、需要性能与隔离、需要跨平台分发时选 Wasm。维护上 Wasm 需版本管理及时，Lua 需注意脚本质量与安全。

Lua 与 Wasm 是 Envoy 扩展的两种主要方式，取舍的本质是"开发便捷 vs 性能/隔离"。Lua 轻量快速适合小逻辑，Wasm 强大但开发重。按业务复杂度与性能要求选型，避免过度使用高级方案。

• 静态配置
• 文件订阅（file-based dynamic）
• xDS 动态更新

静态配置：在 bootstrap 或配置文件中直接写死 listener/cluster，适合配置稳定、无需动态变更的场景，简单可靠但无法热更新。文件订阅：通过文件（file-based）动态订阅配置，配置变化时重载文件并应用，适合配置变更不频繁、且希望避免全量 xDS 复杂性、无控制面的场景。xDS 动态更新：通过 gRPC 与 xDS 服务（控制面）订阅，实时推送配置变更，适合服务网格等需要动态、大规模、程序化管理配置的场景，支持热更新与增量推送。选型：简单稳定用静态，需动态但无控制面用文件订阅，网格化/规模化用 xDS。

三种方式对应"配置的灵活性"从小到大：静态最简单、文件订阅适中、xDS 最灵活。选型取决于是否需要动态变更、是否有控制面、以及配置复杂度。网格场景必然选 xDS，而独立部署的简单代理可用静态或文件订阅。

• 重试预算与次数
• 超时层级（per-try/全局）
• 幂等性约束

重试策略在 route 配置 retries：次数（num_retries）、重试条件（retry_on，如 connect-failure、5xx、reset）与重试预算（retry_budget，控制并发重试占总请求的比例，防止重试风暴）。超时层级：全局超时（timeout）是整次请求（含重试）的上限，per-try timeout 是单次尝试的超时，两者配合避免单次尝试过慢或总耗时过长。幂等性约束：只有幂等请求（如 GET）才可安全重试，非幂等请求（POST）重试可能导致重复操作，因此重试条件需谨慎配置，避免对写操作重试造成数据不一致。配置时需结合后端语义设置 retry_on 与预算。

重试与超时是"防风暴 + 控耗时 + 保幂等"的平衡：重试预算限制重试对系统的压力，per-try/全局超时控制耗时，幂等性约束保证重试安全。配置不当（如无限重试、重试非幂等请求）反而会放大故障。

• 本地限流（local rate limit）
• 全局限流（RLS）
• 适用场景

本地限流（local rate limit）：在单个 Envoy 实例内按本地计数限流，实现简单、无外部依赖、延迟低，但只对本实例生效，无法在多实例间共享额度，适合简单场景或边缘防护（如按实例限流）。全局限流（RLS，Rate Limit Service）：把请求发送给集中式的限流服务，基于全局统计（跨多实例）按用户/IP/维度限流，能实现分布式一致的额度，适合需要全局共享配额、多实例协同限流的场景，但引入外部服务依赖与额外延迟。选型：部署简单、单机限流用本地；需要跨实例全局一致限额、多租户配额用全局限流。

本地与全局限流的本质区别是"额度范围"：本地按实例、全局按集群。全局限流适合需要统一配额与多租户隔离的场景，本地限流适合简单轻量的防护。理解差异才能按业务需要选择，避免为简单场景引入复杂的外部服务。