5.2 无服务器计算 Serverless

5.2 无服务器计算 Serverless

本节摘要：无服务器计算（Serverless）把"服务器"三个字从你的工作里抹掉：你只管写代码，平台按事件触发执行、按实际用量计费、自动弹性伸缩。本节拆解 FaaS 的事件驱动模型，讲清"按需付费、自动扩展、免运维"三大优势，也诚实指出冷启动延迟、超时限制、有状态应用不友好三大限制，最后给你一张"什么时候该用 Serverless"的选型地图。

核心问题

阅读完本节，你应当能够：

1. 解释"无服务器"的真实含义：没有服务器要你管，不等于没有服务器。
2. 画出事件源 → 函数 → 触发 → 回收的执行链路。
3. 说出 Serverless 的三大优势与三大限制。
4. 判断 API 后端、事件处理、定时任务等场景是否适合 Serverless。

一、问题与直觉

"无服务器"这个名字很有迷惑性——好像服务器真的消失了。其实服务器一直在，只是不再由你管。云厂商把"服务器"这个抽象彻底收走了：你不必选规格、不必打补丁、不必处理故障，你只需要交一段代码和一个触发条件。

为什么会有这种需求？想想一个典型的图片处理服务：白天用户上传图片，晚上几乎没人用。如果租一台虚拟机 24 小时开着，白天用 10% 晚上用 1%——90% 的算力在闲置，账单却一分不少。Serverless 把计费粒度从"租机器"变成"按执行"：有请求才跑、跑多久算多久，没请求零成本。这让"为峰值容量付费"彻底成为历史。

更妙的是弹性。传统服务器弹性要预先配置、手动或半自动伸缩；Serverless 的弹性是"默认行为"——突发一万个请求，平台自动拉起一万个实例；请求过去，实例自动回收。你什么都不用做，弹性自己发生。这就是"免运维 + 按需计费 + 自动伸缩"三合一的吸引力所在。

二、核心原理

2.1 FaaS：函数即服务的执行模型

FaaS（Function as a Service）是 Serverless 的核心形态。你写一个函数（处理图片、处理消息、处理 HTTP 请求），配置好触发条件（对象存储有新文件、消息队列有新消息、API 网关收到请求），剩下的事——拉起运行环境、执行函数、返回结果、回收资源——全部由平台完成。

2.2 三大优势

按需付费：只为实际执行的时间付费（通常按"执行次数 + 执行时长 × 内存规格"计费），闲置零成本。自动扩展：平台根据请求量自动伸缩函数实例，无需配置扩容策略。免运维：没有服务器要打补丁、没有集群要管、没有容量要规划——平台全包。这三点的组合，把"运维"这项成本从你的账单上删掉了。

2.3 三大限制

冷启动延迟：函数闲置后被再次调用，要先初始化运行环境，可能多出数百毫秒到数秒的延迟——对延迟敏感的场景（如支付回调）是硬伤。超时限制：单次函数执行通常有超时上限（如几分钟），长任务、长连接不适用。有状态不友好：函数无状态，内存、本地文件都在执行后回收，不适合需要保存会话状态的应用。三者合起来说：Serverless 擅长"短、小、事件驱动"，不擅长"长、大、有状态"。

三、工程实践要点

3.1 Serverless 与传统计算对比

⚠️ 常见坑：把"常驻型核心服务"硬塞进 Serverless。一个 24 小时高频调用的服务用函数跑，按执行计费可能比包一台虚拟机还贵，还要忍受冷启动与超时。Serverless 的省钱前提是"负载稀疏、波动大"，不是"永远在跑"。

💡 关键直觉：Serverless 选型的试金石是问三个问题——"负载规律吗？执行时间短吗？需要状态吗？" 负载不规律、执行短、无状态，三个都满足，Serverless 几乎是最优解；有一个不满足，就要权衡。

3.2 典型适用场景

API 后端：轻量接口、移动端后端，突发流量多，用函数按调用计费非常划算。事件处理：对象存储上传触发图片处理、消息队列触发业务逻辑，天然的事件驱动。定时任务：定时备份、定时清理、定时报表，用定时触发器即可，无机器空转。数据处理：日志清洗、格式转换、短小批处理，按执行付费。

3.3 不适合的场景

长连接服务（WebSocket）、实时音视频、需要本地缓存的机器学习推理、以及任何需要"常驻 + 低延迟"的服务，都不适合标准 FaaS。这些场景要么用容器，要么等 Serverless 容器（托管容器）这类新形态成熟。理解"边界"比记住"优点"更重要——选错形态的代价，通常要跑一阵子账单才能看出来。

四、常见问题（FAQ）

Q1：Serverless 和函数计算是一回事吗？

函数计算（FaaS）是 Serverless 的代表形态，但 Serverless 是更大的概念——包括无服务器数据库、无服务器存储、无服务器容器等。可以说"函数计算是最典型的 Serverless"，但"Serverless 不等于只有函数计算"。

Q2：冷启动能优化吗？

能，常见手段：预留并发（预热实例）、减小函数体积（依赖精简）、用更快的运行时。但优化有上限，冷启动不会完全消失。对延迟极敏感的场景，需要评估是否值得为"省运维"付出"加延迟"的代价。

Q3：Serverless 和容器能混用吗？

