一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

Tue, 07 Jul 2026 23:10:08 +0800

一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

SaaS、PaaS、IaaS、BaaS、FaaS、DaaS、AIaaS…… 满世界都是"aaS"。本文从三层模型讲起，逐个拆解它们的本质、责任划分与适用场景，最后给一张决策树，帮你下次选型不再发懵。

一、先搞懂：为什么会有这么多"aaS"？

想象你 2010 年开了一家创业公司，要做一款 App。那时你需要：

找机房、谈专线、买机柜
采购服务器，装系统、装数据库
配 Nginx、配负载均衡
部署业务代码、配置监控告警
凌晨三点被电话叫起来处理磁盘告警

光这些"非业务"的事就能耗掉一个小团队几个月。于是云厂商出现了，他们说：

“你不用买服务器了，我租给你；你不用装数据库了，我托管；你甚至不用写后端，我帮你写。”

XaaS 的本质就是把"非核心业务"的某一层打包成可按需使用的服务。X 是什么，就把什么服务化：

把软件服务化 → SaaS
把平台服务化 → PaaS
把基础设施服务化 → IaaS
把后端服务化 → BaaS
把函数服务化 → FaaS
……

理解了这个公式，再看满屏的"aaS"就不会眼晕了。下面我们从最经典的三层模型开始。

二、云服务三层模型：IaaS / PaaS / SaaS

这是云计算最经典的分层。从下到上：IaaS → PaaS → SaaS，越往上云厂商承担越多，越往下用户掌控越细。

2.1 IaaS：基础设施即服务

面向运维。云厂商把服务器、网络、存储虚拟化后按需出租，你拿到的是一台台虚拟机（或裸金属），剩下的 OS、中间件、应用全由你装。

典型产品：AWS EC2、阿里云 ECS、腾讯云 CVM、Azure VM、AWS S3、阿里云 OSS
你管：OS、运行时、应用、数据
厂商管：虚拟化、硬件、网络、机房
适合：需要底层控制权的团队，比如要跑自建 K8s、自管数据库、特殊内核模块

# 拿到一台 ECS 后，你还得自己干这些
ssh root@your-ecs
yum install -y nginx mysql
systemctl start nginx
# 凌晨三点被告警叫醒的也是你

2.2 PaaS：平台即服务

面向开发者。云厂商帮你把运行时（Java/Go/Node/Python）、中间件、部署流程都搭好，你只需要把代码扔上去，平台自动构建、部署、扩缩容。

典型产品：Heroku、Google App Engine、Vercel、Netlify、Render、阿里云 EDAS、腾讯云 TSF
你管：代码、数据、应用配置
厂商管：运行时、OS、虚拟化、硬件
适合：中小团队、创业项目，想专注业务不养运维

1
2
3

# Heroku 风格：一行命令上线
git push heroku main
# 不用关心服务器在哪、装了什么 OS

2.3 SaaS：软件即服务

面向最终用户。云厂商直接交付一个可用的软件，你开账号就能用，连代码都不用写。

典型产品：钉钉、飞书、Gmail、Notion、Salesforce、企业微信、Zoom、Shopify
你管：使用、配置、数据
厂商管：应用本身 + 全部底层
适合：协作、办公、CRM、HR 等通用需求，没必要自己造轮子

💡 一个判断技巧：如果你"开账号就能用"，那就是 SaaS；如果"要写代码再部署"，是 PaaS；如果"要先开虚拟机再装东西"，是 IaaS。

三、责任划分矩阵：谁在管哪一层

光看定义容易糊涂，画张矩阵图就清晰了。表格里蓝色是用户负责，灰色是厂商负责。

观察几个关键点：

数据永远归用户：哪怕是 SaaS，业务数据也是你的，云厂商不能动。这是合规底线。
IaaS 的边界在虚拟化层：你管 OS 以上，厂商管 Hypervisor 以下。
PaaS 把 OS 和运行时也接走了：你只面对"代码 + 数据"两件事。
SaaS 把应用层也接走：你只面对"使用 + 数据"。

经典段子：用 On-Prem 时，连空调坏了、机房漏水都是你的事。用 SaaS 之后，你只剩"我的数据归我"这一件事。

四、BaaS：让前端/移动开发者"少写后端"

