Serverless核心理念：FaaS与BaaS

可视化演示

架构演变：从自建厨房到云食堂

很多人第一次听到"Serverless"都以为云上真没有服务器，就像以为食堂完全不设后厨。其实，食堂仍然有后厨，只是你不需要自己买灶台、雇厨师、备食材。传统模式是为了偶尔请客，在家里装修一整个厨房：买冰箱、装煤气、屯菜、洗碗，无论有没有客人，这些成本都要承担。Serverless 模式则把厨房外包给一家云食堂，你只负责把菜谱写好，剩下的备菜、炒菜、洗碗都由后厨接管。

从物理机到虚拟机、再到容器和函数，云计算的抽象层一层层抬高。到了 Serverless 这一层，服务器、操作系统、运行时环境、扩缩容逻辑全部从开发者的视野里被抹掉。你看到的只剩“函数”和“后端服务”两种单元。Serverless 并不是一项单一技术，而是 FaaS 与 BaaS 的组合：FaaS 负责承载业务逻辑，BaaS 负责提供数据库、认证、存储等通用后端能力。

回到食堂比喻：Serverless 仍然有“后厨”，只是由云厂商统一管理和维护。你不需要关心厨师几点上班、灶台够不够用，只需要把菜谱写好、把半成品调料备齐。理解这一点，是进入 Serverless 世界的第一把钥匙。

架构特征：食堂自动加灶

云食堂和传统包厨最大的区别，是它会根据客人数量自动调整灶口。中午 12 点订单暴增，食堂立刻多开十个灶口；下午三点没有客人，灶口自动熄灭，不再消耗燃气。Serverless 架构的核心特征正是这种“事件驱动、自动扩缩、无状态、全托管”的模式。

事件驱动是 Serverless 的引擎。HTTP 请求、消息队列、对象存储上传、定时器触发，都可能成为“客人按铃”的事件源。平台收到事件后，会启动一个函数实例处理；处理完，实例进入休眠或直接被回收。因为函数实例不保存会话状态，平台可以随时创建或销毁它，所以弹性伸缩可以做到近乎实时。

在这个模型里，开发者不需要提前购买“灶台”。平台观测到等待队列变长，就自动加开实例；请求减少，就自动回收。正因如此，Serverless 特别适合流量像潮水一样忽高忽低的业务，比如电商大促、AI 模型突发推理、物联网数据上报等。

FaaS核心：订单到达才开火

FaaS 可以理解为一本“菜谱集”。每个函数就是一道菜谱，菜谱里写清楚原料和做法；顾客按铃下单，后厨才打开灶台。经典菜谱（函数）需要短小、单一、可复用，比如“生成缩略图”“解析 OCR 文本”“检查用户权限”。

函数不是一直运行的进程，而是被事件“唤醒”的临时任务。传统服务器上的应用是一个常驻服务，请求来了就处理；FaaS 则是“平时不占资源，事件来了才创建实例”。这个机制带来一个常见问题——冷启动。当新实例第一次被创建时，平台需要加载运行时、初始化环境，这段时间就是冷启动延迟。

所以，FaaS 适合延迟容忍度较高的任务：异步图片处理、消息通知、数据清洗、定时报表等。对实时性要求极高、又无法接受冷启动的核心链路，则需要额外手段，比如预留实例或保持实例常热。就像食堂必须对“订单高峰”提前预热几个灶口，才能避免客人等太久。

BaaS服务：中央厨房的半成品

有了菜谱（FaaS），还必须有调料和食材。BaaS 就是中央厨房里准备好的半成品：腌制好的肉类、切好的蔬菜、现成的酱料、可租赁的桌椅。开发者不需要自己做酸奶、搭冷库、雇收银员，直接通过 API 调用这些现成的后端服务。

典型的 BaaS 服务包括：用户认证与权限管理、云数据库、对象存储、消息队列、短信邮件、第三方支付接口等。在传统架构中，这些组件需要开发、部署、扩容、监控；在 Serverless 架构中，它们变成“开箱即用”的托管服务。FaaS 负责编排业务逻辑，BaaS 负责提供能力底座，两者像“菜谱 + 中央厨房”一样协同工作。

BaaS 不是“免费的午餐”，而是“按用量付费的半成品”。你不需要在厨房里自己做酱料，但每用一勺酱料都要计费。对 AI 服务来说，对象存储放模型文件、消息队列接收推理请求、数据库保存预测结果，这些 BaaS 组件能把后端绑定成本降到最低。

计费模型：按份收费的食堂

传统服务器的计费像“包场费”：不管有没有客人，只要包下这个场地，就要按天付钱。Serverless 的计费更像“按份收费”：客人点一份菜，就收一份菜的钱；没人点菜，后厨虽然存在，但你不付费。这个特性让低流量、突发流量的成本结构变得非常友好。

