1、Serverless 初探：什么是无服务器计算？Serverless 的发展历程与核心价值。
好，咱们直接进入正题。
很多人第一次听到「无服务器计算」这五个字，第一反应都是：没服务器？那代码跑在哪儿？
嗯，这个问题我当年也问过。说白了，这个名字确实有点误导人。服务器当然存在，只不过你不需要去管它了。你想想看，以前我们部署一个应用，得先买机器、装系统、配网络、搭环境……这一套下来，少说一两天，多则一两周。而 Serverless 要做的，就是把这些脏活累活全部抽象掉，让你只关心代码本身。
1.1 什么是无服务器计算？
无服务器计算，是一种云原生架构模式。它的核心思想是：你只管写代码，平台负责运行。
我个人习惯把 Serverless 理解为「按需执行的函数」。你写好一段逻辑，上传到云平台，然后就不管了。当有请求进来时，平台自动拉起一个环境去执行你的代码；执行完，环境自动销毁。整个过程，你不需要关心底层用了多少台机器、CPU 负载怎么样、磁盘够不够用。
核心特征：
- 无需管理服务器：你不需要登录任何机器，不需要打补丁，不需要做容量规划。
- 按实际使用付费：代码不跑的时候，一分钱不花。跑的时候，按执行次数和时长计费。
- 自动弹性伸缩：从零到上千并发，平台自动搞定，你不需要写任何扩缩容脚本。
- 事件驱动：通常由 HTTP 请求、消息队列、数据库变更等事件触发执行。
举个例子。你写了一个图片缩略图生成函数。用户上传一张照片到对象存储，这个事件触发了你的函数，函数把图片压缩成小图，再存回去。整个过程，你只写了大概 30 行代码。没有服务器，没有守护进程，没有负载均衡器。
避坑指南：
我曾经在一个项目里，把整个后端都塞进一个函数里，结果冷启动时间长达 8 秒。后来才明白，Serverless 函数应该是「小而专」的。一个函数只做一件事，做精做透。别想着在一个函数里又处理登录又处理支付又处理日志——那是在给自己挖坑。
1.2 Serverless 的发展历程
Serverless 不是凭空冒出来的。它的背后，是云计算不断抽象化的结果。
| 阶段 | 时间 | 特点 |
|---|---|---|
| 物理机时代 | 2000 年代 | 自己买硬件，自己托管，运维成本极高 |
| 虚拟化时代 | 2006 年左右 | IaaS 出现，按需租用虚拟机，但仍需管理 OS |
| 容器时代 | 2013 年左右 | Docker 出现，应用与依赖打包，环境一致性提升 |
| PaaS 时代 | 2010 年代 | Heroku、Google App Engine，部署应用不用管机器 |
| Serverless 时代 | 2014 年至今 | AWS Lambda 发布，函数级抽象，真正按需执行 |
2014 年，AWS Lambda 正式上线。我记得当时圈子里很多人都在讨论：这东西靠谱吗？函数执行完就销毁，状态怎么保存？数据库连接怎么复用？
说实话，早期的 Lambda 确实有很多限制。比如最大执行时间只有 5 分钟，代码包大小限制 50MB，没有 VPC 支持。但随着时间的推移，这些限制被一一打破。现在 Lambda 支持最长 15 分钟的执行时间，支持容器镜像，支持 Graviton 处理器，性能已经非常成熟。
2016 年之后，各大云厂商纷纷跟进。Google Cloud Functions、Azure Functions、阿里云函数计算、腾讯云云函数……Serverless 从一个概念变成了主流选择。
注意：
不要以为 Serverless 只适用于小项目。我见过一些大型企业，把核心的图片处理、数据清洗、消息推送等模块全部迁移到了 Serverless 上。关键在于，你要清楚哪些场景适合，哪些不适合。比如长时间运行的 WebSocket 服务、需要大量本地磁盘 I/O 的任务，就不太适合 Serverless。
1.3 Serverless 的核心价值
说了这么多，Serverless 到底能给我们带来什么？我总结了三句话：
- 降低运维复杂度：你不用再半夜爬起来处理服务器告警了。
- 降低运营成本：没有流量的时候，成本为零。流量波峰波谷再大，也不用提前买机器。
- 缩短交付周期：你只需要关注业务逻辑，基础设施的活儿交给云平台。
你想想看，传统架构下，一个简单的 API 接口，从开发到上线，要经过多少步骤？写代码、打包、配置服务器、配置反向代理、配置域名、配置 SSL、配置监控……而在 Serverless 下，你只需要写一个函数，绑定一个 HTTP 触发器，就完事了。
一个真实的对比：
我之前帮一个创业团队做技术选型。他们要做的是一个图片分享社区，初期用户量不大，但增长预期很高。
- 传统方案：两台 ECS 实例，一年费用约 6000 元，还需要一个兼职运维。
- Serverless 方案：函数计算 + 对象存储 + API 网关，按量付费，初期每月不到 100 元。
而且，当用户量突然暴涨时，传统方案需要手动扩容，而 Serverless 方案自动就扛住了。这就是核心价值——弹性 + 成本 + 效率。
1.4 什么时候该用 Serverless？
不是所有场景都适合 Serverless。我个人建议，以下场景可以优先考虑：
- 事件驱动的任务：比如文件处理、数据 ETL、消息通知。
- 轻量级 API：CRUD 接口、表单提交、Webhook。
- 定时任务：每天凌晨跑一次报表、清理过期数据。
- 原型验证：快速搭建 MVP，验证业务想法。
而以下场景，我建议谨慎：
- 长时间运行的 WebSocket 服务：函数有超时限制。
- 需要大量本地状态的应用：Serverless 是无状态的，状态需要外置。
- 延迟敏感型应用：冷启动可能会带来几百毫秒的额外延迟。
我的经验：
刚开始接触 Serverless 时，我犯过一个错误：把所有逻辑都写在一个函数里，结果代码又臭又长，调试起来非常痛苦。后来我学乖了，按照「单一职责」原则拆分函数。一个函数只做一件事，参数清晰，返回值明确。这样不仅好调试，也方便复用。
1.5 小结
Serverless 不是银弹，但它确实解决了很多传统架构下的痛点。它让开发者可以更专注于业务本身，而不是被基础设施拖累。
接下来的章节，我会带你一步步搭建一个完整的 Serverless 应用。从函数编写、触发器配置，到监控告警、性能优化，咱们一个一个来。
准备好了吗？咱们开始动手。