3. VS快照概念解析：什么是VS快照、快照的组成结构、快照与实时配置的关系
在服务网格治理回滚护栏体系中，VS快照（VirtualService Snapshot）是保障配置变更可追溯、可回退的核心数据载体。它并非简单的配置备份，而是一个包含版本元数据、完整配置内容及依赖关系的时间点冻结记录。
3.1 什么是VS快照
VS快照是对特定VirtualService资源在某一时刻的全量状态拷贝，包含该资源的所有字段、关联的DestinationRule引用、以及生成该快照时的上下文元数据。快照一旦生成即为不可变对象，任何对实时配置的修改都不会影响已生成的快照。
核心特性：快照是“只读的历史记录”，而非“可编辑的配置副本”。它专为审计、回滚、对比分析而设计，不参与服务网格的数据面转发决策。
| 特性 | 说明 |
|---|---|
| 不可变性 | 快照生成后，其内容不可被任何API修改或删除（仅可通过TTL或管理策略清理） |
| 时间点一致性 | 快照记录的是某一时刻的完整配置状态，而非增量变更 |
| 独立存储 | 快照与实时配置存储分离，避免误操作影响生产配置 |
| 可追溯性 | 每个快照携带唯一ID、时间戳、操作者标识，满足审计需求 |
3.2 快照的组成结构
一个完整的VS快照由以下四个核心部分组成，它们共同构成了可独立用于回滚操作的原子单元：
3.3 快照与实时配置的关系
理解快照与实时配置的关系，是掌握回滚机制的前提。两者并非主从关系，而是“历史记录”与“当前状态”的平行关系。
| 对比维度 | VS快照 | 实时配置 |
|---|---|---|
| 可变性 | 不可变（只读） | 可变（可读写） |
| 存储位置 | 快照存储区（独立etcd前缀或对象存储） | Kubernetes API Server（etcd） |
| 生命周期 | 由TTL策略或手动清理管理 | 随资源创建/更新/删除而变 |
| 对数据面的影响 | 无直接影响 | 直接影响Envoy路由行为 |
| 回滚能力 | 作为回滚源 | 被回滚操作覆盖 |
| 审计价值 | 高（完整历史链） | 低（仅保留当前版本） |
关键机制：当执行回滚操作时，系统从快照存储区读取目标快照的“VS配置体”，将其内容写入Kubernetes API Server，覆盖当前的实时配置。此过程不修改快照本身，确保回滚操作可重复执行。
3.4 快照生成与回滚的时序关系
下图展示了快照在配置变更生命周期中的位置，以及回滚操作如何利用快照恢复历史状态：
重要提醒：快照仅记录VirtualService本身的配置状态，不包含数据面Envoy的运行状态。回滚操作恢复的是“期望配置”，而非“运行时状态”。若Envoy实例存在配置缓存延迟，回滚生效可能存在秒级滞后。
3.5 快照存储与索引策略
为了支撑大规模服务网格下的高效回滚，快照存储采用分层索引结构：
- 一级索引：按命名空间+VS名称组织，每个VS维护一个快照链表
- 二级索引：按时间戳排序，支持按时间范围检索
- 三级索引：按操作者/变更单号，用于审计追溯
- TTL策略：默认保留最近30天的快照，关键变更可标记为“永久保留”
# 快照存储路径示例（etcd键值结构）
/snapshot/v1/namespaces/{ns}/virtualservices/{vs}/snapshots/
├── snap-20250301-001/ # 快照目录
│ ├── metadata.json # 元数据头
│ ├── config.yaml # VS配置体
│ ├── dependencies.json # 依赖索引
│ └── checksum.sha256 # 校验签名
├── snap-20250302-001/
└── snap-20250303-001/
最佳实践：在回滚演练前，建议先验证目标快照的校验签名是否与当前实时配置的哈希值匹配。若匹配，说明快照对应的配置与当前配置相同，回滚无实际意义；若不匹配，则回滚操作将产生配置变更。