Serverless
一、Serverless 的第一性原理
在讨论 Serverless 的任何技术细节之前，必须先回答一个根本问题：
Serverless 解决的不是“服务器运维问题”，而是“计算在分布式系统中的存在方式问题”。
1. 计算的瞬时性（Ephemeral Compute）
在传统架构中：
- 计算资源是长期存在的
- 服务实例被视为“稳定对象”
而 Serverless 的核心假设是：
计算不应被长期持有，而应在“被需要的瞬间”才存在。
这直接导出三个结论：
- 计算实例可以随时被创建
- 计算实例可以随时被销毁
- 计算实例不应承载长期状态
2. 状态必须外置（State Externalization）
在分布式系统中：
状态是复杂度的根源。
Serverless 并不是“天然无状态”，而是：
- 强制状态外置
- 通过平台机制降低状态管理成本
因此：
- FaaS → 只负责“计算”
- BaaS → 承载“状态、消息、持久化”
这是 Serverless 成立的结构性前提，而不是工程实现选择。
3. 调度权的转移（Control Shift）
Serverless 的本质交易是：
| 用户放弃 | 平台承诺 |
|---|---|
| 实例生命周期控制 | 弹性伸缩 |
| 资源规划 | 自动调度 |
| 容量预估 | SLA |
Serverless 的“无服务器”，本质是“无调度权”。
二、Serverless 的概念分层模型（稳定知识骨架）
为了避免实现细节淹没原理，Serverless 的认知必须分层。
1. 概念分层结构
| 层级 | 关注点 | 是否稳定 |
|---|---|---|
| 原理层 | 不变量、约束 | ✅ 极稳定 |
| 架构层 | 组件关系、职责 | ✅ 稳定 |
| 平台层 | 调度与治理 | ⚠️ 半稳定 |
| 工程层 | 优化技巧 | ❌ 不稳定 |
后文所有内容都将显式归属某一层级。
三、Serverless 的架构抽象（架构层）
1. 狭义 Serverless（Serverless Computing）
标准架构公式：
Serverless = Trigger + FaaS + BaaS
其抽象含义是：
- Trigger：计算的触发条件
- FaaS：瞬时计算执行单元
- BaaS：状态与外部能力承载者
这不是实现组合，而是职责切分模型。
2. FaaS 的分层抽象
FaaS 的内部结构可以抽象为三层：
- 基础执行层
- OS / 容器 / Sandbox
- 运行时层
- 语言 Runtime
- 请求绑定
- 用户逻辑层
- 业务代码
分层的目的不是“解耦”，而是： 让“计算实例”可以被快速创建、复用、销毁。
四、计算生命周期管理（能力模型一）
1. 冷启动的本质
冷启动并不是性能问题，而是：
计算实例从“不存在”到“存在”的必然成本。
冷启动包含的阶段：
- 资源调度
- 代码获取
- 运行时初始化
- 用户初始化逻辑
其中只有最后一步属于用户责任。
2. 冷启动优化的哲学分工
平台侧（系统性优化）
- 缓存与镜像
- 预测与预加载
- 网络与依赖内置
用户侧（约束性优化）
- 控制包体
- 控制初始化逻辑
- 接受实例随时销毁
Serverless 的优化不是“消灭冷启动”，而是“驯服冷启动”。
五、弹性与调度（能力模型二）
1. 扩缩容的本质模型
扩缩容不是简单的“加机器”，而是一个闭环系统：
指标 → 决策 → 执行 → 反馈
核心变量包括：
- 指标选择（QPS / 延迟 / 队列深度）
- 调度策略（节点级 / 实例级）
- 决策模式（稳定 / 恐慌）
2. 削峰与容灾的结构意义
Serverless 通过：
- 异步化
- 队列缓冲
- 幂等与重试
将流量问题从“容量问题”转化为：
时间与顺序问题
这是分布式系统的经典降维手段。
六、流量与版本治理（能力模型三）
1. 灰度发布的本质
灰度发布并非 Serverless 独有，但在 Serverless 中具备天然优势：
- 函数版本不可变
- 别名即路由
- 实例天然短生命周期
本质是：
通过流量切分降低变更风险。
2. 流量转发的职责边界
在 Serverless 中：
- 网关 → 接入控制
- Activator → 冷启动兜底
- Autoscaler → 容量调节
这是一个典型的控制面 / 执行面分离模型。
七、状态与编排（能力模型四）
1. 为什么需要编排
当业务出现以下特征时：
- 长流程
- 分支并行
- 事务补偿
- 状态追踪
单个函数已经不足以表达业务。
2. 编排系统的架构抽象
编排系统本质由两部分构成：
- 控制面：定义、存储、调度
- 执行面：解释流程、驱动执行
它是 Serverless 补齐“复杂业务表达力”的关键拼图。
八、BaaS：Serverless 的状态容器
BaaS 不是“配套服务”，而是：
Serverless 能成立的前提条件。
- 数据库
- 消息队列
- 对象存储
它们的共同特征是：
- 生命周期独立
- 被函数共享
- 平台级运维
九、Serverless 的边界与反模式
Serverless 并非银弹。
不适合的场景：
- 超低延迟强一致
- 长连接、常驻状态
- 高度依赖本地缓存
是否使用 Serverless，本质是是否接受“计算瞬时性”的约束。
十、Serverless 平台设计的核心原则
平台设计不应从功能出发，而应从原则出发：
| 能力 | 设计原则 |
|---|---|
| 函数管理 | 不可变版本 |
| 权限 | 最小权限 |
| 资源 | 平台优先保护 |
| 可观测 | 全链路先于业务 |
结语：Serverless 不是终点，而是一种架构取舍
Serverless 并不是要取代微服务、容器或 Kubernetes。
它的真正价值在于：
把“计算”从“长期资源”重新定义为“瞬时能力”。
这是一种架构哲学的转变，而不仅是云产品形态的变化。