1. Serverless概念与背景
咱们先聊聊“云计算服务模型是怎么变过来的”。这节内容，是我做了十多年后端，踩过不少坑才真正理解的。Serverless 并不是凭空冒出来的技术，它是云计算层层演进的必然结果。
1.1 云计算服务模型演进
最早的时候，大家都用物理服务器。买个机器，插上电，装系统，部署应用。你想想看，那会儿扩个容要等采购周期，少说两周，多了两月。我记得2012年在电商公司，双十一前申请加机器，流程走完都到元旦了。
后来虚拟化技术成熟了，IaaS（基础设施即服务）出现。我们能快速创建虚拟机，但还得自己装系统、配网络、打补丁。说白了，还是得有人管“机器”。
再后来出现了PaaS（平台即服务），比如Heroku、Google App Engine。我们只管写代码，平台负责跑。但问题是，应用要按指定框架写，迁移成本很高。
容器（如Docker）加上编排（Kubernetes）解决了环境一致性和混合部署的问题，但运维的复杂度并没有消失——你得管理集群、节点、网络插件、存储等等。我身边不少团队，K8s 配好了，业务反而不敢动了，生怕搞崩集群。
Serverless 就是在这样背景下产生的。它的核心思想是：你只管写业务逻辑，其余的全交给平台。冷启动、自动扩缩、故障转移……这都是云平台的事。
1.2 Serverless 的定义
说了这么多背景，那到底什么是 Serverless？我自己比较认可的定义是：一种云原生开发模型，让开发者只关注业务代码，而无需关心底层基础设施的运维、扩缩和容量规划。
它有两个关键组成部分：
- FaaS（函数即服务）：比如 AWS Lambda、阿里云函数计算，你上传一段代码，平台帮你触发运行。
- BaaS（后端即服务）：比如云数据库、对象存储、身份认证这些现成的后端能力，直接通过API调用，不用自己搭建。
说白了，Serverless 不是“没有服务器”，而是“服务器对你不可见”。我记得第一次用 Lambda 时特别惊讶：写了个图片缩略图函数，传参跑完，点开日志才发现它自动扩到了30个并发实例——而我根本没配置任何集群。
1.3 与传统架构的对比
为了让你更直观地感受差异，我整理了一个对比表。你可以在看它的同时，想想自己项目里当前的模式。
| 维度 | 传统架构（虚拟机/容器） | Serverless 架构 |
|---|---|---|
| 部署方式 | 构建镜像、推仓库、更新Pod | 上传代码或配触发器，一键部署 |
| 扩缩容 | 手动/自动扩缩容器副本 | 平台自动扩缩，从0到上万级别 |
| 计费模式 | 按实例运行时长付费（即使空闲） | 按调用次数和实际执行时长付费 |
| 运维负担 | 需要管理OS、运行时、监控 | 几乎零运维（除业务代码） |
| 冷启动 | 没有（容器一直运行） | 有（首次调用或空闲后重新分配） |
| 执行时长限制 | 无强制上限（可常驻） | 通常5~15分钟（如Lambda最长15分钟） |
| 状态管理 | 可以保留本地状态（文件、内存） | 无状态设计，需依赖外部存储 |
1.4 适用场景与局限
不是所有场景都适合Serverless。我个人的经验是，以下场景用Serverless会很香：
- 事件驱动型任务：比如文件上传后自动做转码、数据库变更触发的通知、邮件发送等。这些任务短小、偶发，扩缩容根本不用操心。
- 定时巡检/定时任务：比如每天凌晨跑报表、检查服务健康状态。用定时触发器（Cron）来调度，比在服务器上维护crontab干净得多。
- 轻量级API后端：业务逻辑简单、请求量波动大的API，用Serverless很合适。我去年帮一个创业团队重构了用户服务，从6台ECS改成Lambda + API Gateway，运维成本降了80%。
- 数据处理管道：日志分析、ETL、图片处理等，天然适合函数组合。
但Serverless也有明显的局限：
- 冷启动延时：尤其是Java、C#这类语言，启动慢，不适合延迟敏感型应用。我建议用Node.js、Python或Go来避开这个坑。
- 执行时长限制：超过15分钟的任务（比如大型文件处理、复杂计算）只能用其他方式。
- 无状态约束：不能在函数内存里保存会话或临时文件，必须依赖Redis、S3等外部存储。
- 调试和本地开发麻烦：不像传统应用可以在IDE里直接跑，Serverless调试需要模拟云环境，工具链还不算很成熟。
- 供应商锁定：不同平台的函数接口、触发器、服务绑定都不一样，迁移成本较高。