名字的误导

Serverless 不是"没有服务器"——服务器当然存在，只是你不需要管理它。

更准确的理解：把服务器的运维责任交给云厂商，开发者只关心代码。

两种主要形态

一、FaaS（Function as a Service，函数即服务）

代表：AWS Lambda、Azure Functions、阿里云函数计算、腾讯云 SCF。

模式：

  • 你上传一段函数代码；
  • 配置触发器（HTTP 请求、消息队列事件、定时任务、文件上传等）；
  • 事件发生时，平台自动分配资源、运行你的函数、返回结果；
  • 按实际运行时间和调用次数计费。

二、BaaS（Backend as a Service）

托管后端服务：数据库、对象存储、身份认证、消息队列等。

代表：Firebase、Supabase、云厂商的托管数据库服务。

核心特点

一、按需计费

传统服务器：无论有没有请求，都在运行，都在计费。

Serverless：空闲时不计费（或有极低的存储费用）。对于流量波动大、有大量空闲时段的应用，成本优势明显。

二、自动扩缩容

流量激增时，平台自动启动更多实例；流量下降时自动收缩。

三、无需运维

不用管理操作系统、打补丁、监控服务器健康、容量规划。

局限

一、冷启动（Cold Start）

如果一个函数长时间没被调用，平台可能回收其运行环境。下次调用时需要重新初始化——包括加载运行时、加载代码、建立连接。

延迟：从几十毫秒到数秒不等（取决于运行时、代码包大小、初始化逻辑）。

影响：对延迟敏感的应用（如同步 API）体验不佳。

缓解：

  • 预置并发（Provisioned Concurrency）：保持一定数量的实例常驻（但要付费，削弱了成本优势）；
  • 精简代码包和依赖；
  • 选择启动快的运行时（如 Go、Rust 快于 Java）。

二、执行时间限制

多数平台对单次执行有超时限制（如 Lambda 最长 15 分钟）。

不适合：长时间运行的任务、需要保持长连接的场景。

三、无状态

函数实例是临时的、可被回收的。不能在内存中保存状态——状态必须存到外部（数据库、缓存、对象存储）。

四、本地状态与连接复用

虽然实例可能被复用（"热"实例），但不能依赖这一点。

数据库连接是个典型问题：每个函数实例可能建立独立连接，流量大时连接数爆炸（需要用连接池或 RDS Proxy 一类的方案）。

五、厂商锁定

各家的 API、触发器、运行时支持都不同。迁移成本高。

六、调试与可观测性

本地调试相对困难（虽然有模拟工具），分布式追踪和日志需要专门配置。

七、成本不一定更低

对于持续高负载的应用，Serverless 可能比常驻服务器更贵。

简单估算：如果函数的运行时间占比超过一定比例（有说法是 50%–70%，取决于定价），包月服务器更划算。

适合什么

  • 流量波动大、有明显波峰波谷的应用；
  • 事件驱动的处理（图片/视频转码、文件处理、数据清洗）；
  • 定时任务（Cron）；
  • Webhook 处理；
  • 原型验证和小项目（快速上线，无需运维）；
  • 流量不可预测的初创项目。

不适合：

  • 长时间运行的计算；
  • 延迟极度敏感的服务；
  • 持续高负载的稳定服务；
  • 需要精细控制底层环境的应用。

一个认知

Serverless 的核心价值不是"省钱"，而是降低运维负担、加快交付速度、让资源与实际使用精确匹配。

对团队来说，它把"要不要为这个小功能单独部署一台服务器"的问题彻底消除了。

说明：本文为云计算的知识整理。