跳转至

3.1 云上容灾

课程简介

在数字化时代，系统的高可用性和业务连续性是企业的生命线。本课程将深入探讨如何构建可恢复、高性能的云架构。我们将从国家灾备标准出发，详细解析 RTO 与 RPO 指标，深入讲解“两地三中心”等经典云上容灾架构，并探讨当前主流的“多云容灾”策略与实践，帮助企业应对单云故障风险，实现业务的极致高可用。

学习目标

通过本课程的学习，您将能够：

  • ✓ 掌握灾备标准：理解国家灾备等级（1-6级）的具体要求及 RTO/RPO 指标含义。
  • ✓ 设计容灾架构：熟练设计同城双活、两地三中心（Geo-Redundancy）等云上容灾方案。
  • ✓ 实施多云策略：了解多云容灾的优势，掌握半双活与全双活多云架构的设计要点。
  • ✓ 落地实战：通过真实案例，学习如何通过多云部署实现业务连续性保障与降本增效。

第一部分：灾备标准与核心指标

本部分导读
灾备建设不是“拍脑袋”，而是有法可依、有章可循的。了解国家标准和核心指标是设计容灾方案的前提。

一、核心指标：RTO 与 RPO

在灾备建设中，有两个至关重要的衡量指标：

指标 全称 中文含义 定义 关注点
RTO Recovery Time Objective 恢复时间目标 灾难发生后，业务从停顿到恢复服务所需要的时间。 业务停多久？(时间)
RPO Recovery Point Objective 恢复点目标 灾难发生后，系统能恢复到的时间点，即最多丢失多少数据。 数据丢多少？(数据)
  • 理想目标：RTO = 0（业务零中断），RPO = 0（数据零丢失）。
  • 现实权衡：RTO/RPO 越低，投入成本（技术、资源、运维）越高。

二、国家灾备等级标准 (GB/T 20988-2007)

我国《信息系统灾难恢复规范》将灾备能力划分为 6 个等级：

等级 关键特征 数据备份要求 RTO/RPO 参考值
等级 1 基本支持 每周 1 次全量备份，介质场外存放。 RTO ≥ 2天
RPO 1-7天
等级 2 备用场地支持 在等级 1 基础上，要求有备用场地和网络线路协议。 RTO ≥ 24小时
RPO 1-7天
等级 3 电子传输支持 每天 1 次全量备份，利用网络定时批量传输数据。 RTO ≥ 12小时
RPO 数小时-1天
等级 4 电子传输及完整设备 备用中心配备全部设备，处于就绪状态，7x24 运维。 RTO 数小时-2天
RPO 数小时-1天
等级 5 实时数据传输 实时数据复制技术，备用网络具备自动切换能力。 RTO 数分钟-2天
RPO 0-30分钟
等级 6 数据零丢失 远程实时备份，实现数据零丢失，应用具备自动无缝切换能力。 RTO 数分钟
RPO = 0

选型建议： - 一般非关键业务：等级 1-3。 - 关键业务（如金融核心）：等级 5-6。

第二部分：云上容灾架构设计

本部分导读
云计算天然具备多地域（Region）、多可用区（AZ）的特性，为构建低成本、高可靠的容灾架构提供了基础设施。

一、主流容灾模式

1.1 同城容灾 (同城双活)

  • 部署方式：在同一地域（Region）的两个不同可用区（AZ）部署业务。
  • 特点：网络延迟极低（<2ms），可实现数据强同步（RPO=0）。
  • 防范风险：机房级故障（如断电、火灾）。

1.2 异地容灾

  • 部署方式：在不同地域（如北京、上海）部署业务。
  • 特点：距离远，通常采用异步复制，数据可能存在秒级延迟。
  • 防范风险：地域级灾难（如地震、洪水）。

二、经典架构：两地三中心

这是金融级业务最常用的高可用架构。

graph TD
    subgraph Region_A[地域A (如: 广州)]
        subgraph AZ_1[可用区 1 (生产中心A)]
            App1[应用集群]
            DB1[(主数据库)]
        end

        subgraph AZ_2[可用区 2 (生产中心B)]
            App2[应用集群]
            DB2[(同城备库)]
        end

        DB1 <-->|强同步复制| DB2
    end

    subgraph Region_B[地域B (如: 上海)]
        subgraph AZ_3[可用区 3 (异地灾备中心)]
            App3[应用集群]
            DB3[(异地灾备库)]
        end
    end

    DB1 -.->|异步复制| DB3

    LB[全局负载均衡/DNS] --> Region_A
    LB -.-> Region_B

