📚 课程目录第2章 Oracle Cloud基础设施即服务网络基础

2. Oracle Cloud基础设施即服务网络基础

在 OCI（Oracle Cloud Infrastructure）上做网络设计，第一步不是打开控制台点“创建 VCN”，而是先把 OCI 的物理与逻辑层级关系理清。OCI 的网络模型可以理解为一条自上而下的“归属链”：区域（Region）→ 可用域（Availability Domain, AD）→ 故障域（Fault Domain, FD）→ 虚拟云网络（VCN）→ 子网（Subnet）→ 路由表 / 安全列表 / 网络安全组。前四层决定资源“放在哪里、能容忍多大故障”，后三层决定流量“怎么走、能不能走”。工程化设计的核心，就是让这条链上的每一层都服务于明确的可用性目标与安全边界。

一、区域、可用域与故障域：可用性的物理底座

区域是 OCI 的地理部署单元，例如 ap-singapore-1、us-ashburn-1。区域之间彼此独立，跨区域通信必须经过公网或 FastConnect/DRG 互联，因此区域选择首先由数据驻留合规、用户时延和容灾半径决定。

一个区域内包含一个或多个可用域。AD 是区域内相互隔离的数据中心组，拥有独立的供电、冷却和网络。同一区域内 AD 之间的时延通常在亚毫秒到 1 毫秒量级（示例值，实际以官方为准），因此 AD 是 OCI 上做高可用的首选故障边界。生产架构的通行做法是：同一逻辑层至少跨两个 AD 部署，例如 Web 层在 AD-1 与 AD-2 各放一台实例，挂到同一个区域级负载均衡后面。

故障域是 AD 内部的进一步隔离单元，每个 AD 默认包含三个 FD。FD 共享同一 AD 的电力和网络主干，但机架级故障（如单机架掉电、单交换机异常）被限制在单个 FD 内。FD 的价值在于“防机架级连带故障”：把同一集群的多个副本分散到不同 FD，可以避免一次机架故障同时打掉多个副本。需要强调的是，FD 不是 AD 的替代品，跨 AD 才是抵御数据中心级故障的手段。

记忆口诀：区域管合规与容灾半径，AD 管数据中心级高可用，FD 管机架级分散。设计时先定区域，再定跨几个 AD，最后用 FD 做副本打散。

二、VCN 与子网：逻辑网络的骨架

VCN 是区域级的私有网络，拥有一个或多个 IPv4/IPv6 CIDR 块。VCN 不跨区域，但覆盖区域内所有 AD。创建 VCN 时最关键的两个决策是 CIDR 规划与子网划分方式。

CIDR 规划要预留增长空间。示例：某项目规划 VCN 使用 10.20.0.0/16，按环境切分——生产 10.20.0.0/18、预发 10.20.64.0/18、开发 10.20.128.0/18、共享服务 10.20.192.0/18。每个 /18 有 16384 个地址，足够容纳多个 /24 子网。若未来要与本地数据中心通过 DRG 打通，必须提前确认本地网段与 VCN 网段不重叠，否则路由无法收敛。

子网是 VCN 内的地址段，分为两种类型：

区域级子网（Regional Subnet）：覆盖区域内所有 AD，创建实例时可自由选择 AD。这是当前推荐方式，灵活性最高。
AD 级子网（AD-specific Subnet）：绑定到单个 AD，实例只能落在该 AD。适用于需要严格绑定物理位置的场景，但会牺牲调度灵活性。

子网还分公有子网与私有子网。公有子网的路由表中存在指向 Internet Gateway 的默认路由，且实例可分配公网 IP；私有子网没有到 IGW 的路由，实例只能通过 NAT Gateway 出站或通过 Service Gateway 访问 OCI 服务。工程上应遵循“默认私有”原则：只有必须直接暴露的负载均衡或跳板机才放入公有子网。

三、路由表、安全列表与网络安全组：流量的通行规则

这三者常被混淆，但职责完全不同，必须分开理解：

组件	作用层级	核心职责	状态
路由表（Route Table）	子网级	决定流量“下一跳去哪”，如 IGW、NAT GW、DRG、LPG	无状态
安全列表（Security List）	子网级	子网内所有 VNIC 共享的入站/出站规则	有状态
网络安全组（NSG）	VNIC 级	按实例/资源粒度定义规则，可跨子网复用	有状态

路由表是“方向决策”，安全列表和 NSG 是“准入决策”。一个数据包先匹配路由表确定出接口，再经过安全规则判断是否放行。安全列表和 NSG 都是有状态的：允许入站请求后，其响应流量自动放行，无需再配出站规则。

工程化设计建议：安全列表只保留最小基线规则，业务规则尽量用 NSG 表达。因为安全列表作用于整个子网，一旦放开某个端口，子网内所有实例都受影响；而 NSG 可以精确绑定到某组实例，例如只允许 app-nsg 的 8080 端口接收来自 lb-nsg 的流量。这样在实例扩缩容或迁移子网时，安全策略随实例走，不会因换子网而失效。

四、一个可落地的三层架构示例

下面给出一个典型的 Web-App-DB 三层设计，VCN 为 10.20.0.0/16，跨 AD-1 与 AD-2 部署：

VCN: 10.20.0.0/16
├── 公有子网 web-pub: 10.20.0.0/24   (AD-1/AD-2 区域级)
│    路由: 0.0.0.0/0 → Internet Gateway
│    安全列表: 入站 80/443 来自 0.0.0.0/0
├── 私有子网 app-priv: 10.20.1.0/24
│    路由: 0.0.0.0/0 → NAT Gateway
│    NSG: 入站 8080 仅来自 lb-nsg
├── 私有子网 db-priv: 10.20.2.0/24
│    路由: 无默认路由，仅本地
│    NSG: 入站 1521 仅来自 app-nsg
└── Service Gateway: 用于访问 Object Storage 等 OCI 服务

该设计中，Web 层跨两个 AD 各放一台实例，由区域级负载均衡分发；App 层与 DB 层均为私有子网，出站经 NAT Gateway，DB 层甚至不配默认路由，彻底阻断外联。安全策略通过 NSG 实现“只允许上一层访问下一层”，形成清晰的南北向与东西向边界。

五、设计检查要点

在提交网络设计前，建议逐项核对：VCN CIDR 是否与本地及其他 VCN 无重叠；生产子网是否跨至少两个 AD；FD 是否用于副本打散；公有子网是否只保留必要入口；私有子网出站是否统一走 NAT Gateway；安全列表是否只保留基线、业务规则是否已下沉到 NSG；DB 子网是否已移除默认路由。这些检查项直接对应 OCI 网络模型中的层级职责，任何一项缺失都可能在故障切换或安全审计时暴露问题。

理解 OCI 网络的关键，是把“物理层级”和“逻辑规则”分开看：区域、AD、FD 决定故障域边界，VCN、子网、路由表、安全列表与 NSG 决定流量路径与准入。两者对齐，架构才既高可用又可审计。