Serverless 与 FaaS

从一个浪费说起: 凌晨三点, 没人用, 但在付钱

先看传统部署的一个尴尬: 假设有一个"生成月度报表"的服务, 每月就月初被调用几次, 每次跑几分钟, 但为了那几次, 得 7x24 跑着一台(或几台)服务器. 凌晨三点, 月中, 没人用的时候--服务器照样开着, 照样计费.

更普遍的浪费: 为应对流量峰值, 按峰值容量备机器, 但大部分时间流量远低于峰值--多备的容量全在空转烧钱.

问题的本质: 为"容量"付费(机器开着就计费), 而不是为"实际使用"付费. 容量和使用之间的差, 就是被浪费的钱和资源. Serverless 要消灭的正是这个差.

Serverless 到底是什么: 三个核心特征

"Serverless(无服务器)"是个有点误导的名字--服务器当然还在, 只是不再需要感知和管理它们. 判断一个东西是不是真 Serverless, 看它是否同时具备三个特征:

这三点环环相扣: 因为事件驱动, 平台知道"现在没事干"→ 于是缩容到零 → 于是不执行就不计费. 三者合起来, 才实现了"为使用而非为容量付费".

两种形态: FaaS 与 BaaS

Serverless 通常以两种形态出现, 分工不同:

FaaS 是 Serverless 最具代表性的形态--也是本篇和第 03 篇 Knative 的重点. 它的模型极简: 写一个函数, 声明它被什么事件触发, 平台负责其余一切(拉起, 扩缩, 销毁, 计费).

# 一个典型的 FaaS 函数(伪代码): 只写这段逻辑
def handler(event, context):
    # event 里是触发信息(比如上传的文件, HTTP 请求体)
    image = event['file']
    thumbnail = make_thumbnail(image)   # 业务逻辑
    save(thumbnail)
    return {"status": "ok"}

# 不用写: 服务器, 监听端口, 扩缩容, 负载均衡, 进程管理...
# 平台看到"有文件上传"事件 → 自动拉起这个函数 → 跑完 → 销毁

绕不开的代价: 冷启动

"缩容到零"听起来很美, 但它带来 Serverless 最著名的痛点--冷启动(Cold Start). 逻辑很直接: 缩容到零意味着实例数 = 0, 这时来了一个请求, 平台得现场拉起一个新实例, 加载运行时, 加载代码, 初始化(连数据库, 读配置), 然后才能开始处理请求. 这段"从零准备好"的时间, 就是冷启动延迟(几百毫秒到几秒). 如果实例已经是热的(刚处理过请求, 还没被销毁), 直接处理 = 热启动, 很快.

这是个无法回避的根本权衡: 想要"闲时零成本", 就得接受"被唤醒时有延迟". 对延迟不敏感的场景(异步处理, 定时任务, 低频接口), 冷启动无所谓; 但对要求稳定低延迟的在线核心链路(比如用户下单的主接口), 偶尔几秒的冷启动可能不可接受.

缓解手段有: 保留少量"预热实例"(但这就牺牲了一部分"缩容到零"的省钱), 用更轻量的运行时, 减小代码体积和初始化开销. 缓解冷启动往往意味着放弃一部分省钱--又是复杂度/成本的权衡(第 01 篇).

适用边界: 什么场景适合, 什么场景别碰

这是本篇最该记住的部分. Serverless 不是万能的, 它有清晰的"甜区"和"雷区":

其他要权衡的代价

除了冷启动和成本, Serverless 还转移来几项复杂度(回应第 01 篇"复杂度守恒"):

• 调试和可观测性变难: 函数转瞬即逝, 无固定实例, 传统"登录服务器看日志"行不通, 更依赖可观测性系列那套指标/日志/追踪--而且追踪一条跨多个函数的请求尤其有挑战.
• 厂商绑定(Vendor Lock-in): 各家 FaaS 的函数签名, 事件格式, 配套服务都不同, 深度用了某家就很难迁走. 这正是第 03 篇 Knative 想缓解的--把 Serverless 建在开放的 K8s 上.
• 无状态约束: 函数随时被销毁, 不能依赖本地内存/磁盘保存状态, 状态必须外置(数据库, 缓存).
• 执行时长 / 资源上限: FaaS 平台通常限制单次执行时长和内存, 跑不了重型长任务.