为什么今天还要精读一份十多年前的云计算架构指南？

有句话说，技术会变，但架构思维不会过时。

当我们翻开那份由早期云计算先驱编写的《云计算基础设施和体系架构指南》时，最先感受到的不是"过时"，而是一种令人惊讶的前瞻性——虚拟机作为标准部署对象、按需自助付费、基础设施可编程、应用程序的组合式设计……这些在当年被当作"趋势"写进白皮书的概念，今天已经是每一个云架构师的基本功。

但问题也随之而来：当行业从单一公有云走向混合云、多云甚至分布式云，当 Kubernetes 取代虚拟机成为新的"标准部署对象"，当我们面对的不只是一个云厂商而是五六个——那份指南里提出的分层模型和架构问题，到底哪些依然成立，哪些需要重新理解？

这篇文章就试着做一次精读。我们会用 TOGAF（The Open Group Architecture Framework）的视角，把 IaaS、PaaS、SaaS 三层架构拆开来看，聊清楚每一层的服务边界在哪里、安全责任如何划分、治理要点是什么，最后再对比当下混合云与多云趋势下的架构变化。

不堆术语，不说空话，争取让你读完之后能直接拿去画架构图。

一、先回到起点：云计算到底是什么？

指南里给出的定义非常精炼——

云计算就是封装好的、具有 API 且通过网络提供的服务。

这句话看起来简单，但拆开来有三个关键词：封装、API、网络。

• 封装意味着使用者不需要关心底层实现。你不需要知道那台服务器是什么型号、硬盘是 SSD 还是 HDD。
• API意味着可编程。基础设施不再是运维人员手动去机房插线、装系统的产物，而是开发人员写几行代码就能调度的资源。
• 网络意味着一切服务都是远程可达的。这既是云计算的优势来源，也是安全边界的起点。

指南还特别强调了一个容易被忽略的观点：云计算不是新生事物，它是既有趋势的延伸。虚拟化、按需部署、Web 服务、开源软件——这些技术早已成熟，云计算做的事情是把它们整合到一种新的交付模式里。

这个观点放到今天依然成立。我们现在讨论的云原生、Serverless、边缘计算，本质上也是在既有技术栈上做进一步的抽象和自动化。

二、三层架构：IaaS / PaaS / SaaS 的服务边界

指南把云服务分成三层，并用一张经典的层级图来说明。我们下面用 TOGAF 的"服务能力"概念来重新理解每一层的边界。

2.1 IaaS：把基础设施当作服务

IaaS 提供的是最底层的抽象——计算、存储、网络。用户拿到的是虚拟机（或者今天的容器实例）、虚拟网络、块存储和对象存储，至于上面跑什么操作系统、装什么中间件，完全是用户自己的事。

指南里举了一个非常形象的例子：开发人员从预配置的虚拟机映像库里选择负载均衡器、Web 服务器、数据库服务器，自己配置、自己部署、自己管理网络拓扑。整个过程不需要跟 IT 运维团队"谈判"采购新服务器。

TOGAF 视角下的 IaaS 服务边界：

核心要点：IaaS 把硬件风险转移给了云厂商，但把软件栈的安全和运维责任完全留给了用户。这也是为什么很多企业用了 IaaS 之后发现运维成本并没有显著下降——因为最头疼的部分（操作系统管理、中间件配置、安全加固）还是自己的活。

2.2 PaaS：把平台当作服务

PaaS 在 IaaS 之上多了一层"软件平台"。指南的描述很到位：

PaaS 是一个软件层，作为一项服务提供，用来构建更高水平的服务。

PaaS 的消费方式有两种理解角度：

1. 生产者视角——把操作系统、中间件、开发工具打包成一个平台。比如一个集成了 IDE、Web 服务器栈、数据库的虚拟设备。
2. 消费者视角——只看到一个封装好的 API，通过 API 部署应用，底层的扩展、负载均衡、故障恢复全部由平台自动处理。

TOGAF 视角下的 PaaS 服务边界：

PaaS 最大的好处是让开发人员专注于业务逻辑，不用操心底层环境。但代价也很明显：你会被平台限制。指南里明确提到"PaaS 可能会由于云提供商选择提供的能力而受到制约"。放到今天，这句话翻译成大白话就是——如果你用的 PaaS 不支持某个语言版本或者某个框架，你只能干瞪眼。

2.3 SaaS：把软件当作服务

SaaS 是最上层，也是离最终用户最近的一层。单个应用实例运行在云上，为多个租户提供服务。指南列举了当时的典型例子：在线 CRM、电子邮件、文档协作。

TOGAF 视角下的 SaaS 服务边界：

