容灾

概述 凌晨 2 点 17 分，手机弹出告警：核心机房 A 区网络设备故障，数据库主从同步中断。值班 SRE 切到灾备机房 B 区，发现应用连上新主库后，部分订单数据查不到——异步复制窗口期丢了 47 秒数据。业务恢复用了 38 分钟，超出 RTO 目标 8 分钟。 这是一次真实的容灾切换事故。事后复盘发现，系统设计了容灾架构，配置了数据同步，也写了切换脚本，但真正切换时还是出了问题。问题不在于"有没有灾备"，而在于容灾架构的每个环节是否真正经得起生产级考验。 本文拆解跨机房容灾的核心架构决策，覆盖同城双活、异地灾备、两地三中心三种模式的选型权衡，同步复制的性能代价与脑裂防护，异步复制的窗口期补偿机制，以及故障切换从决策到执行的完整流程。每个环节都附有真实踩坑记录和性能数据。 在我经手过的跨机房容灾方案中，最终达成 RPO<5min、RTO<30min 的指标。这个数字看起来不算极致，但它是成本、稳定性和业务需求三方博弈后的工程最优解——不是理论上的 RPO=0，而是生产环境能跑通、能验证、能回滚的方案。 RPO 和 RTO 的工程真相 不是技术指标，是业务指标 RPO（Recovery Point Objective）和 RTO（Recovery Time Objective）这两个词被技术圈用烂了，但很多人理解反了——它们首先是业务指标，然后才是技术指标。 RPO 回答的是"能容忍丢多少数据"。比如一个电商系统，订单数据的 RPO 必须是 0（不能丢订单），但用户行为日志的 RPO 可以是 1 小时（丢了不影响核心交易）。RTO 回答的是"能容忍停多久"——核心交易系统 RTO 要 <5 分钟，而报表系统的 RTO 可以是 4 小时。 关键认知：不要一刀切。 我见过太多团队把所有系统都按 RPO=0、RTO<1min 设计，结果容灾建设成本翻了好几倍，非核心系统根本不需要这么高的规格。 按业务重要性分级设计容灾目标： 级别 系统类型 RPO 目标 RTO 目标 同步方式 P0 核心交易、支付 0 <5min 同步复制 P1 用户中心、订单查询 <1min <15min 半同步复制 P2 内容管理、报表 <30min <2h 异步复制 P3 日志分析、离线计算 <1h <4h 定时备份 RPO=0 的代价不是线性的 很多人觉得"RPO 越小越好"，但 RPO 从 1 分钟到 0 的成本跳跃是指数级的：...

概述 当你的业务从"服务一个城市"扩展到"服务全国"甚至"服务全球"时，单机房架构会遇到两个硬约束：距离带来的延迟和单点故障的风险。多地域多活架构是解决这两个问题的工程方案。 但多活架构是 SRE 领域最复杂的主题之一——它不是简单的"在两个机房部署服务"，而是涉及数据一致性、流量调度、故障切换、运维复杂度等一系列深层工程挑战。做对了，系统可用性从 99.9% 提升到 99.99%；做错了，多活架构本身就会成为最大的故障源。 从多活架构模式、数据一致性挑战、流量切换策略、容灾 RTO/RPO 设计、跨地域监控到故障切换演练，详细梳理多活架构的可靠性设计。 关于多活架构的深入讨论，可参考 Google SRE Book - Disaster Preparedness 和 AWS - Multi-Region Active-Active Architecture。 一、为什么需要多活架构 单机房架构的局限 单机房架构： ┌── App Server ×N 用户 ──→ DNS/CDN ──→ Load Balancer ─────┼── App Server ×N └── App Server ×N │ ┌─────────┴─────────┐ │ Database (主从) │ └───────────────────┘ 问题： 1. 如果机房断电/网络中断 → 全站不可用 2. 跨地域用户延迟高（北京到广州 ~30ms RTT） 3. 容量受限于单个机房 多活架构的驱动力 驱动力 说明 优先级 容灾 机房级故障时业务不中断 高 低延迟 就近服务用户，降低访问延迟 高 容量扩展 突破单机房容量上限 中 合规要求 数据必须在特定地域存储 视行业 容灾演练要求 监管要求具备跨机房容灾能力 视行业 容灾的关键指标 在设计多活架构之前，必须先明确两个容灾指标：...