BaaS（Backend as a Service）面向前端 / 移动开发者。它把"后端通用能力"——认证、数据库、文件存储、推送、云函数——打包成 SDK，前端调用即可，几乎不用写后端代码。

4.1 BaaS 提供的六大件

能力	解决什么	例子
认证 Auth	不用自己写登录注册、Token、OAuth	邮箱密码 / 微信 / Google 一键登录
数据库 DB	不用部署 MySQL/Mongo，直接 SDK 读写	Firestore / Supabase Postgres
存储 Storage	不用搭对象存储，SDK 直传图片视频	Firebase Storage / S3 直传
云函数 Function	写少量服务端逻辑（如发邮件、对账）	Firebase Cloud Functions
推送 Push	不用对接 APNs/FCM	FCM 模板消息
分析 Analytics	不用自己埋点统计	用户行为 / 漏斗 / 留存

4.2 BaaS vs PaaS：差在哪

很多人会把 BaaS 和 PaaS 混淆，关键区别在面向对象和抽象层次：

维度	PaaS	BaaS
面向	通用应用开发者	前端 / 移动开发者
抽象	“你的代码跑在我平台上”	“通用后端我帮你写好了，你调 SDK”
代码	你写完整后端	你几乎不写后端，只写前端
灵活	高（任意后端逻辑）	中（受 SDK 模型约束）

简单说：PaaS 给你"运行环境"，BaaS 给你"现成后端"。Heroku 是 PaaS，Firebase 是 BaaS，Vercel 介于两者之间（前端 PaaS + 边缘函数）。

4.3 BaaS 的甜蜜区与雷区

甜蜜区：

创业 MVP、个人作品：几天就能上线一个有登录、有数据库的 App
内容型/社交型小程序：CRUD 占大头，复杂逻辑少
Hackathon 项目：48 小时交付必备

雷区：

复杂业务逻辑：当你的"云函数"开始堆积上百个、互相调用时，调试和测试会很痛苦
强一致性事务：BaaS 默认的 NoSQL（如 Firestore）事务能力弱于关系型数据库
厂商锁定：SDK 渗透到前端代码每个角落，迁出成本极高
成本曲线：免费额度用完后，按调用次数计费可能比自建贵

实践经验：BaaS 适合"0 到 1"，不适合"100 到 1000"。一旦业务跑起来，往往要逐步把核心模块从 BaaS 迁回自建后端。

五、FaaS：函数即服务与无服务器架构

FaaS（Function as a Service）是"无服务器（Serverless）“的核心形态。你只写一个函数，云厂商负责：何时启动、跑几份、怎么扩缩、怎么计费。

5.1 FaaS 的四个特征

事件驱动：函数不会常驻，由 HTTP 请求、对象存储事件、消息队列、定时器等触发
按需启动：无请求时实例数为 0，不收钱；有请求时拉起实例处理
自动伸缩：QPS 高就加实例，从 0 到 10000 都不用你管
按用量计费：按执行时长 × 内存 × 调用次数，毫秒级计费

// AWS Lambda 风格：一个函数就是一个处理单元
exports.handler = async (event) => {
  const orderId = event.orderId;
  await sendNotification(orderId);
  return { statusCode: 200, body: 'OK' };
};

5.2 冷启动：FaaS 的阿喀琉斯之踵

第一次调用或长时间空闲后，云厂商需要拉镜像、初始化运行时，这段时间叫冷启动：

语言	典型冷启动
Node.js / Python	100–300ms
Java	500ms–3s
Go / Rust	50–200ms
C++（编译镜像）	100–500ms

应对方案：

Provisioned Concurrency（预留并发）：厂商始终保温一批实例，代价是要付"保温费”
精简依赖：Java 的 Spring 启动慢，换 Quarkus / GraalVM 原生镜像可大幅压缩
避免在 handler 外做重活：模块加载阶段的代码每次冷启动都会跑

5.3 FaaS 适合什么

✅ 突发流量：秒杀、抢购、IoT 海量上报
✅ 事件处理：图片上传后自动压缩、订单创建后发通知
✅ 定时任务：每天凌晨跑数据汇总
✅ Webhook 接收：接收 GitHub / Stripe 回调
❌ 长连接 / 流式：WebSocket、视频流不适合
❌ 重状态服务：函数实例是无状态的，状态要放外部 DB
❌ 超低延迟：冷启动无法保证 P99

