1. 课程导入与全局认知
在开始设计任何跨区域架构之前，我们需要先建立一个共同的判断基准：当故障发生时，业务到底能承受多长时间的不可用、能承受多少数据丢失。这两个问题分别由两个关键指标回答——RTO（Recovery Time Objective，恢复时间目标）和RPO（Recovery Point Objective，恢复点目标）。RTO 描述的是"从故障发生到业务恢复可接受的最长停机时间"，RPO 描述的是"故障发生时，最多可以接受丢失多长时间窗口内的数据"。它们不是技术指标，而是业务指标，技术方案只是用来满足这两个数字的手段。
理解这两个指标最直观的方式是看时间轴。假设某电商系统在 10:00 发生区域级故障，如果 RTO 为 15 分钟，那么 10:15 之前必须恢复对外服务；如果 RPO 为 5 分钟，那么恢复后数据最多只能回退到 9:55 的状态。RTO 决定"恢复速度"，RPO 决定"数据新鲜度"，两者共同决定了架构的复杂度和成本。一个常见的误区是把 RTO 和 RPO 混为一谈，实际上它们由不同的机制保障：RTO 主要靠冗余部署、流量切换和自动化故障转移来压缩，RPO 主要靠数据复制方式和复制频率来控制。
关键认知：RTO 与 RPO 越小，架构成本和运维复杂度越高。业务连续性设计的目标不是"做到零"，而是在可接受的成本下，让 RTO/RPO 落在业务允许的范围内。因此第一步永远是向业务方确认这两个数字，而不是先选技术。
为了把这两个抽象指标落到具体架构上，业界常用"灾备分级"来对应不同的 RTO/RPO 区间。下面这张表给出一个便于讨论的参考框架（数值为示例性区间，用于教学对比，并非某产品的官方承诺）：
| 灾备级别 | 典型 RTO | 典型 RPO | 核心手段 | 成本量级 |
|---|---|---|---|---|
| 备份与恢复 | 数小时～数天 | 数小时～1 天 | 定期快照、对象存储备份 | 低 |
| 温备（Pilot Light） | 10～60 分钟 | 分钟级 | 核心数据持续复制，计算按需拉起 | 中 |
| 热备（Warm Standby） | 1～10 分钟 | 秒级～分钟级 | 缩容常驻副本，故障时扩容接管 | 中高 |
| 多活（Active-Active） | 秒级～近零 | 近零 | 多区域同时承载流量，数据双向/多向同步 | 高 |
这张表的意义在于：它把"业务要求"翻译成了"架构选型"。如果业务方说"停机不能超过 5 分钟、数据不能丢超过 1 分钟"，那么备份恢复级别直接出局，至少要走到热备甚至多活。反过来，如果业务允许 4 小时停机，就没有必要为多活付出数倍成本。
Google Cloud 全球基础设施：灾备的物理底座
要谈多区域高可用，必须先理解 Google Cloud 的全球基础设施层级。它由三个核心概念构成：区域（Region）、可用区（Zone）和边缘接入点（Edge Point of Presence）。一个区域是一个独立的地理位置，例如 us-central1、europe-west1、asia-east1；每个区域内包含三个或更多可用区，例如 us-central1-a/b/c。可用区之间通过低延迟、高带宽的专用网络互联，电力、冷却和网络在物理上相互隔离。这意味着：单可用区故障（如某机房断电）不会影响同区域的其他可用区，而单区域故障（如大范围自然灾害）则需要跨区域冗余来应对。
Google 的全球骨干网络是另一个关键资产。区域之间通过 Google 自有的私有光纤骨干互联，而不是走公共互联网。这带来两个对灾备极其重要的特性：一是跨区域复制的延迟和抖动更可控，二是流量在区域间切换时路径更稳定。对于 RPO 要求秒级的场景，数据复制能否走这条骨干，往往直接决定方案是否可行。
此外，Google Cloud 的资源是"区域级"或"全局级"的。例如 Compute Engine 实例、Cloud SQL 实例、区域级持久盘是区域资源；而全局负载均衡、Cloud Storage 存储桶、IAM 策略、VPC 网络是全局资源。理解这一点非常关键：全局资源天然具备跨区域能力，区域资源则需要显式复制或重建。灾备设计的大部分工作，就是围绕"哪些是区域资源、如何让它们在另一个区域可用"展开的。
课程实战项目说明
本课程围绕一个贯穿始终的实战项目展开：为一家虚构的在线票务平台"TicketFlow"设计并实现多区域高可用与灾备架构。该平台的核心业务是查询余票、下单锁座和支付回调，业务方给出的连续性要求是：RTO ≤ 15 分钟，RPO ≤ 5 分钟，且要求"单区域整体故障时，用户仍能完成查询和下单"。这个要求意味着我们不能停留在备份恢复级别，需要走到热备或更高。
项目将使用以下真实组件逐步搭建：全局外部负载均衡（Global External Load Balancer）作为统一入口，两个区域分别部署托管实例组（MIG），Cloud SQL 采用跨区域只读副本，Cloud Storage 使用多区域或双区域存储桶，配合 Cloud Monitoring 做健康检查和告警。整个课程会沿着"指标定义 → 单区域高可用 → 跨区域数据复制 → 流量切换 → 故障演练 → 成本与优化"的路径推进，每一章都会在上一章的架构上增加一层能力。
学习建议：在进入后续章节前，请先记住三个判断问题——"这个资源是区域级还是全局级？""它的数据靠什么机制复制到另一个区域？""故障时流量靠什么切过去？"后续每一章的设计，本质上都是在回答这三个问题。
最后需要强调一个贯穿全课程的原则：没有经过演练的灾备方案，不能算作可用的灾备方案。RTO 和 RPO 是目标值，不是承诺值；只有通过实际的故障注入和切换演练，才能知道真实恢复时间是多少、数据实际丢失了多少。本课程会在后半段专门安排故障演练章节，用可控的方式验证前面搭建的架构是否真的满足业务给出的那两个数字。