1. 课程导入与OCI全局认知

企业上云走到今天，已经很少是“要不要上云”的问题，而是“如何把关键业务系统安全、稳定、可治理地放到云上”的问题。传统自建数据中心里，企业往往要提前采购服务器、存储和网络设备，按峰值容量规划，结果平均利用率长期偏低；扩容周期以周甚至月计，遇到业务高峰只能被动等待；安全边界依赖机房防火墙，一旦业务跨地域、跨云、跨SaaS，访问路径和合规要求就变得难以统一描述。更现实的是，很多企业同时运行Oracle数据库、Java中间件、容器化微服务和数据分析负载，这些负载对网络时延、存储IOPS、可用性和合规性的要求差异极大，用一套“通用云主机”思路很难同时满足。

Oracle Cloud Infrastructure（OCI）的核心价值主张，正是针对上述矛盾提出的：以高性能、低时延的云基础设施承载企业级关键负载，用一致的安全与治理模型覆盖IaaS、PaaS和数据库服务，并通过全球区域与专用区域组合满足数据驻留和合规要求。OCI在架构上强调几个关键特征：扁平高速的RDMA网络与低时延互联，让分布式数据库和HPC类负载获得接近本地的通信性能；以“区域—可用域—故障域”为骨架的容错拓扑，使高可用设计有明确的物理落点；以隔间（Compartment）、策略（Policy）、动态组（Dynamic Group）和标签（Tag）为基础的IAM与治理体系，让资源权限和成本归属可被精确控制；同时提供从虚拟机、裸金属、Kubernetes到自治数据库、Exadata Cloud的连续能力谱系，企业不必在“自己搭”和“完全托管”之间二选一。

理解OCI，先要理解它的整体架构层次。最底层是物理基础设施层，由全球多个区域组成，每个区域内部通常包含多个可用域，可用域之间通过低时延、高带宽网络互联，可用域内再划分故障域，用于进一步隔离电源和硬件故障。其上是计算、存储、网络三大基础服务层：计算提供虚拟机、裸金属和容器实例；存储提供块存储、文件存储、对象存储和归档存储；网络提供虚拟云网络（VCN）、子网、路由表、安全列表、网络安全组、负载均衡和NAT网关等构件。再往上是数据库与数据服务层，包括自治数据库、Exadata Cloud Service、MySQL、NoSQL和流式数据服务。最上层是应用与集成层，涵盖Kubernetes、函数计算、API网关、集成云和可观测性服务。贯穿所有层次的是身份与访问管理、安全、监控、审计和成本管理这些横向能力。

从这张层次图可以看出，OCI的学习路径不应从“创建一台云主机”开始，而应先建立三个基础心智模型。第一是地理与容错模型：区域是资源部署的地理边界，可用域是区域内相互独立的故障域集合，故障域是可用域内的进一步隔离单元。设计高可用时，通常把同一应用的多个实例分散到不同可用域，数据库采用跨可用域的主备或Data Guard配置，从而在单个可用域故障时仍能提供服务。第二是网络与安全模型：VCN是区域级的虚拟网络，子网可以按可用域划分，安全列表作用于子网，网络安全组作用于实例网卡，路由表决定流量去向，NAT网关让私有子网访问公网而不暴露入口。第三是身份与治理模型：隔间是资源分组和权限边界，策略用“允许组在隔间内执行某类操作”的语句描述授权，动态组把计算实例等资源纳入身份体系，标签用于成本分摊和自动化运维。

为了把这三个模型落到可操作层面，下面给出一个典型的企业级起步示例。假设某企业要在OCI上部署一套三层Web应用，规划如下：区域选择离主要用户最近的区域；创建三个隔间，分别为prod-network、prod-app、prod-data；VCN网段为10.0.0.0/16，其中公共子网10.0.1.0/24放置负载均衡，私有应用子网10.0.2.0/24放置应用服务器，私有数据子网10.0.3.0/24放置数据库；应用实例跨两个可用域部署，数据库使用自治数据库或Exadata Cloud并启用跨可用域容灾。权限上，创建AppAdmins组并授予其在prod-app隔间内管理实例和负载均衡的权限，数据库管理员组仅能访问prod-data隔间。这样的规划让网络、权限和成本边界从一开始就清晰，后续扩容和审计都有据可依。