前端技术演化史

Serverless与FaaS

Properties1
tags部署, 托管, serverless, faas, lambda, 全栈前端

11分钟阅读

⚡ Serverless 与 FaaS

一句话定性

Serverless 不是”没有服务器”,而是**“你不用管服务器”。它把”运行时计算”从一台你要长期维护的机器,变成了一段按需触发、用完即走、按用量计费的函数**。它正是 Jamstack 缺失的那块”动态能力”——让全栈前端能写后端逻辑,却完全不碰运维。

一、它是什么 & 出现的时代

Serverless(无服务器) 是一种云计算模型;其最典型的形态是 FaaS(Function as a Service,函数即服务)。

  • 标志事件:AWS Lambda 于 2014 年发布,开创了 FaaS 这一品类(随后 Google Cloud Functions、Azure Functions 跟进)。
  • 核心理念:开发者只写一个函数(input → output),上传到云平台。平台负责何时运行、运行在哪台机器、运行几个实例、何时回收——这些全部对开发者透明。
  • 前端语境:在 2018-2023 工程化时代,Serverless 与 Jamstack 结合,成为前端补足动态能力的标准手段(Netlify Functions、Vercel Functions、Next.js API Routes 底层都是它)。

"Serverless" 是个营销词,本质是"运维责任转移"

服务器当然还在,只是从”你买、你装、你扩容、你打补丁、你 7×24 盯着”,变成了**“云厂商替你做完这一切,你只为函数实际跑的那几毫秒付费”**。它消灭的不是服务器,是”服务器运维”这个负担。

二、为什么会出现(解决上一代什么痛点)

它要替代的,是传统**“长期运行的服务器进程 / 虚拟机”** 这种部署单元的痛点:

传统常驻服务器的痛点

  1. 为峰值付费,为闲置买单:为了扛住流量高峰,你得常年开着一堆机器;但 90% 时间它们是闲的——钱白花,资源白耗。
  2. 扩容是手工活:流量涨了要手动加机器、配负载均衡、调连接池;流量落了又要记得缩。
  3. 运维拖累交付:打补丁、防宕机、保活——这些跟业务无关的活儿,吃掉了大量工程时间。
  4. 前端工程师被挡在后端之外:想加一个”发邮件""调支付”的小接口,却要去搭一整套服务器,门槛劝退。

Serverless 的回答是把粒度打碎:不再部署”一台一直开着的服务器”,而是部署”一个个按需唤醒的函数”。 没请求时零实例(零成本),来请求才拉起,流量大就自动并发拉起更多——伸缩和计费都精确到单次调用。

三、核心机制 & 为什么流行

工作机制

请求到达
   │
   ▼
平台检查:有没有"热"的函数实例?
   ├─ 有(warm)──► 直接复用,毫秒级响应
   └─ 没有(cold)──► 现场拉起一个实例(下载代码 + 启动运行时)──► 执行
                        ▲ 这段额外延迟 = cold start(冷启动)
   │
执行完 ──► 返回结果 ──► 实例闲置一段时间后被平台回收(缩到 0)
  • 按需伸缩(auto-scaling):并发请求多,平台就并行拉起多个实例;没请求就缩到零。开发者完全不用配置。
  • 按用量计费(pay-per-use):只为函数实际执行的时长 × 内存付费,空闲不收费。
  • 零运维:不碰操作系统、补丁、容量规划。

为什么前端拥抱它

"全栈前端"的关键拼图

2018-2023 工程化时代的前端工程师想做全栈,但不想也不擅长管服务器。Serverless 让他们:

  • 写一个 api/send-email.js,git push,后端接口就上线了——没有服务器、没有运维。
  • 与 Jamstack 完美互补:静态页(M)交给 CDN,动态逻辑(A)交给 Serverless 函数,补齐了 Jamstack 缺的运行时计算。
  • 元框架的 API Routes / Server Actions 底层就是它:Next.js 的 pages/api、Server Actions、以及很多平台上的 SSR(见 渲染模式演进史),部署后其实都被打包成 Serverless 函数运行。前端写起来像本地函数,部署后自动变成按需伸缩的云函数。