FaaS 的账单通常由三个因素决定：函数被调用的次数、单次执行的时长、为函数分配的内存或 CPU 配置。为了便于计费，平台会把执行时长按固定粒度切分，例如每 100 毫秒为一个计费单位，不足 100 毫秒也按 100 毫秒计算。不同云厂商还有免费额度，个人项目甚至可以维持在零成本。

计费模型决定了 Serverless 的适用边界：闲置免费的诱惑很大，但如果业务 24 小时持续高负载，按调用和时长付费可能会比包一台服务器更贵。就像食堂按份收费，对偶尔来吃的散客很划算，对一日三餐都在食堂吃的老客户，可能包月更便宜。

适用场景：快闪夜市与长流水席

什么时候适合租摊位，什么时候适合自己开店？这个选择同样适用于 Serverless。最适合 Serverless 的场景是“快闪夜市”：流量来得快、消失也快，突然有大批人涌来，又突然冷清。比如限时秒杀、新闻热点抓取、节假日营销活动、AI 模型突发推理请求，这些都是典型的高弹性场景。

另一类高频应用是定时任务和异步处理。定时任务往往一天只跑几次，不需要为它常驻一台服务器；异步任务对延迟不敏感，冷启动带来的影响很小。数据清洗、图片转码、视频切片、消息分发，这些“吃完就走的菜”非常适合用 FaaS 来做。反过来，如果业务是“24 小时流水席”——比如核心交易数据库、长连接网关、实时音视频流服务，就不适合后端函数化，因为平台对单次运行时长有限制，也无法保证极低延迟。

快闪夜市摊主不需要常年租大厨房，按订单备菜反而最省钱；长流水席则需要稳定的大厨房，包场更划算。选型时先算算自己的“突发倍数”，比盲目追新更重要。

选型迁移：大锅菜改小份菜单

从传统架构迁移到 Serverless，就像把一家经营多年的“大锅菜餐厅”改造成“小份菜单店”。原来的大锅是一次性炒一百人份；现在每一道菜要能独立点单、独立制作。迁移不是简单地把代码丢进函数，而是一场结构性改造。

首先要评估现状：业务是否具有突发性？对延迟的容忍度有多高？团队是否熟悉云端 API 编程？如果答案是“流量平稳、延迟敏感、团队没有云原生化经验”，那就不必强行迁移。其次，把单体应用拆成多个函数，按“单一职责”划分：登录认证一个函数、生成报表一个函数、处理图片一个函数。拆分后，还要把共享状态外置到 BaaS，例如使用 Redis、数据库、对象存储，因为函数实例本身不保存状态。

迁移的最后一步是建设可观测性。传统应用有完整日志和监控告警，函数化之后实例是临时且分散的，必须通过分布式追踪、结构化日志、调用链分析来掌握系统状态。就像小份菜餐厅需要更精细的订餐系统，才能知道哪道菜卖得好、哪个厨师效率高。

AI 应用场景

Python 演示

class Baas:    """BaaS 后端服务模拟器"""     def __init__(self):        self.calls = 0     def call(self, service_name, payload):        self.calls += 1        return "{}:{}".format(service_name, payload)  class FaaSPlatform:    """FaaS 平台: 注册函数, 触发执行, 统计费用"""     def __init__(self, unit_price=0.000002):        self.functions = {}        self.execution_count = 0        self.total_duration_ms = 0        self.unit_price = unit_price        self.baas = Baas()     def register(self, name, duration_ms):        self.functions[name] = duration_ms     def invoke(self, name):        if name not in self.functions:            raise KeyError(name)        self.execution_count += 1        self.total_duration_ms += self.functions[name]        self.baas.call("auth", name)     def calculate_cost(self):        units = self.total_duration_ms // 100 + 1        return self.execution_count * units * self.unit_price  if __name__ == "__main__":    platform = FaaSPlatform()    platform.register("thumbnail", 120)    platform.register("ocr_extract", 300)     for event in ["thumbnail", "ocr_extract", "thumbnail", "ocr_extract", "thumbnail"]:        platform.invoke(event)     print("execution_count =", platform.execution_count)    print("total_duration_ms =", platform.total_duration_ms)    print("estimated_cost =", platform.calculate_cost())

1. class FaaSPlatform:模拟 Serverless 平台，内部维护函数字典和计费累计量。
2. self.functions[name] = duration_ms注册函数，相当于把菜谱放到食堂菜单上。
3. platform.invoke("thumbnail")模拟一次事件触发，相当于顾客点了这道菜。
4. self.baas.call("auth", name)函数执行时调用 BaaS 服务，相当于后厨向中央厨房领半成品。
5. platform.calculate_cost()按调用次数和时长估算费用，对应“按份收费”模型。

常见误区

面试题