能，而且越来越常见。典型架构：核心长驻服务用容器（K8s 编排），突发短任务用函数，中间用消息队列解耦。这种"容器扛底、函数扛峰"的混合架构，正在成为云原生应用的主流形态之一。

Q4：Serverless 的成本怎么估算？

按"调用量 × 平均执行时长 × 内存规格"估算，加上触发源（如 API 网关）的费用。关键是要有真实负载数据——拿一周的调用曲线算账，比拍脑袋准得多。也可以先用免费额度试跑，再决定是否大规模迁移。

Q5：调试和监控麻烦吗？

确实比传统方式多一层抽象，但现代工具已大幅改善：本地调试框架、日志与追踪服务、无服务器监控面板都已成熟。核心思路不变——函数要有结构化日志、要接监控告警，只是工具变了，工程素养的要求没变。

五、Serverless 的架构模式

一个成熟的 Serverless 应用，往往不是"一个函数包打天下"，而是几种模式的组合。

模式一：API + 函数。API 网关接 HTTP 请求，分发到不同函数处理，函数内部调用数据库、消息队列等托管服务。适合移动端后端、微服务接口。

模式二：事件驱动链。对象存储收到文件 → 触发处理函数 → 处理结果写入数据库/消息队列 → 再触发下游函数。像一条管道，每个环节一个函数，各管一段，天然解耦。

模式三：混合架构。常驻服务（容器）处理主业务，函数处理突发与批处理（图片转码、报表生成、异步通知），消息队列串联两者。这是兼顾"稳定 + 弹性"的务实组合。

三种模式的共同点：把"执行"拆成小的、独立的、无状态的动作，让平台帮你调度与伸缩。 这正是云原生方法论（第 5.5 节）在计算层的一种具体表达——应用被拆得越细，平台越能高效调度，弹性与成本控制越好。

六、Serverless 的运维真相

Serverless 免掉了"服务器运维"，但没有免掉"工程运维"——只是把工作内容从"管机器"变成了"管函数"。认真说，有三件事反而是 Serverless 特有的运维重点。

第一是函数的依赖与版本管理。函数体积直接影响冷启动，依赖臃肿会让启动变慢；函数版本、别名、灰度发布要管好，否则一个坏版本上线就是事故。传统应用"部署一个包"，Serverless 是"管理几十上百个函数版本"，维度更细。

第二是可观测性。函数实例短暂、动态，传统"登录机器看日志"的方式完全失效。必须依赖分布式追踪与结构化日志：用请求 ID 串联一次调用的完整链路，才能定位"哪个环节慢了、错了"。可观测性做不好，Serverless 应用就是"黑盒"，出了问题无从下手。

第三是安全边界。函数经常直接对接数据库、对象存储，权限配置要格外小心——一个函数权限过大，等于给攻击者留了后门；密钥、环境变量要进密钥管理服务，不能写死在函数代码里。函数数量多、权限细，安全审计的颗粒度也相应变细。

这三件事加在一起，结论是：Serverless 省的是"机器运维"，花的是"函数治理"。 如果你期待"彻底不用运维"，那会失望；如果你愿意把运维精力从"看机器"转向"管函数、做可观测、控权限"，Serverless 会把你从最枯燥的那部分运维里解放出来。

七、Serverless 的选型决策树

把散落的要点整理成一张决策树，选型时顺着走一遍就行。

第一步问：应用能拆成"短小无状态"的函数吗？ 不能（长连接、有状态、常驻），跳过 Serverless，用容器或虚拟机。

第二步问：负载是"稀疏/突发"还是"持续稳定"？ 持续稳定（24 小时高频），Serverless 按执行计费可能更贵，用包时长的机器更划算；稀疏突发，Serverless 是省钱最优解。

第三步问：延迟敏感吗？ 极敏感（支付回调、实时互动），冷启动可能是硬伤，要评估预留并发或放弃；容忍秒级延迟，Serverless 没问题。

第四步问：团队愿不愿意建立"函数治理"体系？ 愿意（版本、追踪、权限都有人管），上 Serverless 能享受最大收益；不愿意，先小规模试点，别一步到位。

四步走完，答案基本清晰。决策树的价值不在于给出"标准答案"，而在于逼你把"负载、延迟、状态、治理能力"四个变量都摆到台面上——这些变量想清楚了，选什么都错不到哪去。这也是 Serverless 学习最值得记住的一点：它考验的不是"会不会调函数"，而是"会不会从负载特征反推架构"。

本节速览

• 无服务器真义：没有服务器要你管，不等于没有服务器。
• FaaS 模型：交代码 + 配触发，平台负责拉起、执行、回收。
• 三大优势：按需付费、自动扩展、免运维。
• 三大限制：冷启动、超时限制、有状态不友好。
• 选型试金石：负载不规律、执行短、无状态，三个都满足才最划算。
• 适用场景：API 后端、事件处理、定时任务、短小数据处理。
• 不适合：长连接、低延迟强敏感、常驻有状态服务。
• 混合趋势：容器扛底、函数扛峰，Serverless 容器正在模糊边界。

Serverless 解决了"算力在哪跑"，但"数据离用户太远"的问题还在——下一节讲边缘计算，看计算怎么从中心搬到离数据源最近的地方。