四、带来的新问题 / 副作用

函数化的代价

  1. 冷启动(cold start):闲置后第一个请求要等实例拉起,额外几十毫秒到数秒延迟。对延迟敏感的页面(尤其 SSR 首屏)很伤——这正是 Edge边缘运行时要解决的核心问题之一。
  2. 供应商锁定(vendor lock-in):Lambda 的触发器、权限、环境与 AWS 深度绑定,换云厂商要重写不少胶水代码。二阶效应:平台越好用,迁移越难。
  3. 本地调试难:函数运行在云端特定环境里,本地很难 100% 复现(权限、触发器、超时、并发行为),“线上才暴露的 bug”成了常态。
  4. 无状态约束:函数用完即走,不能在内存里存状态;数据库连接也容易因瞬时大量并发实例而被打爆(连接风暴)。
  5. 执行时长 / 资源上限:函数有超时和内存上限,不适合长任务、常驻连接(如 WebSocket 长连)。

五、为什么会衰落 / 现状

没有衰落,但被"边缘化"了(字面意义上)

经典的”区域型 FaaS”(如跑在某个数据中心的 Lambda)依然是后端和全栈的主力,但它在前端 SSR 场景里暴露了两个软肋——冷启动慢、且仍然部署在某个固定区域(离远方用户还是远)。

于是算力继续向用户靠近:Edge边缘运行时登场。Edge 函数用更轻量的运行时(V8 isolate 而非完整 Node 容器),把冷启动从”秒级”压到”毫秒级”,还把函数分发到全球边缘节点而非单一区域。

结果是分层格局:

  • 区域 Serverless(Lambda 等):重计算、需完整 Node API、长任务 → 仍是它的地盘。
  • Edge 函数:轻量、低延迟、贴近用户的动态逻辑(中间件、个性化、Edge SSR)→ 新前沿。
常驻服务器/VM ──► 区域 Serverless(按需,但有冷启动 + 固定区域)──► Edge 函数(毫秒冷启动 + 全球分发)
              算力向用户靠近 ───────────────────────────────────►

六、对后续技术的影响(因果链)

常驻服务器/VM(为峰值付费、运维重、前端被挡在后端外)
   │ 把"一台一直开的机器"打碎成"一个个按需函数"
   ▼
Serverless / FaaS(按需伸缩 + 按用量计费 + 零运维)   ◄── AWS Lambda @ 2014
   │
   ├──► 补足 [[Jamstack]] 缺失的"动态 API"能力 ──► 全栈前端不碰运维成为可能
   │
   ├──► 元框架的 API Routes / Server Actions / SSR 底层都跑在它上面(见 [[渲染模式演进史]])
   │
   └──► 但:冷启动慢 + 供应商锁定 + 固定区域(离远方用户仍远)
            │ "能不能更快冷启动、还跑在离用户最近的节点?"
            ▼
       [[Edge边缘运行时]](V8 isolate,毫秒冷启动,全球边缘分发)
            │
            ▼
       动态内容也能像静态一样快(详见 [[未来5到10年前端发展方向]])

历史地位

Serverless 是”算力向用户靠近”主线上承前启后的一环:它先把部署单元从”常驻服务器”打碎成”按需函数”,让计算变得弹性、廉价、零运维,从而补全了 Jamstack 的动态短板,撑起了全栈前端的时代。但它的冷启动和”固定区域”两个短板,又成了下一步的动力——把函数做得更轻、推到更靠近用户的边缘。理解 Serverless,就理解了为什么前端能”既不碰服务器、又能写后端”,以及 Edge边缘运行时究竟在优化它的哪两个痛点。

🔗 相关:部署与托管演进史 | Jamstack | CDN与静态托管 | Edge边缘运行时 | 渲染模式演进史 | Node.js | 2018-2023 工程化时代 | 未来5到10年前端发展方向

关系图谱

反向链接