多云内容分发网络容灾切换设计：缓存、证书与回切风险

多云内容分发网络容灾切换设计，不能只验证备用源站“能不能打开”。切换后若缓存策略不一致，内容可能过期或出现版本混杂；证书没有同步，客户端会遇到连接错误；故障解除后一次性回切，还可能让主源站承受突增请求。设计时应把这三类风险纳入同一套演练和回退流程。

先对齐缓存行为，而不只是缓存内容

以 Azure Blob Storage 和 Google Cloud Storage 分别作为主、备源站为例，即使两边保存相同文件，分发层也可能因缓存键、响应头或规则差异而返回不同结果。需要核对的内容包括：哪些路径可缓存、缓存有效期由哪一方控制、是否遵循源站的 Cache-Control，以及查询参数是否参与缓存键。

对 HTML、配置文件等可能频繁更新的内容，可采用较短缓存时间或明确的版本标识；对带版本号的静态文件，则可使用较长缓存时间，但发布时要确保新旧版本引用一致。还应核对压缩和响应头处理规则，避免一个环境返回压缩内容、另一个环境返回不同的内容编码，却共用同一缓存标识。

切换前可抽取代表性路径，在两套环境分别请求并对比状态码、内容摘要、响应头和缓存命中信息。缓存预热也应针对高频对象分批执行；不要把刷新全部对象当成默认做法，否则可能在切换时把请求集中压回源站。

证书和密钥要按部署边界同步

证书同步不等于复制一个证书文件。应确认备用分发环境已部署覆盖实际访问主机名的证书、完整证书链及匹配的私钥，并检查证书有效期、SAN 主机名和更新责任人。若使用托管证书，证书通常绑定具体服务或平台，不能假定另一家服务会自动取得同一证书；应提前安排独立签发或按平台要求部署。

私钥属于敏感凭据，不能通过普通文件传输或写入脚本同步。应使用受控的密钥管理方式限制读取权限，记录版本和部署状态，并在证书轮换时先部署新证书、验证握手，再撤下旧证书。验证需覆盖备用域名和实际访问域名；仅确认控制台显示“已配置”并不足够。

让切换与回切都可控

健康检查应验证真实业务依赖，而非只检查源站端口是否可连接。例如页面依赖的对象存储、必要接口或鉴权服务不可用时，单纯的连通性检查可能仍显示健康。检查频率和失败阈值要结合故障恢复时间、误报风险及平台能力设定；阈值越敏感，越可能因短暂抖动触发切换。

列清依赖：记录主、备源站、访问域名、证书、缓存规则、回源鉴权和刷新方式，并标明各项配置的负责人。
做双向验证：分别通过两套分发路径检查代表性页面、静态文件和接口，记录响应码、内容版本、证书链及缓存状态。
演练故障切换：在可控窗口模拟主源站不可用，观察健康检查、流量转移、错误率和备用源站负载；确认故障解除前不会误触发回切。
渐进回切：先确认主源站数据和依赖已恢复，再小比例导回流量，观察错误率、延迟、缓存命中和源站负载。可把约5%至10%作为试运行起点，每阶段观察数分钟至十几分钟；实际比例和间隔应按容量、流量波动及业务恢复目标调整。

回切风暴常见于主源站刚恢复就接回全部流量：备用侧已积累的热缓存无法自动填补主侧冷缓存，主源站会同时面对回源请求和用户请求。可先预热关键对象、限制回源并发或采用流量分阶段提升；若指标恶化，立即暂停或退回上一阶段，而不是继续按计划加流。