1. 课程导入与目标对齐

在开始讨论 Oracle Cloud Infrastructure（OCI）的多区域高可用与灾备架构之前，需要先回答一个更根本的问题：企业为什么愿意为“多区域”付出额外的成本与复杂度？答案通常不在技术本身，而在业务连续性要求。一次区域性故障可能同时影响计算、存储、数据库和网络，如果所有资源都集中在单一区域，业务恢复时间将完全取决于该区域的恢复能力。多区域架构的核心价值，是把“单点故障”从单个可用域扩展到单个区域之外，用可控的成本换取可承诺的恢复能力。

业务驱动通常来自三类场景。第一类是监管与合规要求，例如金融、医疗行业要求关键系统具备异地灾备能力，并定期验证切换流程。第二类是收入连续性要求，电商、支付、在线服务在区域故障期间的停机损失与时间强相关，停机越久损失越大。第三类是客户体验与SLA承诺，对外承诺的可用性指标需要底层架构支撑，否则承诺无法兑现。这三类场景最终都会落到两个可量化指标上：RTO 与 RPO。

RTO 与 RPO：把业务语言翻译成架构参数

RTO（Recovery Time Objective，恢复时间目标）回答的是“业务能容忍中断多久”，即从故障发生到业务恢复可用的最长时间。RPO（Recovery Point Objective，恢复点目标）回答的是“业务能容忍丢失多少数据”，即故障发生时允许丢失的时间窗口内的数据量。两者共同决定了架构的形态：RTO 越短，越需要热备或主动-主动；RPO 越接近零，越需要同步复制或近实时复制。

举一个教学示例（以下参数为合理假设，用于说明推导过程，并非实测结果）：某订单系统要求 RTO ≤ 15 分钟、RPO ≤ 5 分钟。若采用“备份+恢复”方式，恢复数据库可能需要数小时，RTO 明显不满足；若采用异步复制到另一区域，复制延迟通常在秒级到分钟级，RPO 可以满足，但切换仍需人工决策与 DNS 切换，RTO 需要压缩到 15 分钟内。此时架构选择会倾向于“跨区域异步复制 + 预置备用环境 + 自动化切换脚本”，而不是单纯增加备份频率。

可用域、故障域与区域：OCI 的故障隔离层级

OCI 的全球基础设施按层级组织，理解这些层级是设计高可用与灾备的前提。最上层是区域（Region），每个区域是一个独立的地理位置，区域内包含一个或多个可用域（Availability Domain，AD）。可用域是区域内相互隔离的数据中心组，拥有独立的电力、冷却和网络，一个可用域故障不会直接影响同一区域内的其他可用域。在可用域内部，还有更细粒度的故障域（Fault Domain，FD），用于在单个可用域内进一步分散资源，降低单点硬件故障的影响。

这三层的关系可以这样理解：区域是“城市”，可用域是“城市中相互独立的园区”，故障域是“园区内不同的机房分区”。跨区域部署应对的是城市级灾难，跨可用域部署应对的是园区级故障，跨故障域部署应对的是机房内局部硬件故障。设计时通常从业务 RTO/RPO 出发，决定需要跨到哪一层。

OCI 全球基础设施概览与区域选择

OCI 的区域分布覆盖美洲、欧洲、中东、非洲和亚太。每个区域至少包含一个可用域，多数商业区域包含三个可用域，部分区域根据当地条件可能只有一个可用域。区域之间通过 OCI 的骨干网络互联，跨区域流量走专有路径，不经过公共互联网，这为跨区域复制和灾备切换提供了相对稳定的网络基础。

选择区域时，通常同时考虑四个因素：用户延迟（靠近主要用户群）、合规要求（数据是否必须留在境内）、区域配对（灾备区域与主区域的距离和网络质量）、服务可用性（目标区域是否提供所需服务，例如某些数据库或 AI 服务并非所有区域都有）。一个常见的做法是主区域选在用户密集区，灾备区域选在同一大区内但地理上分离的位置，既控制复制延迟，又满足隔离要求。

从业务驱动到架构决策的映射

把前面的概念串起来，可以得到一条清晰的决策链：业务连续性要求决定 RTO/RPO；RTO/RPO 决定复制方式与切换自动化程度；复制方式与切换要求决定跨区域还是跨可用域；区域与可用域的选择又受合规、延迟和服务可用性约束。这条链上的每一步都会影响成本，因此架构设计不是“越冗余越好”，而是在满足 RTO/RPO 的前提下寻找成本与复杂度的平衡点。