公有云与私有云与混合云
部署模型四象限：公有云/私有云/混合云/多云的架构、典型模式与选型权衡。
前置知识与学习目标
「部署模型」回答的问题是：这套基础设施归谁所有、谁能用。同一套应用，
跑在公有云上、自建机房里、还是两边各跑一半，成本结构、合规姿态与运维
复杂度完全不同。本文与 020-IaaSPaaSSaaS 互补：那篇讲「供应商管到哪层」，
这篇讲「基础设施放在谁那里」。
1. 四种部署模型
| 模型 | 基础设施归属 | 访问范围 | 一句话心智模型 |
|---|---|---|---|
| 公有云 | 云供应商 | 公开 | 租别人的发电厂 |
| 私有云 | 组织自建 | 组织内部 | 自建自用发电厂 |
| 混合云 | 私有 + 公有 | 按需 | 自备电厂 + 电网互补 |
| 多云 | 多家供应商 | 按需 | 同时买两家电网的电力 |
注意「多云」与「混合云」的正交性：混合云说的是「自建 + 外购」，多云说 的是「外购但买两家」。现实中「多云 + 混合」常同时成立。
2. 公有云
2.1 特点
| 优势 | 劣势 |
|---|---|
| 无需前期投资 | 数据不在本地 |
| 弹性伸缩 | 依赖供应商与互联网链路 |
| 全球部署 | 长期大体量成本可能反超 |
| 丰富的服务 | 强合规行业受限 |
| 快速上线 | 供应商锁定（专有 API） |
公有云的经济本质是把固定资产支出（CapEx）变成运营支出（OpEx）：
不为峰值买硬件，只为用量付费。但「用得久、用得多」的场景未必便宜，
长期稳态负载的自建 TCO 反超是真实存在的（见 290-CloudMigration6RStrategy
的 TCO 分析）。
2.2 主要供应商
| 供应商 | 全球份额（量级参考） | 优势 |
|---|---|---|
| AWS | 约 30% | 服务最全、生态最大 |
| Azure | 约 20-25% | 企业集成、混合云 |
| GCP | 约 12% | 数据分析、K8s 原生 |
| 阿里云 | 约 4% | 中国市场第一 |
| 华为云/腾讯云 | 中国市场前列 | 政企、音视频 |
（口径为 Synergy/Canalys 等机构 2024-2025 年全球 IaaS/PaaS 份额的量级， 随季度波动，仅作相对位置参考；中国市场的排名与全球差异很大。）
2.3 适用场景
初创公司、互联网应用、全球化业务、AI/ML 工作负载、开发测试环境。 共同点：弹性需求大或试错成本必须低。
3. 私有云
3.1 特点
| 优势 | 劣势 |
|---|---|
| 数据完全控制 | 前期投资大 |
| 安全合规 | 运维需专职团队 |
| 定制化 | 扩容以月为单位 |
| 稳态成本低 | 资源利用率通常偏低 |
一个常见误区：私有云不等于「虚拟化机房」。只有当自建环境具备自助 服务、弹性供给、计量计费这些「云的特征」时才叫私有云——VMware 集群 加 OpenStack 是，一台 vSphere 主机不是。
3.2 实现方式
| 方式 | 描述 | 代表 |
|---|---|---|
| 自建 | 购买硬件+部署云平台 | OpenStack, VMware |
| 托管私有云 | 供应商提供专属硬件 | AWS Outposts, Azure Stack |
| 虚拟私有云 | 公有云中的隔离网络 | VPC |
托管私有云（Outposts/Stack）本质是「把公有云的机柜搬到你的机房」： 硬件归你场地，软件栈与公有云一致，适合数据必须出楼但想复用公有云 API 的强合规场景。
3.3 适用场景
金融/政府的强监管数据、数据敏感行业、超大规模稳态负载、核心低延迟 系统。判断标准不是「安全焦虑」，而是具体的法规条文与业务曲线。
4. 混合云
4.1 架构
flowchart LR
P[私有云<br/>核心业务/敏感数据] <-->|专线/VPN 互联| U[公有云<br/>弹性负载/大数据]混合云的难点不在「两边都有」，而在互联层：网络（专线低延迟、VPN 低成本）、身份（统一账号与权限）、数据（同步与一致性）三条线都要打通。
4.2 典型模式
| 模式 | 描述 | 现实约束 |
|---|---|---|
| 云爆发 | 私有云为主，公有云应对峰值 | 数据需要能快速移动到公有云 |
| 数据驻留 | 敏感数据在私有侧，计算在公有侧 | 跨界流量大时专线成本高 |
| 灾备 | 公有云作为灾备站点 | 备份链路带宽与演练频率 |
| 渐进迁移 | 新业务上公有云，老系统暂留 | 边界系统的网络与身份打通 |
4.3 关键技术
| 技术 | 作用 |
|---|---|
| 专线连接 | 低延迟、高带宽互联 |
| 统一管理 | 混合云管理平台 |
| 容器化 | 跨云一致性 |
| 服务网格 | 跨云服务通信与策略 |
容器 + Kubernetes 是当下混合云的事实标准：镜像在两边完全一致，编排层 屏蔽环境差异，这是它比「虚拟机模板同步」可靠得多的原因。
5. 多云
5.1 驱动因素
避免单一供应商锁定、按服务择优（A 家的 AI + B 家的数据仓库）、并购 带来的既有资产、区域性合规、大客户要求故障隔离。
5.2 挑战与对策
| 挑战 | 对策 | 现实提示 |
|---|---|---|
| 管理复杂 | 统一管理平台、GitOps | 没有真正的「单一控制台」 |
| 网络互联 | 云间专线、对等连接 | 跨云流量费是隐性大头 |
| 数据一致性 | 事件驱动同步、最终一致 | 强一致跨云基本不现实 |
| 技能要求 | Terraform/K8s 等中立技术栈 | 团队要同时懂两家专有服务 |
| 成本控制 | FinOps、标签治理 | 两套账单体系，更容易失控 |
对多数组织，「为避免锁定而多云」的真实成本是放弃两家各自的深度集成
能力。更务实的路径是「单云深耕 + 中立抽象层（容器/开源数据库/
Terraform）」保留迁移能力，除非并购或合规强制，不建议主动全量多云。
详见 280-MultiCloudHybridArchitecture。
6. 选型指南
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 初创/互联网 | 公有云 | 弹性与试错成本优先 |
| 金融/政府核心 | 私有云+混合云 | 合规条文驱动 |
| 明显波峰谷的业务 | 混合云 | 基线自建+峰值上云 |
| 并购整合/区域合规 | 多云 | 既有资产与法规强制 |
| 数据必须出楼 | 托管私有云 | 公有云软件栈 + 本地硬件 |
小结
- 初学者要点：四种模型的本质是「基础设施归谁、谁能访问」；公有云把 CapEx 变 OpEx 但长期大体量未必便宜；私有云要有自助与弹性才配叫云； 混合云难在网络/身份/数据三条互联线；容器与 K8s 是跨环境一致性的 事实标准。
- 进阶注意：多云是高成本高风险策略，中立技术栈比「买两家」更能防锁定； 云爆发的可行性取决于数据可移动性，不是调度器配置；选型先用合规 条文与负载曲线做约束求解，而不是先选品牌。