SaaS 的核心矛盾在于：你用起来最省心，但你对系统的控制力也最低。当你的业务数据全部放在第三方 SaaS 平台上时，数据主权、数据迁移、合规审计就变成了绕不开的话题。

三、用 TOGAF 框架重新审视三层架构

TOGAF 是企业架构领域最主流的方法论之一。它强调四件事：业务架构、应用架构、数据架构、技术架构（简称 BDAT）。我们把三层云模型套进去看看。

3.1 业务架构层：谁在为谁提供什么价值？

在 TOGAF 里，业务架构回答的是"能力"问题——企业需要什么能力，这些能力由谁提供。

云计算三层模型本质上就是能力外包的三种程度：

• IaaS：外包了硬件能力，保留了软件能力
• PaaS：外包了硬件+平台能力，保留了应用开发能力
• SaaS：外包了全部技术能力，只保留业务使用权

架构决策的核心不是"选哪一层"，而是"我的团队擅长什么、不擅长什么"。如果你的团队运维能力很强，IaaS 能给你最大的灵活性；如果你的团队只有业务开发人员，PaaS 或 SaaS 可能更合适。

3.2 应用架构层：组件如何组合？

指南中有一个非常重要的观点：应用程序是组合在一起的，而且设计为可以组合的。

这跟 TOGAF 的"服务组件"理念完全一致。在云环境下，一个应用不再是单体部署在一台服务器上，而是由多个服务组件拼装而成——负载均衡器是一个组件、数据库是一个组件、缓存是一个组件、消息队列是一个组件。

这种组合式设计带来三个架构要求：

1. 松散耦合——组件之间通过 API 通信，不依赖具体的物理部署位置
2. 无状态设计——任何一次请求都应该能被任意一个实例处理，这样才能水平扩展
3. 原地失败（Fail-in-Place）——某个组件挂了就让它挂着，由上层的负载均衡和自动恢复机制处理，不要去试图"修好"一个正在运行的实例

指南里特别提到了一个经典案例：某视频聚合应用在三天内从 50 台服务器扩展到 3500 台。能做到这一点，前提是应用本身被设计为水平可扩展、有限状态、并通过云 API 管理自身部署。

3.3 数据架构层：数据在哪里，处理就在哪里

指南提出了一个概念叫"数据物理"（Data Physics），意思是数据和处理之间的关系。

这个概念放到 TOGAF 的数据架构维度来理解，核心原则是：尽量减少数据的移动，把计算推到数据所在的位置。

原因很直白：

• 数据传输要时间，尤其是大规模数据
• 数据传输有安全风险，经过的网络节点越多，泄露风险越大
• 数据传输有合规约束，某些数据不允许离开特定地理区域

指南里引用了一个生动的例子：某媒体机构想把档案中的 1100 万份文档转换为 PDF，传统 IT 部门评估需要七周，而一位开发人员用 100 个云实例跑分布式计算框架，24 小时就完成了，成本只有 300 美元。

这个例子的关键不在于"云很快"，而在于架构师把计算任务拆分后推送到了数据所在的位置，而不是把数据搬到计算资源那里。

3.4 技术架构层：基础设施的可编程性

TOGAF 的技术架构关注的是"用什么技术来实现"。在云计算语境下，最关键的技术特征就是：基础设施是可编程的。

指南用了一个类比来说明这一点：过去，Java 开发人员决定何时创建新线程；现在，开发人员可以同样轻而易举地创建新的虚拟机，并决定它们如何互相连接。

这产生了一个深远的影响——开发人员和架构师的角色开始融合。一个优秀的云时代开发者，不仅要写业务代码，还要理解如何设计可扩展的部署拓扑、如何配置网络安全策略、如何通过 API 实现自动化运维。

四、安全边界：每一层该防什么、谁来防

安全是云计算架构中最容易被低估、也最容易出错的部分。指南里虽然没有大篇幅专门讲安全，但散落在各处的观点加起来已经勾勒出了一个清晰的安全框架。

4.1 安全责任的"共担模型"

前面三张表格里其实已经体现了这个模型的核心逻辑：

云厂商负责"云本身的安全"（Security OF the Cloud），用户负责"云内部的安全"（Security IN the Cloud）。

具体来说：

• IaaS 层：厂商保证物理安全和虚拟化层的隔离，用户负责操作系统以上的所有安全
• PaaS 层：厂商多负责了操作系统和运行时的安全，用户只需关注应用代码和数据
• SaaS 层：厂商几乎负责全部技术安全，用户主要管数据分类和访问权限

4.2 每一层的关键安全控制点

4.3 网络安全：从边界防护到微隔离

指南特别提到了网络安全做法，强调在云环境中引入信任需要认真考虑。

