4. 目标架构设计原则

在把业务系统从自建数据库或传统商业数据库迁移到 Oracle Cloud 之前，必须先确定目标架构的“设计原则”。原则不是口号，而是后续每一个具体决策的判据：选单实例还是 RAC、选 Data Guard 还是 Autonomous Data Guard、用私有子网还是公共子网、开不开自动扩缩容、备份保留多久、加密密钥由谁托管。本节围绕高可用、可扩展、安全合规、成本优化四条主线，给出可落地的判断依据，并绘制一张 Oracle Cloud 数据库平台逻辑架构图，作为后续章节细化部署方案的基础。

一、高可用：先定义 RTO/RPO，再选技术组合

高可用的第一步不是选产品，而是量化业务能承受多长的中断（RTO）和多少数据丢失（RPO）。例如某订单系统要求 RPO≈0、RTO≤5 分钟，那么单靠每日备份就不够，必须引入同步或近同步的复制机制。Oracle Cloud 中常用的高可用能力可以按“故障域”分层理解：

• 实例级故障：Base Database Service 的 RAC 提供节点冗余，单节点宕机时另一节点继续服务，连接通过 SCAN 监听自动重定向。
• 可用域级故障：Data Guard 把主库变更传送到另一可用域（AD）的备库，可配置为最大可用性（MaxAvailability）或最大性能（MaxPerformance）保护模式。
• 区域级故障：跨区域 Data Guard 或 Autonomous Data Guard 提供异地容灾，适合监管要求异地保存的场景。
• 逻辑错误与人为误删：闪回数据库、闪回表、回收站以及 PITR（时间点恢复）用于应对“数据被改错”而非“机器坏了”。

需要强调的是，RAC 解决的是实例与节点冗余，不防存储损坏；Data Guard 解决的是站点级冗余，但切换需要时间。二者是互补关系，不是二选一。一个常见的组合是：同区域双 AD 部署 RAC + Data Guard，主库在 AD-1，备库在 AD-2，保护模式设为 MaxAvailability，切换目标 RTO 控制在 2～5 分钟，RPO 接近 0。

二、可扩展：垂直、水平与读写分离三条路径

可扩展性要区分“扩容能力”和“弹性伸缩”。垂直扩展是调整 CPU、内存、存储 IOPS，例如把 4 OCPU 的 VM DB 升到 8 OCPU，操作简单但存在单机上限；水平扩展是增加节点，如 RAC 增加实例、只读副本分担查询；读写分离是把报表、导出类负载导向只读副本或 Active Data Guard 备库，避免分析查询拖慢交易主库。

在 Oracle Cloud 中，Autonomous Database 的 ECPU 自动扩缩容和 Base Database 的自动伸缩（Auto Scaling）可以在负载高峰临时提升资源，低谷时回落，这属于“弹性”而非“容量规划”。容量规划仍要基于业务峰值 TPS、并发连接数、单条 SQL 平均逻辑读来估算。例如交易峰值 800 TPS、平均每事务 120 次逻辑读，则约需 96,000 逻辑读/秒，再结合单 OCPU 可承载的逻辑读经验值反推所需 OCPU 数量，并预留 30% 余量。

三、安全合规：从网络、身份、数据三层收敛

安全合规不是加一个防火墙就结束，而是分层收敛：网络层用 VCN、私有子网、安全列表和 NSG 限制访问路径，数据库不暴露公网；身份层用 IAM 策略、动态组、最小权限原则，并尽量用 IAM 数据库口令或 Kerberos 替代静态口令；数据层用 TDE 透明加密、客户托管密钥（OKV/HSM）、Data Safe 做敏感数据发现与审计。合规要求往往决定架构形态，例如等保或行业监管要求审计日志留存 180 天以上，就必须规划审计表空间容量和 Data Safe 审计策略。

四、成本优化：把“固定成本”换成“按需成本”

成本优化的核心是让资源与业务曲线匹配。Oracle Cloud 提供了按需、预留、BYOL 等计费方式，也提供了自动伸缩和自动停止能力。常见做法包括：非生产环境在夜间和周末自动停止；用 Autonomous Database 的自动扩缩容替代长期高配；把冷数据放到低成本存储或对象存储；用预留容量覆盖稳定基线负载，用按需覆盖峰值。需要提醒的是，成本优化不能牺牲 RPO/RTO 和合规底线，例如为了省钱把备库降配到无法承接切换流量，等于高可用形同虚设。

五、Oracle Cloud 数据库平台逻辑架构图

下图把上述四条原则落到一张逻辑架构上：左侧是访问入口与网络边界，中间是数据库平台的核心组件（主库、备库、只读副本、备份与密钥），右侧是运维与安全管控面。图中标注了关键数据流方向与决策点，便于对照本节原则检查每一项设计是否有依据。

六、把原则变成可执行的决策表

为了让架构评审有据可依，可以把四条原则转成一张决策表。下表给出示例参数，实际项目应按业务量级调整。

最后需要提醒：四条原则之间经常互相拉扯。提高可用性通常增加成本，强化合规可能降低弹性，追求低成本可能削弱容灾能力。正确的做法是先确定不可妥协的底线（通常是 RPO/RTO 与合规要求），再在剩余空间里做成本与弹性的优化。架构评审时，每一个组件都应能回答“它服务于哪条原则、依据是什么、代价是什么”，这样的目标架构才经得起迁移后的真实流量与故障考验。