5.4 BaaS + FaaS = Serverless

业内常说的"Serverless"通常指 BaaS + FaaS 的组合：

用 BaaS 搞定认证、数据库、存储
用 FaaS 写少量自定义逻辑

整个应用没有"常驻服务器"，按用量付费，自动伸缩。这是云原生演进的极致形态。

六、其他常见 XaaS 一览

除了上面五种，还有一堆"aaS"。这里挑常见的列一遍，方便对照：

名称	全称	一句话	代表产品
DaaS	Data as a Service	数据订阅/查询 API	天气 API、Bloomberg、企查查
AIaaS / MaaS	AI / Model as a Service	AI 能力 / 大模型 API 调用	GLM API、OpenAI、通义千问、文心一言
DBaaS	Database as a Service	托管数据库	RDS、MongoDB Atlas、PolarDB
CaaS	Containers as a Service	容器即服务	阿里云 ACK、AWS EKS、Google GKE
STaaS	Storage as a Service	对象存储	OSS、S3、COS、七牛云
NaaS	Network as a Service	网络即服务	CDN、SDN、Cloudflare
SECaaS	Security as a Service	安全即服务	WAF、DDoS 高防、Snyk
DRaaS	Disaster Recovery as a Service	灾备即服务	跨地域备份、容灾切换
WaaS / DaaS-桌面	Workspace / Desktop as a Service	工作空间 / 桌面云	阿里云无影、AWS WorkSpaces
ITaaS	IT as a Service	IT 整体外包	MSP 托管服务
BPaaS	Business Process as a Service	业务流程即服务	财务 SaaS、HR SaaS
iPaaS	Integration as a Service	集成即服务	Zapier、MuleSoft、Workato
VPaaS	Video Platform as a Service	视频即服务	声网、Twilio Video

注意 DaaS 有歧义：可以是 Data as a Service，也可以是 Desktop as a Service（桌面云）。结合上下文判断。

注意 BaaS 也有歧义：Backend as a Service 之外，有时也指 Blockchain as a Service（区块链即服务），如阿里云区块链服务。

七、如何选型：从团队到场景

没有最好的 XaaS，只有最匹配当前阶段的方案。下面这张决策树覆盖了 90% 的选型场景：

7.1 决策五步法

直接用现成软件就行？ → 选 SaaS（钉钉 / Notion / Salesforce）
要自己写代码？ → 进入下一步
前端为主，后端只是 CRUD？ → 选 BaaS（Firebase / Supabase）
是事件驱动 + 突发流量？ → 选 FaaS（Lambda / 函数计算）
有专职运维，需要底层控制权？ → 选 IaaS；否则 → 选 PaaS

7.2 按团队规模看典型组合

团队规模	典型组合	理由
个人 / 1–3 人	BaaS + SaaS	不写后端，专注产品
小团队 / 5–15 人	PaaS + DBaaS + SaaS	不养运维，用 PaaS 部署 + 托管数据库
中型 / 20–100 人	IaaS + CaaS + 部分 PaaS	开始有运维，自己跑 K8s，但用托管 DB
大型 / 100+ 人	混合云 + 多 XaaS	核心自建，非核心用 SaaS，关键能力用 IaaS

7.3 一个真实的组合案例

一个常见的中型 SaaS 创业公司技术栈：

代码托管         GitHub（SaaS）
CI/CD            GitHub Actions（SaaS）
监控告警         Datadog（SaaS / 监控 SECaaS）
日志             阿里云 SLS（PaaS）
应用部署         阿里云 ACK（CaaS / 跑在 IaaS 上）
数据库           PolarDB（DBaaS）
缓存             Redis 云版（DBaaS / PaaS）
对象存储         OSS（STaaS）
CDN              阿里云 CDN（NaaS）
大模型调用       GLM API（AIaaS / MaaS）

可以看到，真实项目几乎从不"只用一种 XaaS"，而是按层次组合：底层 IaaS 提供算力，中层用 DBaaS / CaaS / STaaS 减负，上层用 SaaS 处理通用需求。

八、避坑指南与趋势

8.1 三个常见坑