传统数据中心的网络安全模型是"边界防护"——一道防火墙把内网和外网隔开，内网默认是安全的。但云环境打破了这个假设：

• 虚拟机可能随时创建和销毁，IP 地址不固定
• 多租户共享物理网络，隔离靠虚拟化层实现
• API 通道天然暴露在互联网上

所以云时代的安全策略从"边界防护"转向了"微隔离"——每一个服务组件都有自己的安全策略，组件之间的通信也要经过认证和加密。这也是后来"零信任"架构理念的前身。

五、治理要点：别让云变成"影子 IT"的温床

指南提到一个容易被忽略的风险：自助式模式会把架构决策的责任从架构师转移给开发人员。

这听起来像是一件好事（更快、更灵活），但如果缺乏治理，后果可能是灾难性的：

• 开发人员用信用卡开通了一堆云资源，IT 部门完全不知道
• 不同团队选择不同的云厂商，数据散落各处，无法统一管理
• 没有统一的日志和监控，出了问题都不知道去哪里查

5.1 TOGAF 治理框架在云环境中的应用

TOGAF 的架构治理强调四个要素，我们逐一对应到云场景：

1. 架构合规性审查

每个云资源的采购和使用都应该经过架构审查委员会的评估。不是说要走冗长的审批流程，而是要有基本的"准入标准"：

• 这个云厂商通过了哪些安全认证？
• 数据存储在哪里？是否满足合规要求？
• API 是开放标准还是专有协议？是否存在厂商锁定风险？

2. 架构变更管理

云环境最大的特点是变化快。一个应用可能一天之内从 10 台实例扩展到 1000 台。变更管理流程必须适应这种速度——不能还用传统的"每月一次变更窗口"模式，而应该通过自动化流水线实现"持续合规"。

3. 服务水平管理

指南里反复提到 SLA（服务水平协议）。在多层架构中，SLA 是逐层叠加的：

如果你的 SaaS 应用承诺 99.9% 的可用性，而底层的 IaaS 只提供 99.5%，那你中间必须有自己的容错机制来弥补这个差距。

4. 供应商管理

指南建议"查找在尽可能多的地方使用标准 API 的提供商"。这条建议在多云时代更加重要——标准 API 意味着更低的迁移成本和更少的厂商锁定。

5.2 一份实用的云治理检查清单

• 所有云资源是否有统一的标签（Tag）策略？
• 是否实现了基于角色的访问控制（RBAC）？
• 是否有自动化的成本监控和预算告警？
• 关键数据是否有备份和灾难恢复方案？
• 是否定期进行安全审计和渗透测试？
• 是否制定了云退出策略（Exit Strategy）？

六、从公有云到混合云：架构模型的演进

指南在基础设施模式部分讨论了三种云：公有云、私有云、混合云。这三种模式在当年被视为"选型问题"，但到了今天，它们已经演化成了一种新的架构范式。

6.1 公有云：灵活但有代价

公有云的核心优势是指南里反复强调的风险转移——基础设施的投资风险从企业转移给了云厂商。你不需要预测未来三年需要多少台服务器，用多少付多少就行。

但公有云的代价也很明确：

• 数据主权：你的数据在别人的服务器上
• 多租户隔离：虽然虚拟化层做了隔离，但物理资源是共享的
• 网络延迟：所有通信都要走公网
• 厂商锁定：专有 API 让迁移变得困难

6.2 私有云：控制力强但成本高

私有云是为一个客户单独构建的，提供"对数据、安全性和服务质量的最有效控制"。适合对合规要求高、数据敏感的场景。

但私有云的问题在于：你需要自己承担全部基础设施的建设成本和运维成本。这跟传统数据中心有什么区别？区别在于——私有云引入了虚拟化和自动化，让资源的分配和回收变得灵活。

6.3 混合云：理想很美好，现实很复杂

指南对混合云的定义是"把公有云模式和私有云模式结合在一起"，最典型的用法是用公有云来处理工作负荷高峰——也就是所谓的"超负荷计算"（Surge Computing）。

混合云的核心挑战是指南里点出来的一个关键问题：数据和处理资源之间的关系。

如果数据量小，或应用程序无状态，混合云要成功得多。与必须把大量数据传输到公有云中进行小量处理相比，混合云在轻量级场景下的表现更好。

6.4 多云时代：架构变化的全景图

从 2020 年代开始，行业进入了一个新阶段——多云（Multi-Cloud）。企业不再只依赖一家云厂商，而是同时使用多家公有云，甚至加上私有云和边缘节点。

我们用一张对比表来展示架构模型的变化：

6.5 多云架构的三个关键设计原则

原则一：抽象层隔离

