1. Envoy缓存基础：架构、数据面位置与灾备关系
1.1 Envoy架构概述
Envoy 是一款高性能、可编程的七层代理，采用 主从多线程 + 事件驱动 架构。其核心组件围绕 Listener、Filter Chain、Cluster 和 Config 四大抽象构建，形成数据面与控制面分离的现代代理模型。
架构要点： Envoy 通过 LDS（Listener Discovery Service）、RDS（Route Discovery Service）、CDS（Cluster Discovery Service）和 EDS（Endpoint Discovery Service）实现动态配置下发，数据面无需重启即可热更新路由与缓存策略。
| 组件 | 职责 | 与缓存的关系 |
|---|---|---|
| Listener | 监听端口，接收入站流量 | 可绑定缓存过滤器，决定哪些请求进入缓存逻辑 |
| Filter Chain | 按序处理请求/响应 | 缓存模块作为 HTTP 过滤器插入链中 |
| Cluster | 定义上游服务端点集合 | 缓存命中时直接返回，避免转发到 Cluster |
| Config | 动态或静态配置管理 | 缓存规则、大小、TTL 均由配置驱动 |
1.2 缓存模块在数据面中的位置
Envoy 的缓存能力通过 HTTP Cache Filter 实现，该过滤器插入在 HTTP 连接管理器（HCM） 的过滤器链中。其位置决定了缓存策略的执行时机：
- 前置位置： 在 Router 过滤器之前，确保缓存命中时直接短路返回，不经过上游转发。
- 请求路径： 检查请求是否可缓存（GET/HEAD + 无 Authorization 头等），若命中则直接构造响应。
- 响应路径： 上游返回后，根据 Cache-Control、Expires 等头部决定是否存入缓存。
生产建议： 缓存过滤器应放置在 Router 过滤器之前，且通常位于 故障注入过滤器之后，以便在注入故障前完成缓存命中判断，避免误注入影响缓存路径。
| 过滤器链位置 | 典型过滤器 | 对缓存的影响 |
|---|---|---|
| 第 1 层 | 故障注入 / 限流 | 缓存请求可能被限流拦截，需配置白名单 |
| 第 2 层 | HTTP Cache Filter | 核心缓存逻辑，命中即返回 |
| 第 3 层 | Router / 重写 / 重试 | 未命中时继续转发，重试可能引发缓存穿透 |
| 第 4 层 | 上游连接池 / 负载均衡 | 缓存未命中时选择后端实例 |
1.3 缓存与灾备的关系
在灾备场景中，缓存承担 流量兜底 和 数据面降级 的双重角色。当上游集群故障或网络分区时，缓存模块成为保障服务可用的最后一道屏障。
1.4 缓存灾备的关键设计原则
- 缓存即兜底： 当上游集群健康检查失败或超时比例超过阈值时，Envoy 可自动切换至缓存响应模式。
- 过期缓存可用： 通过
stale-while-revalidate和stale-if-error指令，允许在故障期间返回过期缓存。 - 缓存隔离： 缓存存储与上游集群故障域隔离，避免级联故障影响缓存层。
- 可观测性： 缓存命中率、过期命中率、降级次数等指标必须纳入巡检监控体系。
常见误区： 将缓存仅视为性能优化手段，忽略其在灾备中的兜底作用。未配置 stale-if-error 的缓存策略，在上游故障时仍会穿透到故障集群，导致缓存雪崩。
1.5 本章小结
Envoy 的缓存模块位于数据面过滤器链的核心位置，通过 HTTP Cache Filter 实现请求级缓存。在灾备场景中，缓存从性能加速器转变为 高可用兜底组件。理解缓存与灾备的关系，是后续进行命中率巡检和故障排查的前提。