一、无服务器架构概述：什么是无服务器计算、与传统架构的对比、核心优势与挑战

好，咱们直接进入正题。

无服务器计算，这个名字其实有点误导人。我第一次听到这个词时，心里想的是：「没有服务器？那代码跑在哪儿？」

后来我才明白，它不是说没有服务器，而是说——你不用管服务器了。你只管写代码，剩下的交给云平台。

1.1 什么是无服务器计算

说白了，无服务器计算是一种执行模型。云服务商负责管理所有基础设施，包括服务器、操作系统、网络、存储等等。你只需要上传代码，然后定义触发条件。

举个例子。我写一个图片缩略图处理函数。传统做法是：买一台服务器，装好系统，部署应用，配置 Nginx，然后写代码。无服务器呢？我直接把函数代码扔到云上，告诉它：「只要有新图片上传到 S3，你就自动执行这个函数。」

完事。服务器？不存在的。至少对我来说不存在。

嗯，这里要注意。无状态这个特性，既是优势也是约束。我在项目中就踩过坑——一开始把用户登录状态存在函数内存里，结果下次请求过来，状态全丢了。后来才改用 Redis 或数据库来存。

1.2 与传统架构的对比

咱们直接看个对比表，这样更直观。

维度	传统架构（服务器）	无服务器架构
基础设施管理	自己买服务器、装系统、打补丁	云平台全包，你只管代码
扩缩容	手动扩容，或者提前预估流量	自动扩缩，从 0 到无限
计费方式	按服务器租用时间付费（24小时）	按实际执行次数和时长付费
启动时间	服务器一直运行，响应快	冷启动有延迟（几百毫秒到几秒）
状态管理	可以轻松维护内存状态	无状态，需要外部存储
调试难度	本地可复现，调试方便	本地模拟有限，生产调试较麻烦
适用场景	长运行、高负载、状态复杂的应用	短任务、事件处理、弹性需求高的场景

你想想看，传统架构就像自己开餐馆——你得自己买菜、洗菜、炒菜、洗碗。无服务器呢？你只管炒菜，其他都有人帮你搞定。

但也不是说无服务器就完美。我记得有一次，一个定时任务跑在 Lambda 上，每次执行要 15 分钟。结果 Lambda 最大超时时间是 15 分钟，刚好卡在边界上。后来我不得不把任务拆成多个小函数，用 Step Functions 编排。

1.3 核心优势

聊完对比，咱们说说无服务器到底好在哪里。

1. 降低运维成本——不用再半夜爬起来修服务器了。我有个朋友，以前做电商，每次双十一前都要通宵扩容。用了无服务器之后，双十一那天他在家陪孩子看动画片。
2. 弹性伸缩——流量从 10 到 10 万，系统自动适应。你不需要提前算峰值，也不用担心资源浪费。
3. 按需付费——开发环境、测试环境，没流量的时候零成本。我算过一笔账，一个低频 API，用传统服务器一年要花几千块，用无服务器一年可能就几十块。
4. 快速迭代——部署一个函数只需要几秒钟。改一行代码，上传，完事。不用打包、不用重启服务。

1.4 挑战与局限

当然，无服务器也不是银弹。我踩过的坑，说出来给你提个醒。

• 冷启动延迟——函数长时间不调用，下次触发时要重新初始化环境。Java 和 .NET 尤其明显。我曾经用 Java 写了一个函数，冷启动要 5 秒多。后来换成 Node.js，降到 200 毫秒。
• 执行时长限制——大部分平台限制函数最长执行 15 分钟。长任务？得拆。
• 调试困难——本地跑得好好的，一上生产就出问题。日志不够细，又没法 SSH 进去看。我后来养成了一个习惯：每个函数都加详细的日志，关键路径打点，方便排查。
• 供应商锁定——每个云厂商的函数计算 API 都不一样。从 AWS Lambda 迁移到阿里云函数计算，代码基本要重写。
• 状态管理复杂——无状态是设计原则，但很多业务天然有状态。比如 WebSocket 长连接、用户会话。这些场景需要额外引入 Redis 或数据库。

1.5 什么时候该用，什么时候不该用

这个问题，我经常被问到。我的回答很简单：

适合用无服务器的场景：

• API 后端（尤其是流量波动大的）
• 事件处理（文件上传、消息队列消费）
• 定时任务（数据备份、报表生成）
• 数据处理管道（ETL、图片转码）
• 微服务和 BFF（Backend For Frontend）

不太适合的场景：

• 长连接应用（WebSocket 游戏、实时协作）
• 高计算密集型任务（视频转码、机器学习训练）
• 延迟敏感型应用（高频交易、实时控制系统）
• 状态复杂的单体应用（迁移成本太高）

嗯，说白了，无服务器不是万能的。但它确实解决了很多传统架构的痛点。我个人习惯是：能用无服务器的，优先用；不能用的时候，再考虑容器或虚拟机。

下一章，咱们会深入函数计算的核心概念，包括触发器、运行时、冷启动优化这些实战内容。到时候我会拿几个真实项目案例来讲，保证干货满满。