3. 变更门禁的配置模型：动态配置与静态配置的区别、变更门禁的配置结构（Bootstrap、Listener、Cluster、Route、Secret）、配置版本管理与热加载机制
3.1 静态配置 vs 动态配置：核心差异
Envoy 的配置模型分为静态配置与动态配置两种模式。变更门禁系统主要作用于动态配置的变更路径，但理解两者的区别是排查配置问题的前提。
| 对比维度 | 静态配置（Static） | 动态配置（Dynamic/xDS） |
|---|---|---|
| 配置来源 | Bootstrap 文件（YAML/JSON） | xDS 控制面（ADS/SDS/CDS/RDS/LDS） |
| 变更方式 | 修改文件 → 重启或 SIGHUP 重载 | 控制面推送增量/全量更新 |
| 变更粒度 | 全量重载，无法局部更新 | 按资源类型（Listener/Cluster/Route/Secret）独立更新 |
| 变更门禁适用性 | 不适用（无推送路径） | 核心场景：拦截、校验、灰度、回滚 |
| 故障隔离 | 配置错误导致进程启动失败 | 配置错误可被门禁拦截，不影响运行中配置 |
| 热加载能力 | 依赖进程重启或 SIGHUP | 原生支持，无连接中断 |
3.2 变更门禁的配置结构：五大核心资源
Envoy 的配置体系由 Bootstrap、Listener、Cluster、Route、Secret 五类资源构成。变更门禁需要分别对每类资源的变更进行校验与管控。
3.2.1 Bootstrap：配置的起点
Bootstrap 是 Envoy 进程启动时读取的唯一静态文件。它定义了节点标识（node.id、node.cluster）、管理接口（admin）、动态配置的 xDS 端点（dynamic_resources）以及静态的 Listener/Cluster 兜底配置。
node.id 和 node.cluster 是门禁系统识别 Envoy 实例身份的关键字段，用于匹配变更策略。
3.2.2 Listener：流量入口
Listener 定义 Envoy 监听的端口、协议、过滤器链以及 TLS 配置。变更门禁在 Listener 变更时重点校验：端口冲突、过滤器链完整性、TLS 证书有效性。
3.2.3 Cluster：上游服务定义
Cluster 描述上游服务集群的端点列表、负载均衡策略、连接池大小、健康检查参数。变更门禁对 Cluster 变更的校验包括：端点可达性、健康检查配置合理性、负载均衡算法兼容性。
3.2.4 Route：流量路由规则
Route 定义虚拟主机（VirtualHost）和路由匹配规则（match → route action）。这是变更最频繁的资源，也是门禁校验最严格的区域——路由冲突、权重总和校验、重试策略合理性是常见拦截点。
3.2.5 Secret：证书与密钥
Secret 管理 TLS 证书、私钥和验证链。变更门禁在 Secret 变更时执行：证书链完整性校验、私钥匹配校验、过期时间检查、OCSP stapling 配置验证。
3.3 配置版本管理与热加载机制
Envoy 通过 xDS 协议实现配置的热加载，变更门禁系统需要理解版本管理的核心机制才能正确拦截和回滚。
3.3.1 版本号与版本一致性
每个 xDS 资源（Listener、Cluster、Route、Secret）都携带一个版本号（string 类型）。控制面每次推送新配置时递增版本号。Envoy 在 /config_dump 管理接口中暴露当前生效的配置版本，变更门禁通过比对控制面版本与 Envoy 版本判断是否推送成功。
3.3.2 热加载的原子性保证
Envoy 的热加载采用先建后删策略：新配置的 worker 线程完全就绪后，才将新连接导向新 worker，旧 worker 等待已有连接处理完毕后再销毁。变更门禁可以利用这一特性实现无损回滚——在旧 worker 尚未完全销毁前，推送旧版本配置即可恢复。
3.3.3 增量更新 vs 全量更新
| 更新模式 | 描述 | 变更门禁处理差异 |
|---|---|---|
| 全量更新（SotW） | 每次推送包含某类资源的全部定义 | 门禁需要全量校验，计算变更 diff 成本较高 |
| 增量更新（Delta） | 仅推送发生变化的资源 | 门禁只需校验变更部分，效率更高，但需要维护资源依赖图 |
3.3.4 配置回滚机制
变更门禁在检测到配置推送失败或业务指标异常时，触发回滚操作：
- 控制面回滚：门禁通知控制面重新推送上一个稳定版本（v3）。
- Envoy 侧回滚：如果控制面不可用，可通过管理接口
/config_dump获取历史配置，手动触发 SIGHUP 重载。 - 版本保留策略：建议控制面保留最近 N 个版本（通常 N=5~10），门禁系统维护版本快照用于快速回滚。
3.4 配置模型与变更门禁的集成要点
- 资源依赖顺序：变更推送时应遵循 Secret → Cluster → Route → Listener 的顺序，避免 Listener 引用尚未就绪的 Route 或 Secret。
- 配置校验分层：门禁执行语法校验（YAML/JSON 格式）、语义校验（引用关系完整性）、业务校验（端口是否被占用、证书是否过期）。
- 灰度发布支持：门禁可以按 Envoy 实例的
node.id或node.cluster进行灰度推送，先推 10% 实例观察指标，再全量推送。 - 审计与可观测性：每次配置变更（包括门禁拦截、放行、回滚）都需要记录：变更时间、操作人、版本号、变更内容摘要、校验结果。