架构解析： 1. 同城双中心 (生产)：在广州的 AZ1 和 AZ2 部署双活业务，数据库进行强同步，流量按比例（如 50:50 或 90:10）分发。 2. 异地灾备中心：在上海的 AZ3 部署灾备系统，数据通过 DCN (数据通信网) 异步复制。平时不承接流量或仅承接读流量，灾难时接管业务。

细分模式： - 同城双活 + 异地热备：异地仅做备份，RTO 约 30分钟-1小时。成本较低。 - 一地多活：异地也承接写流量（需解决数据冲突），RTO < 15分钟。成本较高。

第三部分：多云容灾战略

本部分导读
“不要把鸡蛋放在同一个篮子里”。随着单一云厂商故障事件（如 AWS, Google Cloud 宕机）的频发，多云（Multi-Cloud）成为企业分散风险的必然选择。

一、为什么选择多云容灾？

1.1 风险背景

即使是顶级的云厂商，也无法保证 100% 不出故障。 - 2020年 Google 宕机 45 分钟，影响 20 亿用户。 - 2020年 AWS 弗吉尼亚区故障，影响数小时。

1.2 多云优势

  1. 规避供应商锁定 (Vendor Lock-in)：保持技术独立性，议价能力更强。
  2. 极致高可用：规避单一云厂商底层的共性故障（如代码 Bug、网络拥塞）。
  3. 地缘与合规：满足不同国家/地区的数据驻留和合规要求。
  4. 成本优化：利用不同云厂商的优势资源（如某家的 GPU 更便宜，某家的存储更稳）。

二、多云架构模式

2.1 半双活多云 (Active-Standby)

  • 设计：主云承担 100% 流量，备云部署相同架构但仅同步数据。
  • 切换：主云故障时，通过 DNS 修改解析指向备云。
  • 适用：对 RTO 要求不极其苛刻，希望降低备云资源成本的客户。

2.2 全双活多云 (Active-Active)

  • 设计：两朵云同时承担业务流量（如 50:50），数据库做双向同步或单元化拆分。
  • 优势：RTO 接近于 0，随时可切换。
  • 挑战：数据一致性维护复杂，专线网络成本高。

三、多云容灾建设四步走

  1. 业务调研：确定 RTO/RPO 目标，评估业务依赖。
  2. 方案设计：规划网络互通（VPN/专线）、数据同步（DTS/工具）、流量调度（DNS）。
  3. 容灾实施：应用部署、数据全量+增量迁移。
  4. 演练运维：定期进行断网演练，验证切换流程。

第四部分：案例分享

案例：某互联网文娱企业的多云容灾实践

背景： - 主营新闻、小说、直播业务，MAU（月活）千万级。 - 原业务部署在某友商云，对业务连续性要求极高。

痛点： - 担心单一云厂商故障导致全线停服。 - 希望引入竞争机制，降低 IT 成本。

解决方案： 1. 架构升级：引入腾讯云，构建“友商云 + 腾讯云”的多云双活架构。 2. 异地部署：选择与原友商云不同的地域（Region）和可用区（AZ）部署腾讯云灾备中心。 3. 流量调度：使用全局负载均衡/DNS，将流量分发到两朵云。 4. 数据同步：利用 DTS (数据传输服务) 实现跨云数据库的双向/单向同步。 5. 降本增效：在腾讯云侧选用高性价比的 AMD 机型，整体成本降低 30%。

成效： - 将单一云厂商故障的影响降低至分钟级。 - 实现了跨云容灾，保障了千万级用户的业务连续性。

课程总结

知识体系回顾

  1. 标准：灾备 6 级标准，RTO（时间）和 RPO（数据）是核心考量。
  2. 架构：同城双活解决机房故障，异地容灾解决地域灾难，两地三中心是黄金标准。
  3. 趋势：多云容灾已成为主流，能有效规避供应商锁定和单云故障风险。

架构师实践清单 (Checklist)

  • [ ] 定级：您的业务属于哪一类灾备等级？（等级3？等级5？）
  • [ ] 架构：是否实施了跨可用区（Multi-AZ）部署？
  • [ ] 数据：数据库是否开启了跨地域备份或同步？
  • [ ] 演练：是否每年至少进行一次容灾切换演练？

本节课程到此结束。下一节，我们将探讨如何通过3.2 云上架构性能优化来提升系统的运行效率。