1.2 服务模型 IaaS/PaaS/SaaS 与 FaaS
1.2 服务模型 IaaS/PaaS/SaaS 与 FaaS
本节摘要：云计算有四种主流服务模型——IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）、FaaS（函数即服务）。它们不是"谁更好"的并列关系，而是不同抽象层——每一层都把下面那层的运维责任进一步封装。本节用责任分层图把"用户管什么 / 云厂商管什么"切到 8 个层级，并给出选型决策表。学完这节，你能在 5 分钟内对一个真实业务场景画出分层方案。
学习目标
图：四种服务模型责任分层
阅读完本节，你应当能够：
- 说出 IaaS / PaaS / SaaS / FaaS 各自的英文全称，并能用一句话描述它们的核心差异。
- 画出 8 层责任地图（应用 / 数据 / 运行时 / 中间件 / 操作系统 / 虚拟化 / 服务器 / 存储 / 网络），指出每种服务模型下用户与厂商的责任分界线。
- 针对一个真实业务场景（如"做 SaaS 化的图像处理服务"）给出分层方案，并解释为什么不全部选 SaaS 也不全部选 IaaS。
- 理解"无服务器"≠"无运维"：FaaS 仍然需要你管代码、配置、权限与冷启动。
一、问题与直觉：为什么分层比选型更重要
很多新手选云服务的策略是"看哪家便宜用哪家"，结果在 IaaS 上自建数据库、在 PaaS 上跑得战战兢兢、在 FaaS 上踩了冷启动的坑——问题不是选错，而是没理解每种服务模型要你管什么。
举一个反例：某团队为了"减少运维负担"把整个电商后端迁到 AWS Lambda。三个月后他们发现，要管的反而比 ECS 多——冷启动延迟、并发上限、函数间状态共享、第三方 SDK 兼容性、监控与日志聚合——FaaS 减少了"机器"层面的运维，但没减少"系统"层面的运维。
所以选型之前，要先理解责任边界。
二、核心原理：四类服务模型与 8 层责任地图
2.1 8 层责任地图
| 层级 | 责任方：传统 IT | 责任方：IaaS | 责任方：PaaS | 责任方：SaaS | 责任方：FaaS |
|---|---|---|---|---|---|
| 应用 | 你 | 你 | 你 | 厂商 | 你（函数） |
| 数据 | 你 | 你 | 你 | 厂商 | 你 |
| 运行时 | 你 | 你 | 厂商 | 厂商 | 厂商 |
| 中间件 | 你 | 你 | 厂商 | 厂商 | 厂商 |
| 操作系统 | 你 | 你 | 厂商 | 厂商 | 厂商 |
| 虚拟化 | 你 | 厂商 | 厂商 | 厂商 | 厂商 |
| 服务器 | 你 | 厂商 | 厂商 | 厂商 | 厂商 |
| 存储 | 你 | 厂商 | 厂商 | 厂商 | 厂商 |
| 网络 | 你 | 厂商 | 厂商 | 厂商 | 厂商 |
注意几点：
- IaaS 的责任分界线在"操作系统"：从操作系统往上你全管，往下厂商管。AWS EC2、阿里云 ECS、腾讯云 CVM 都属于这一档。
- PaaS 的分界线在"运行时/中间件"：厂商替你管好操作系统、运行时、数据库引擎、消息队列。AWS RDS、阿里云 ApsaraDB、腾讯云 TencentDB 是 PaaS。
- SaaS 的分界线在"应用本身"：你连代码都不写，直接用。钉钉、飞书、Salesforce、Office 365 是 SaaS。
- FaaS 是"轻量 PaaS"：你只写函数代码，厂商管运行时、冷启动、扩缩容。AWS Lambda、阿里云函数计算、腾讯云 SCF 都属此列。
2.2 四种服务模型的对比与典型代表
| 维度 | IaaS | PaaS | SaaS | FaaS |
|---|---|---|---|---|
| 英文全称 | Infrastructure as a Service | Platform as a Service | Software as a Service | Function as a Service |
| 你管什么 | OS 以上全部 | 应用 + 数据 | 仅使用 | 函数代码 + 配置 |
| 厂商管什么 | 硬件 + 虚拟化 | OS + 中间件 + 数据库 | 全部 | 全部 + 自动扩缩 |
| 启动时间 | 分钟级（虚机启动） | 分钟级 | 即开即用 | 毫秒级（冷启动可到秒级） |
| 弹性粒度 | 整台机器 | 实例或连接 | 用户级 | 单次调用 |
| 典型代表 | EC2、ECS、阿里云 ECS、腾讯云 CVM | RDS、Aurora、阿里云 ApsaraDB | 钉钉、飞书、Salesforce | Lambda、阿里云函数计算、腾讯云 SCF |
| 适用场景 | 自建中间件、跑老系统 | 托管数据库、消息队列 | 通用办公、CRM、HR | 事件驱动、短任务 |
2.3 责任分界线的 mermaid 视图
三、工程实践要点：场景化选型
3.1 真实业务场景：做 SaaS 化的图像处理服务
假设你要做一个"用户上传图片、自动加水印、按月订阅付费"的 SaaS。分层建议：
| 子系统 | 推荐模型 | 理由 |
|---|---|---|
| Web 控制台 | SaaS（Vercel / 阿里云 web 托管） | 静态资源托管，不值得自建 |
| 业务 API 服务 | FaaS 或容器 | 流量波动大，弹性需求高 |
| 图片处理流水线 | FaaS（事件触发） | 按图片张数计费，突发峰值天然支持 |
| 对象存储 | IaaS 中的对象存储（S3/OSS/COS） | 三家都有，差异在跨区与冷归档 |
| 元数据库 | PaaS（RDS/ApsaraDB） | 不用自己管主从、备份、监控 |
| 缓存 | PaaS（ElastiCache / 云数据库 Redis 版） | 同上 |
| 定时任务（账单） | FaaS + 定时触发 | 不需要常驻进程 |
核心判断逻辑：核心差异化业务用 PaaS/IaaS（你管），通用业务用 SaaS（厂商管）。这样你只专注自己的竞争力。
3.2 选型决策表
| 你的问题 | 推荐模型 | 反面教材 |
|---|---|---|
| 团队没有 DBA，想跑 MySQL | PaaS RDS | 自建 MySQL 在 ECS 上 |
| 流量是凌晨 2 点的批量任务 | FaaS + 定时触发 | 买 10 台 ECS 7×24 跑着 |
| 需要装 Oracle 12c 这种特殊软件 | IaaS | 强迫厂商装不存在的服务 |
| 公司全员用的 HR 系统 | SaaS | 自建一个 200 万的 HR 系统 |
| 99% 流量是 API 调用、单次耗时 200ms | FaaS | 跑在常驻容器里 |
⚠️ 常见坑：FaaS 不适合长任务。大多数云厂商的 FaaS 单次执行超时为 5-15 分钟（AWS Lambda 15 分钟、阿里云函数计算 10 分钟、腾讯云 SCF 5 分钟）。如果你跑的是 1 小时的批量分析，FaaS 不是选项。
💡 关键直觉：选 IaaS 越多，你的"云"越像传统 IDC。一个项目如果 90% 的服务都选 IaaS，几乎等同于把机房搬到了云上——只是把"采购服务器"换成了"点开控制台"。这种"假上云"既享受不到云的弹性，又额外承担了出网流量、API 调用等云特有的成本。
本节小结
- IaaS / PaaS / SaaS / FaaS 是四个抽象层，不是四个竞品。每上一层，厂商替你多管一层。
- 责任分界线是关键：IaaS 在 OS，PaaS 在中间件，SaaS 在应用，FaaS 在函数代码。
- 选型核心逻辑：差异化业务用 IaaS/PaaS，通用业务用 SaaS，事件驱动用 FaaS。
- FaaS 不等于无运维：仍要管代码、配置、权限、冷启动、并发上限。
- "假上云"陷阱：全用 IaaS 等于机房搬家，享受不到云的弹性又承担云特有成本。
- 混合分层是常态：真实业务几乎都是 IaaS + PaaS + SaaS + FaaS 混用。
下一节我们把视角从"服务模型"切到"部署模型"——公有云、私有云、混合云的决策逻辑。