第一章：Serverless入门
大家好，我是你们这门课的老师。今天咱们聊聊Serverless。
说实话，我第一次听到「Serverless」这个词，第一反应是——「没服务器？那代码跑哪儿去？」
后来真正上手了才发现，这名字起得挺有意思。不是没有服务器，而是你不用管服务器了。
什么是Serverless
Serverless，中文常翻译成「无服务器计算」。但你别被字面意思骗了——服务器当然存在，只是你不用再操心它了。
我习惯这么跟新人解释：你只管写代码，剩下的交给云平台。
传统模式下，你要部署一个Web应用，得先买台服务器，装系统、配环境、搞安全组、做监控……这一套下来，少说一两天。
Serverless模式下呢？你写好一个函数，上传到云平台，配个触发器，完事。用户请求来了，平台自动拉起实例执行；没请求了，实例自动销毁，你也不用付钱。
说白了，就是按需付费、自动伸缩。
核心定义：Serverless是一种云计算执行模型，云提供商动态管理机器资源的分配。你只需关注业务代码，无需关心底层基础设施。
Serverless发展史
这东西不是凭空冒出来的。我简单梳理一下时间线：
- 2006年：Google推出App Engine，算是PaaS的鼻祖。你上传代码，平台帮你跑。但那时候还叫「平台即服务」，不是Serverless。
- 2014年：AWS Lambda正式发布。这才是现代Serverless的起点。我记得当时圈内炸了锅——「函数也能当服务卖？」
- 2016年：Azure Functions、Google Cloud Functions相继推出。各大云厂商开始卷起来了。
- 2017年：Knative开源，把Serverless带到了Kubernetes上。嗯，这步很关键。
- 2019年至今：Serverless进入成熟期。冷启动优化、混合部署、边缘计算……各种玩法都出来了。
为什么会这样发展？你想想看，运维成本越来越高，业务迭代越来越快。谁还愿意花时间折腾服务器？
与传统架构对比
咱们直接上表格，一目了然：
| 对比维度 | 传统架构 | Serverless架构 |
|---|---|---|
| 基础设施管理 | 自己买/租服务器，自己运维 | 云平台全托管，你只管代码 |
| 弹性伸缩 | 手动扩容，或者提前预估 | 自动伸缩，从0到无限 |
| 计费方式 | 按时间付费（不管用不用） | 按调用次数+执行时间付费 |
| 部署复杂度 | 高（环境配置、依赖管理） | 低（上传代码即可） |
| 冷启动问题 | 无（服务常驻） | 有（首次调用可能延迟） |
| 适合场景 | 长运行、高负载、状态敏感 | 短任务、事件驱动、弹性需求大 |
我在项目中遇到过一件事：有个客户要做图片处理服务，每天上传量波动极大——白天几百张，晚上可能几万张。传统架构下，你得按峰值买服务器，晚上跑完就闲置了。换成Serverless后，按调用次数付费，成本直接降了70%。
小提示：不是所有项目都适合Serverless。如果你的服务需要长时间保持连接（比如WebSocket长连接），或者对延迟极其敏感（比如高频交易），传统架构可能更合适。
核心优势
我总结了几点，都是实际用下来的感受：
- 零运维：不用管操作系统、补丁、安全组。云平台全包了。
- 自动伸缩：从0到1000并发，瞬间完成。你不需要写任何伸缩策略。
- 按需付费：没请求就不花钱。对于低频或波动大的业务，省钱效果明显。
- 快速迭代：改一行代码，部署上去就生效。不用重启服务，不用停机。
- 生态丰富：云平台提供了各种触发器——HTTP请求、数据库变更、消息队列、定时任务……
嗯，这里要注意：优势归优势，但别盲目上。我曾经见过一个团队，把整个后端都塞进Lambda函数里，结果调试起来痛苦得要命。
适用场景
根据我的经验，以下场景特别适合Serverless：
- Web API / 微服务：轻量级接口，尤其是CRUD操作。
- 数据处理管道：比如图片压缩、视频转码、日志分析。
- 定时任务：每天凌晨跑个报表、清理过期数据。
- 事件驱动应用：用户上传文件后自动触发处理流程。
- 原型验证 / MVP：快速上线，验证想法，成本极低。
避坑指南：我曾经把一个需要运行30分钟的数据处理任务直接扔到Lambda上，结果超时了。后来才知道，大多数云平台的函数执行时间上限是15分钟。所以，长任务要拆成多个短任务，或者用其他方案。
好了，第一章就到这里。你可能会问：「那我到底该不该用Serverless？」
我的建议是：先从小项目开始试水。比如把一个简单的API迁移过去，感受一下开发流程和运维体验。用过了，你自然就知道它适不适合你了。
下一章，咱们聊聊Serverless的核心组件——函数计算、API网关、触发器。这些东西是怎么配合工作的？到时候见。