不要让应用代码直接调用某一家云厂商的专有 API。在应用和云之间加一层抽象——可以是开源的跨云框架，也可以是自己封装的适配层。指南里就已经警告过：“专有 API 使得变更提供商非常困难。”

原则二：数据就近处理

在多云环境下，数据可能分布在不同的云和区域。架构设计必须考虑数据的"重力"——大数据集很难搬动，所以计算应该尽量靠近数据。指南中的"数据物理"概念在多云时代变得更加重要。

原则三：统一可观测性

当你的系统跨越多个云平台时，如果没有统一的日志、监控和追踪系统，排查问题会变成噩梦。这不是指南里提到的内容（当时还没有"可观测性"这个说法），但它是多云架构成功的前提条件。

七、架构师的决策框架：一张图说清楚怎么选

把前面的讨论总结成一个决策流程，供实际项目参考：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

需求分析
  │
  ├── 数据是否高度敏感？
  │     ├── 是 → 优先考虑私有云或专有部署
  │     └── 否 → 继续评估
  │
  ├── 团队是否有运维能力？
  │     ├── 强 → IaaS（最大灵活性）
  │     ├── 一般 → PaaS（减少运维负担）
  │     └── 无 → SaaS（开箱即用）
  │
  ├── 是否有合规地域要求？
  │     ├── 是 → 选择满足要求的区域或私有部署
  │     └── 否 → 公有云任意区域
  │
  ├── 工作负荷是否波动大？
  │     ├── 是 → 混合云（基础负载私有 + 弹性公有）
  │     └── 否 → 单一部署模式
  │
  └── 是否需要避免厂商锁定？
        ├── 是 → 多云 + 标准化 API + 容器化
        └── 否 → 可以深度使用单一厂商生态

这个框架不是万能的，但它覆盖了指南中提到的大部分架构决策维度，并结合了当前多云环境的实际考量。

八、容易被忽视的架构细节

精读指南的过程中，有几个细节值得单独拎出来聊聊。

8.1 “一切皆临时"的设计哲学

指南里有一句话特别有启发性：

云计算假定一切都是临时的，而且重新部署整个应用程序就像手动修补一组具体的虚拟机一样容易。

这意味着在云架构中，你不应该去"修复"一个有问题的实例，而应该销毁它然后重新部署一个。这就是后来被称为"不可变基础设施”（Immutable Infrastructure）的理念——部署之后就不要再修改运行中的实例，所有变更都通过重新部署来实现。

8.2 开源软件的战略地位

指南给了开源软件很高的评价，认为它在云计算中"发挥着重要作用"。原因很简单：开源软件让创建标准化的虚拟机映像和设备变得极其容易。

今天这个逻辑依然成立，只不过"虚拟机映像"变成了"容器镜像"，而开源的角色更加重要——Kubernetes、Istio、Prometheus、Terraform……整个云原生生态几乎都建立在开源项目之上。

8.3 水平扩展 vs 垂直扩展

指南明确指出了架构趋势的变化：从"在一台更大的服务器上处理更多工作"（垂直扩展）转向"把任务分散到更多的小服务器上"（水平扩展）。

这个转变对应用设计有深远影响：

• 数据库要做分片（Sharding）
• 应用要做无状态设计
• 缓存要分布式部署
• 消息队列要做分区（Partitioning）

指南用了一个形象的表述——“分割并征服”（Divide and Conquer）。把一个大问题拆成小问题，分配到不同的计算节点上并行处理，最后汇总结果。这就是 MapReduce 模型的核心思想，也是今天分布式计算的基础范式。

九、三层架构的成本模型对比

最后补充一个实用的视角——成本。不同架构层的成本结构差异很大，理解这一点对于做架构决策非常重要。

指南中提到一个观点：云计算把"购买多少基础设施的风险从开发机构转移给了云提供商"。但风险转移不等于成本消失——它只是换了一种形式出现。IaaS 的隐性成本是运维复杂度，PaaS 的隐性成本是平台限制，SaaS 的隐性成本是定制困难。

好的架构师会算总账，而不只看账单上的数字。

精读一份经典文档的最大价值，不在于记住它说了什么，而在于理解它的思维框架如何在新环境下继续生效。那份指南里提出的分层模型、安全共担、数据物理、基础设施可编程等概念，经过十多年的行业实践验证，不仅没有过时，反而在混合云和多云时代变得更加重要。

技术栈在变，部署对象从虚拟机变成了容器，编排工具从脚本变成了 Kubernetes，安全模型从边界防护变成了零信任——但架构思维的核心没有变：在正确的层次做正确的抽象，在正确的边界做正确的隔离，在正确的位置做正确的决策。

这才是精读的意义所在。