概述 当你的业务规模增长到单集群无法承载时，多集群就成为必然选择。可能的原因包括：单集群节点上限（5000 节点）、多地域部署、混合云策略、故障隔离、合规要求。但多集群带来的管理复杂度是指数级增长——应用如何跨集群部署、服务如何跨集群发现、配置如何同步、故障如何切换。 本文逐步梳理多集群的架构模式、主流管理工具对比，以及跨集群服务发现、CI/CD、容灾切换的实践方案。 本文基于 Kubernetes v1.30。多集群管理领域仍在快速演进，部分工具的成熟度需持续关注。 为什么需要多集群 单集群的瓶颈 瓶颈 说明 规模上限 K8s 单集群推荐上限 5000 节点、15 万 Pod、30 万容器 故障域 单集群 etcd 故障影响所有业务 升级风险 集群升级可能影响所有业务 多租户隔离 软隔离不如硬隔离 地域延迟 跨地域不能用一个集群 合规要求 数据不能跨地域/跨境 多集群的典型场景 场景 架构 目标 多地域容灾 每地域一个集群，DNS 全局负载均衡 RTO < 5min 混合云 云上 + 自建机房 弹性 + 合规 开发/测试/生产隔离 每环境一个集群 安全隔离 多租户硬隔离 每租户独立集群 安全合规 边缘计算 中心集群 + 边缘集群 低延迟 多集群架构模式 模式一：Hub-Spoke（中心辐射） ┌─────────┐ │ Hub │ ← 管理集群 │ Cluster │ └────┬────┘ ┌────────┼────────┐ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Spoke1│ │Spoke2│ │Spoke3│ ← 工作集群 └──────┘ └──────┘ └──────┘ 中心集群负责管理配置、分发应用、收集状态。工作集群只运行业务负载。这是最常见的多集群管理模式。...

概述 Kubernetes 集群的灾难恢复是运维中最容易被忽视的领域——直到灾难发生。etcd 损坏导致整个集群不可用、PV 数据误删无法恢复、集群升级失败无法回滚……这些场景没有备份就是灾难，有备份就是一次常规恢复。 详细梳理 K8s 灾难恢复的三个层次：etcd 备份恢复（集群元数据）、Velero 备份（K8s 资源）、PV 数据备份（持久化数据），以及跨集群恢复和恢复演练的实践。 本文基于 Kubernetes v1.30 和 Velero v1.14。参考 Kubernetes 灾难恢复文档 灾备基础概念 RTO 与 RPO 指标 全称 含义 目标 RTO Recovery Time Objective 恢复时间目标（多快恢复） < 30min RPO Recovery Point Objective 数据丢失目标（丢多少数据） < 5min 故障发生 恢复完成 |◄────── RTO ──────────►| | | |◄── RPO ──►| | | | | 最后一次备份 故障点 恢复点 备份层次 层次 备份对象 工具 RPO 恢复粒度 etcd 集群所有元数据 etcdctl snapshot 分钟级 整个集群 K8s 资源 Deployment/Service/ConfigMap 等 Velero 分钟级 命名空间/资源 PV 数据 持久化卷数据 Velero/Restic/Kasten 小时级 单个 PV 应用数据 数据库/对象存储 应用自身机制 秒级 应用级 灾备分类 类型 说明 适用场景 备份恢复 定期备份，故障时恢复 通用 活跃-备用 备集群 standby，故障切换 核心业务 活跃-活跃 多集群同时服务，故障切流 全球业务 混沌演练 模拟故障验证恢复能力 灾备成熟度 etcd 备份与恢复 为什么 etcd 备份最重要 etcd 是 K8s 的"大脑"——所有集群状态（Pod、Service、ConfigMap、Secret、Deployment 等）都存储在 etcd 中。etcd 损坏等于整个集群的数据丢失。没有 etcd 备份，其他备份都无意义。...