1.2 三种服务模型：IaaS、PaaS、SaaS
1.2 三种服务模型：IaaS、PaaS、SaaS
本节摘要：IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）不是三个并列的产品线，而是"管理责任在用户与云厂商之间如何划分"的三种刻度。本节用一个六层栈模型讲清三者的边界——你管理哪些层、云厂商管理哪些层——并给出按场景选型的对比框架，帮你摆脱"背定义、对不上应用"的困境。
本节目标
阅读完本节，你应当能够：
- 画出"应用—数据—运行时—中间件—操作系统—虚拟化—硬件—存储网络"的分层栈，标出 IaaS、PaaS、SaaS 各自的管理边界。
- 针对一个具体业务，判断它适合用 IaaS、PaaS 还是 SaaS，并说出理由。
- 解释"云厂商替你管得越多，你的灵活性越低"这一取舍的内在逻辑。
- 说出 IaaS、PaaS、SaaS 各两个典型产品例子。
一、问题与直觉
假设你要在公司里搭一套客户管理系统。你可以有三种完全不同的干法。
第一种，自己买服务器、装虚拟机、配操作系统、装数据库、写代码、自己运维。这是"全栈自己扛"，对应的正是 IaaS 的哲学——云厂商只给你"裸的算力"，剩下的都是你的。
第二种，用云厂商提供的应用托管平台，把代码往上一推，平台自动配好运行环境、数据库、负载均衡，你只管业务逻辑。这就是 PaaS。
第三种，干脆买个现成的 SaaS 客户管理系统，网页登录就用，补丁升级全是厂商的事。你连"部署"这个动作都不需要。
三种干法的差别不在"云不云"，而在责任边界。IaaS 是把地基给你，房子你自己盖；PaaS 是连毛坯房带装修队给你，你只管摆家具；SaaS 是拎包入住，家具家电都是现成的。选哪种，取决于你手里有多少人、多少时间、多少"非做不可的定制"。
二、核心原理
2.1 一个六层栈，看懂三种边界
把一套应用需要的所有东西从下往上排：硬件与网络 → 虚拟化 → 操作系统 → 中间件与运行时 → 应用与数据。云厂商替你管理下面的层，你管理上面的层，分界线往哪划，就是哪种服务模型。
2.2 三种模型的语义细节
IaaS——基础设施即服务。提供的是"裸资源"：虚拟机、块存储、虚拟网络。用户可以自己装任何操作系统、任何软件，自由度最高，但也意味着从系统补丁到中间件调优全得自己来。典型产品有 AWS EC2、Azure 虚拟机、Google Compute Engine。适用场景：需要完全控制基础设施、有专门运维团队、或者要跑自家定制的软件栈。
PaaS——平台即服务。在 IaaS 之上又替你管好了操作系统、运行时、中间件甚至数据库，你只管把应用代码交上去。平台负责扩容、补丁、高可用。典型产品如 AWS Elastic Beanstalk、Azure App Service、Google App Engine。适用场景：团队以开发为主、不想养运维、应用形态适合平台约束。
SaaS——软件即服务。完整的应用直接通过浏览器/客户端交付，用户连部署都不用，订阅即可用。典型如 Salesforce、Google Workspace、Microsoft 365。适用场景：办公协作、CRM、企业通讯这类"用通用能力就够了"的需求。
2.3 责任边界的动态性
要特别提醒一点：同一家厂商的同一类产品，边界也不是铁板一块。比如"数据库"既可能作为 PaaS 组件出现（托管数据库），也可能作为 SaaS 产品出现（数据分析 SaaS）。云厂商这些年还在推出各种"托管 xxx"服务，把原本属于用户的责任往上收。所以更稳的判断方法是回到责任边界：这层东西出问题了，是找你还是找云厂商？ 答案就是你实际使用的服务模型。
为了帮你建立直觉，把三种模型放到一条"用户自治度"谱线上看会更清楚：
从左到右，用户自治度递减，但"省事程度"递增；从右到左，控制力递增，但运维成本也递增。没有任何一个位置绝对正确，只有"适合你团队现状"的位置。一个只有三个人的创业团队选 IaaS 自建全套，通常不是勇敢，是给自己挖坑；一家金融企业把核心账务系统丢给通用 SaaS，多半也不现实。
2.4 典型产品对应关系
把抽象模型落到具体产品上，记忆会牢固得多。下表不追求穷尽，只列每个位置最有代表性的几个名字，方便你建立"术语 ↔ 产品"的映射：
| 服务模型 | 代表产品 | 你得到的 | 你还要做的 |
|---|---|---|---|
| IaaS | AWS EC2、Azure 虚拟机、Google Compute Engine | 虚拟 CPU/内存/磁盘/网络 | 装系统、配环境、打补丁、做备份 |
| IaaS 存储 | AWS S3、Azure Blob、Google Cloud Storage | 无限对象存储空间 | 设计桶结构、设权限策略 |
| PaaS | AWS Elastic Beanstalk、Azure App Service、Google App Engine | 应用运行平台 | 写业务代码、管理数据 |
| SaaS | Salesforce、Google Workspace、Microsoft 365 | 现成应用 | 配置、订阅、管好账号 |
值得留意的是 AWS S3 这类对象存储的归属。它既不是"虚拟机"那种纯 IaaS，也不是"完整应用"那种 SaaS，业界通常归入 IaaS 范畴，因为它卖的是基础设施级的存储能力，你需要自己管理权限、生命周期和数据格式。抓住"我拿到的是资源还是成品"这条线，归类就不容易错。
三、工程实践要点
3.1 三种模型对比
| 维度 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 用户管理 | 操作系统及以上 | 应用与数据 | 数据 |
| 灵活性 | 最高 | 中等 | 最低 |
| 运维负担 | 最重 | 轻 | 几乎没有 |
| 上线速度 | 慢 | 快 | 最快 |
| 典型场景 | 自建数据库、专用软件栈 | 应用开发与托管 | 通用办公、CRM |
| 典型例子 | EC2、Azure VM、GCE | App Service、App Engine | Salesforce、Microsoft 365 |
3.2 选型判断顺序
面对具体业务，按下面的顺序过一遍，比对着特性表硬选靠谱。
第一问：市面上有没有现成的 SaaS？ 有，且定制需求不强，直接 SaaS，这是成本最低的路径。
第二问：没有 SaaS，但我们能接受平台的约束吗？ 比如语言、运行时、服务接口受限。能接受，用 PaaS，省下运维投入。
第三问：需要深度定制、掌控硬件层、或有特殊合规要求？ 那就 IaaS，甚至考虑私有部署。
⚠️ 常见坑：把 PaaS 当 IaaS 用——在 PaaS 平台上疯狂堆自定义脚本、改底层配置，结果既享受不到平台红利，又被平台约束卡脖子，两头不讨好。
💡 关键直觉：服务模型不是"技术先进度"的排序，而是"你愿意为省事付出多少灵活性"的选择。小团队优先往上走（PaaS/SaaS），大企业核心系统可能反而需要往下走（IaaS）。
3.3 云厂商锁定与迁移成本
选型时还有一个常被低估的变量：迁移成本。PaaS 往往绑定平台的特定 API、存储格式、部署模型，换厂商等于重写集成；IaaS 相对接近传统服务器，迁移时改造成本低一些。所以如果预判未来可能换云，尽量把核心逻辑与平台 API 解耦——比如用标准容器、标准 SQL、标准对象存储协议，而不是厂商专属格式。这不算"反云"，而是给自己的选择权留后路。
四、一个贯穿案例：从零搭一套业务系统
把三种模型放进同一个故事里，你就能体会"选型"为什么不是拍脑袋。假设你是一家教育公司的技术负责人，要上一套在线作业系统。
如果选 IaaS：你需要买虚拟机装数据库、配 Web 服务器、自己写部署脚本、自己做备份与监控。优点是整个软件栈都在你掌控中，你可以装任何想装的组件，比如自研算法库、专用协议、甚至魔改内核参数。代价是团队里至少要有一个人专职运维，否则数据库挂了没人会修。
如果选 PaaS：你把应用代码推给应用托管平台，平台自动给你配好运行环境与数据库，负载高了自动扩容，代码更新推一下就生效。团队终于可以把所有人力投在业务逻辑上。代价是——平台支持 Java、Python、Node.js 这些主流栈，但如果你要跑某个冷门语言或特殊运行时，就得跟平台的"支持清单"博弈。
如果选 SaaS：你连系统都不开发，直接用市面上的在线作业 SaaS，老师建班、布置、批改全在网页上完成，一个开发人员都不用养。代价最明显：作业系统的界面、字段、统计口径全按厂商的设计来，你想改个"按班级纬度汇总"的报表，可能等厂商排期排到下季度。
现实中的答案往往是混合的：核心的"判题引擎"自己开发（IaaS 或 PaaS），通知、邮件、日历这些通用能力买 SaaS。服务模型不是单选题，而是组合题。 架构师的核心工作之一，就是决定哪些能力自己造、哪些能力买现成。
五、常见问题（FAQ）
Q1：FaaS（函数即服务）属于 IaaS 还是 PaaS？
严格说都不是，它属于"无服务器计算"这一族，通常单独归类，详见第 5.2 节。理解它的位置有个简单办法：FaaS 连"应用实例"都不用你管理，平台按事件拉起函数、跑完回收，比 PaaS 更"免运维"。你可以把它想象成 PaaS 再往上挪一步的产物。
Q2：私有云上能用 PaaS 吗？
能。服务模型（IaaS/PaaS/SaaS）与部署模型（公有/私有/混合）是两个正交维度。企业完全可以在自己的私有云上搭建一套 PaaS 平台，或者购买部署在私有环境的 SaaS 版本。很多政企客户正是这么做的：既要 PaaS 的免运维，又要数据不出内网。
Q3：IaaS 一定比 SaaS "更先进"吗？
恰恰相反。从行业趋势看，云厂商一直在把越来越多能力"服务化"，也就是往 SaaS/PaaS 方向走，因为这对客户来说更省事。IaaS 的价值在于它是其他一切的地基，但"先进"与否是商业判断，不是技术鄙视链。
Q4：怎么跟老板解释该用哪种云？
别讲技术分层，讲投入产出：SaaS 是"买时间"，最快上线但定制有限；PaaS 是"买平台"，开发效率高但有约束；IaaS 是"买地皮"，最灵活也最费人力。让老板在"速度、控制力、人力成本"三个维度上给权重，答案自然浮出来。
一节小结
- 责任边界：IaaS、PaaS、SaaS 的分野在于用户与云厂商各管理哪些技术层。
- IaaS：用户管操作系统及以上，自由度最高、运维最重，典型如 EC2。
- PaaS：用户只管应用与数据，平台管运行时与中间件，典型如 App Service。
- SaaS：用户只用不建，最快上线、定制最弱，典型如 Salesforce。
- 判断方法：这层出问题找谁，就说明你实际处于哪种服务模型。
- 选型顺序：先找现成 SaaS，再评估 PaaS 约束，最后才考虑 IaaS。
- 组合而非单选：真实系统往往 IaaS、PaaS、SaaS 混用，核心能力自己造、通用能力买现成。
- 绑定风险：PaaS 迁移成本高于 IaaS，核心逻辑应尽量与厂商 API 解耦。
- 正交维度：服务模型与部署模型互不影响，私有云上同样可以跑 PaaS。
服务模型讲完了"卖什么"，下一节回答"放哪儿"——公有云、私有云、混合云、社区云四种部署模型，各有什么代价与收益。