云原生灾备基础
2.1 云原生架构特点
云原生（Cloud Native）是一种以容器、微服务、声明式 API 和不可变基础设施为核心的软件交付与运行模式。其架构特点直接影响灾备策略的设计与实施。
| 架构特征 | 描述 | 对灾备的影响 |
|---|---|---|
| 微服务化 | 应用拆分为独立、松耦合的服务单元，每个服务可独立部署、扩展。 | 灾备粒度从“单体应用”细化为“服务级”，需按服务重要性分级保护。 |
| 容器化 | 应用及其依赖打包为容器镜像，通过编排工具（如 Kubernetes）统一调度。 | 灾备对象从“虚拟机/物理机”变为“容器镜像 + 持久卷 + 配置数据”。 |
| 不可变基础设施 | 服务器/容器实例一旦部署不再修改，更新时直接替换为新实例。 | 灾备恢复强调“重建”而非“修复”，需保证镜像仓库与编排清单的版本一致性。 |
| 声明式 API | 通过 YAML/JSON 描述期望状态，系统自动调和至该状态。 | 灾备恢复可借助声明式配置实现“一键重建”，降低人工操作失误风险。 |
| 弹性伸缩 | 基于负载指标自动扩缩服务实例数。 | 灾备站点需具备同等弹性能力，避免恢复后因资源不足导致性能雪崩。 |
关键认知： 云原生架构的“动态性”和“编排性”使得灾备不再依赖固定的物理拓扑，而是转向“数据 + 配置 + 镜像”三位一体的保护模式。
2.2 灾备等级定义：RPO 与 RTO
灾备等级由两个核心指标量化定义：
- RPO（Recovery Point Objective，恢复点目标）：允许丢失的最大数据量对应的时间跨度。例如 RPO = 15 分钟，表示最多丢失过去 15 分钟内的数据。
- RTO（Recovery Time Objective，恢复时间目标）：从灾难发生到业务恢复所允许的最大时间间隔。例如 RTO = 1 小时，表示必须在 1 小时内恢复服务。
根据 RPO/RTO 的严格程度，灾备等级通常划分为以下层级：
| 等级 | RPO | RTO | 典型实现方式 |
|---|---|---|---|
| L0 无备份 | 无 | 无 | 无任何保护措施 |
| L1 数据备份 | 24 小时 | 24~48 小时 | 定时磁带/对象存储备份 |
| L2 应用级备份 | 4~8 小时 | 4~12 小时 | 虚拟机快照 + 应用一致性检查 |
| L3 主备切换 | 15~60 分钟 | 30~120 分钟 | 数据库主从复制 + 冷备集群 |
| L4 双活/多活 | 0~5 分钟 | 0~15 分钟 | 同步复制 + 负载均衡 + 自动故障转移 |
注意： 云原生环境下，RPO/RTO 的承诺必须考虑容器调度时间、镜像拉取时间、持久卷挂载时间以及服务发现收敛时间。仅计算数据库复制延迟是不够的。
2.3 云原生灾备与传统灾备的区别
传统灾备以“物理机/虚拟机 + 固定 IP + 存储阵列复制”为核心；云原生灾备则以“容器 + 编排 + 声明式配置”为核心。两者在多个维度存在本质差异：
| 对比维度 | 传统灾备 | 云原生灾备 |
|---|---|---|
| 保护对象 | 物理服务器、虚拟机、数据库实例 | 容器镜像、持久卷声明（PVC）、ConfigMap、Secret、CRD 资源 |
| 恢复粒度 | 整机恢复或单文件恢复 | 服务级恢复、命名空间级恢复、甚至单个 Pod 重建 |
| 恢复方式 | 启动备用虚拟机/物理机，挂载存储，启动应用 | 通过 kubectl apply 或 Helm 声明式重建，自动调度至健康节点 |
| 网络依赖 | 依赖固定 IP、MAC 地址、VLAN 配置 | 依赖 Service Mesh、DNS、Ingress 动态路由，IP 不固定 |
| 数据一致性 | 依赖存储阵列快照 + 应用静默 | 依赖分布式存储快照 + 应用级 quiesce 钩子（preStop/postStart） |
| 演练成本 | 需搭建独立演练环境，耗时耗力 | 可在同一集群的隔离命名空间或廉价开发集群中快速演练 |
| 自动化程度 | 依赖脚本或商业灾备软件 | 天然支持 GitOps 驱动，灾备策略可代码化（IaC） |
下图直观展示了两种灾备模式在恢复流程上的核心差异：
核心结论： 云原生灾备将恢复流程从“手动操作 + 固定资源”转变为“声明式重建 + 动态调度”，大幅降低了 RTO，但同时也对镜像版本管理、持久卷备份策略和网络策略一致性提出了更高要求。
2.4 云原生灾备的关键挑战
- 有状态服务的备份一致性：数据库、消息队列等有状态服务在容器环境下，需要借助存储快照 + 应用级钩子（如 MySQL 的 FLUSH TABLES WITH READ LOCK）保证崩溃一致性。
- 跨集群资源依赖：微服务间调用链复杂，灾备恢复时需确保依赖服务（如配置中心、服务网格控制面）优先恢复。
- 镜像与 Helm Chart 版本对齐：生产环境与灾备环境的镜像 Tag 和 Chart 版本必须严格一致，否则恢复后可能出现 API 不兼容。
- 网络策略与安全组同步：Kubernetes NetworkPolicy、Ingress 规则、mTLS 证书等需在灾备集群中同步，避免恢复后服务无法通信。
实践建议： 在灾备准入策略评审中，应将“有状态组件是否支持 quiesce 钩子”、“镜像仓库是否跨集群同步”、“Helm Chart 是否版本锁定”作为必检项。