章节摘要:第 1 章给了全景,这一章钻进三个核心概念内部——FaaS 的函数到底怎么跑(事件驱动、无状态、自动伸缩、按需付费)、BaaS 提供哪些托管能力、以及把它们粘起来的事件驱动架构是怎么回事。读完你会理解 Serverless"为什么能这样工作"。
阅读完本章,你应当能够:
三个概念是同一枚硬币的三面:FaaS 是"计算"、BaaS 是"能力"、事件驱动是"把它们粘起来的胶水"。
钻进 FaaS 的内部机理——函数生命周期、无状态与伸缩的关系、按需付费怎么算,并配代码示例。
逐类讲清 BaaS 提供的托管后端能力:数据库、存储、认证、消息队列、网关,以及怎么选。
事件驱动是 Serverless 的灵魂。这节讲它怎么把函数和 BaaS 解耦地串起来,同步与异步的边界在哪。
先理解 FaaS 这个"计算单元"本身(2.1),再看它依赖的 BaaS"能力池"(2.2),最后看事件驱动如何把它们编排成系统(2.3)。
2.1 FaaS 计算 ──► 2.2 BaaS 能力 ──► 2.3 事件驱动编排 (跑什么) (用什么) (怎么串)
本章三个概念在时间上其实有先后,了解这个顺序能帮你建立"谁为谁铺路"的感觉。事件驱动的思想最老,源自企业系统集成时代的发布订阅模式,当时它解决的是"大型组织里几十个系统怎么互通"。FaaS 把这个思想接收了过来:函数天然的"被唤醒"形态,恰好就是事件驱动的消费者。BaaS 最年轻,它是在 FaaS 落地后被"倒逼"出来的——函数跑起来后人们才发现状态没地方放、连接会被打爆、认证没法做,于是厂商按函数的使用模式重新设计了一批托管服务。所以三者的关系不是并列的三块积木,而是一条因果链:老思想(事件驱动)借新载体(FaaS)复活,又催生了新生态(BaaS)。带着这条链读 2.1 到 2.3,每个设计细节背后的"为什么"都会清晰一层。

三道检验题:①模块级变量缓存为什么"可以用但不能依赖"?(2.1 执行环境复用)②你的函数潮涌建连把数据库连接打爆,除了加连接代理还有什么思路?(2.2)③"半同步半异步"的混合链为什么是最差选择?(2.3 案例复盘)答不出的回对应小节重读,这三题覆盖了本章八成的实践价值。
本章三节构成 Serverless 的技术内核:FaaS 的执行模型(实例的生命周期、冷启动对策全景)、BaaS 的服务版图(数据、消息、认证等托管能力的四项核查)、事件驱动的粘合逻辑(触发器、编排、契约治理)。自检三问:冷启动的三类对策各适用什么延迟预算;引入一个 BaaS 前要核查哪四件事;通知事件与携带事件怎么选。三问能答,本章的工程判断力就到手了——它们都直接会在下一章的平台与工具选型中被用到。本章也是全书的分水岭:前一章回答"要不要用",本章回答"怎么用好"——后面两章分别落到平台实操与开发实践,而本章的三个内核概念会像钉子一样把后续内容钉在墙上。
给三个对比锚帮记本章内核:锚一,函数像临时工(随叫随到、干完就走、不占工位——所以别把重要状态放它兜里);锚二,BaaS 像外包(专业的事交专业的人,但合同条款要盯四项——主权、配额、一致性、可观测);锚三,事件像邮差(只管送到不管读懂——读懂的契约要靠户籍制度管理)。三个锚都是生活比喻,但比喻的边界也要说清:临时工的"冷启动"在比喻里没有对应物(临时工报到不用预热),这正是提醒你别把比喻用过头的地方——比喻帮入门,边界帮深入,两者都要拿。
最后留一道自测题:给你团队现在最痛的一个业务流程,能否在十分钟内画出它的事件驱动版草图——事件源在哪、几个函数、各自碰什么 BaaS、幂等键是什么?画得出草图的流程才值得进方案评审;画不出的部分,正是回本章重读的信号。这道题也是下一章平台选型的热身——草图里的每个构件,都是选型清单里的一行需求。
再补一句与第 5 章的伏笔连接:本章的三个内核(函数、服务、事件)在第 5 章都会长出运营的枝叶——函数要观测、服务要算账、事件要治理契约;学本章时在脑子里给这三个位置留好钩子,到第 5 章收获时挂上去,知识的结构感就是这样一钩一挂长出来的。