厂商锁定（Vendor Lock-in）
- BaaS / FaaS 的 SDK 渗透到代码每个角落，迁出成本极高
- 应对：核心模块抽象出适配层（Repository / Service 模式），关键逻辑可平迁
成本随用量爆炸
- FaaS 按调用次数计费，QPS 上去后可能比包年服务器贵
- 应对：监控用量曲线，高频稳定流量用包年实例，低频突发用 FaaS
数据合规边界
- SaaS 中"数据"始终归你，但物理存储在哪国、谁有访问权，要确认
- 应对：金融、医疗等敏感行业选私有化部署或本地化 region

8.2 三个趋势

PaaS 与 FaaS 融合
- Vercel、Netlify 把静态托管 + 边缘函数 + 服务端函数揉在一起，PaaS 与 FaaS 边界越来越模糊
MaaS 崛起
- 大模型 API（GLM、OpenAI）成为新一类"基础设施"，AIaaS 正在成为继 IaaS/PaaS/SaaS 之后的第四层
行业云 BPaaS
- 不只卖技术栈，还卖业务流程：金融云、医疗云、政务云把行业 know-how 也服务化

九、一张表收尾

模型	全称	面向	你管什么	厂商管什么	代表产品
IaaS	Infrastructure as a Service	运维	OS 及以上	虚拟化、硬件、网络	EC2 / ECS / CVM
PaaS	Platform as a Service	开发者	代码、数据	运行时、OS、硬件	Heroku / Vercel / EDAS
SaaS	Software as a Service	最终用户	使用、数据	全部	钉钉 / Notion / Salesforce
BaaS	Backend as a Service	前端/移动	UI、业务逻辑	通用后端能力	Firebase / Supabase
FaaS	Function as a Service	开发者	函数代码	触发、伸缩、计费	Lambda / 函数计算
DBaaS	Database as a Service	开发者	数据、Schema	数据库运维	RDS / MongoDB Atlas
CaaS	Containers as a Service	运维	容器、镜像	K8s 控制、节点	ACK / EKS / GKE
AIaaS/MaaS	AI/Model as a Service	应用集成方	Prompt、调用	模型、推理	GLM API / OpenAI

总结

一句话概括：XaaS = 把"X"服务化，让用户按需使用、按量付费。

IaaS 把硬件服务化，给运维用
PaaS 把运行环境服务化，给开发者用
SaaS 把软件服务化，给最终用户用
BaaS 把通用后端服务化，给前端/移动开发者用
FaaS 把函数服务化，给事件驱动场景用
其余的 DaaS / DBaaS / CaaS / AIaaS …… 都是把对应能力服务化的具体形态

下次再看到陌生的"aaS"，先用公式套一下：“它把什么服务化了？面向谁？我管什么？"，三问之后基本就能定位。

记住：选型不是越上层越好，而是越匹配越好。能用 SaaS 解决的别上 PaaS，能用 PaaS 解决的别上 IaaS；但如果你是金融核心系统，可能 On-Prem 才是唯一答案。技术选型的本质，是在"控制权、省心程度、成本"三者之间找平衡。

IaaS on Snow

一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

一文搞懂 SaaS、PaaS、BaaS：那些五花八门的"aaS"到底是什么

一、先搞懂：为什么会有这么多"aaS"？

二、云服务三层模型：IaaS / PaaS / SaaS

2.1 IaaS：基础设施即服务

2.2 PaaS：平台即服务

2.3 SaaS：软件即服务

三、责任划分矩阵：谁在管哪一层

四、BaaS：让前端/移动开发者"少写后端"

4.1 BaaS 提供的六大件

4.2 BaaS vs PaaS：差在哪

4.3 BaaS 的甜蜜区与雷区

五、FaaS：函数即服务与无服务器架构

5.1 FaaS 的四个特征

5.2 冷启动：FaaS 的阿喀琉斯之踵

5.3 FaaS 适合什么

5.4 BaaS + FaaS = Serverless

六、其他常见 XaaS 一览

七、如何选型：从团队到场景

7.1 决策五步法

7.2 按团队规模看典型组合

7.3 一个真实的组合案例

八、避坑指南与趋势

8.1 三个常见坑

8.2 三个趋势

九、一张表收尾

总结