Serverless

一、Serverless 的第一性原理

在讨论 Serverless 的任何技术细节之前，必须先回答一个根本问题：

Serverless 解决的不是“服务器运维问题”，而是“计算在分布式系统中的存在方式问题”。

1. 计算的瞬时性（Ephemeral Compute）

在传统架构中：

而 Serverless 的核心假设是：

计算不应被长期持有，而应在“被需要的瞬间”才存在。

这直接导出三个结论：

  1. **计算实例可以随时被创建**
  2. **计算实例可以随时被销毁**
  3. **计算实例不应承载长期状态**

2. 状态必须外置（State Externalization）

在分布式系统中：

状态是复杂度的根源。

Serverless 并不是“天然无状态”，而是：

因此：

这是 Serverless 成立的结构性前提，而不是工程实现选择。

3. 调度权的转移（Control Shift）

Serverless 的本质交易是：

用户放弃平台承诺
实例生命周期控制弹性伸缩
资源规划自动调度
容量预估SLA

Serverless 的“无服务器”，本质是“无调度权”。

二、Serverless 的概念分层模型（稳定知识骨架）

为了避免实现细节淹没原理，Serverless 的认知必须分层。

1. 概念分层结构

层级关注点是否稳定
原理层不变量、约束✅ 极稳定
架构层组件关系、职责✅ 稳定
平台层调度与治理⚠️ 半稳定
工程层优化技巧❌ 不稳定

后文所有内容都将显式归属某一层级。

三、Serverless 的架构抽象（架构层）

1. 狭义 Serverless（Serverless Computing）

标准架构公式：

Serverless = Trigger + FaaS + BaaS

其抽象含义是：

这不是实现组合，而是职责切分模型。

2. FaaS 的分层抽象

FaaS 的内部结构可以抽象为三层：

  1. 基础执行层

    • OS / 容器 / Sandbox

  2. 运行时层

    • 语言 Runtime
    • 请求绑定

  3. 用户逻辑层

    • 业务代码

分层的目的不是“解耦”，而是：让“计算实例”可以被快速创建、复用、销毁。

四、计算生命周期管理（能力模型一）

1. 冷启动的本质

冷启动并不是性能问题，而是：

计算实例从“不存在”到“存在”的必然成本。

冷启动包含的阶段：

  1. 资源调度
  2. 代码获取
  3. 运行时初始化
  4. 用户初始化逻辑

其中只有最后一步属于用户责任。

2. 冷启动优化的哲学分工

平台侧（系统性优化）

用户侧（约束性优化）

Serverless 的优化不是“消灭冷启动”，而是“驯服冷启动”。

五、弹性与调度（能力模型二）

1. 扩缩容的本质模型

扩缩容不是简单的“加机器”，而是一个闭环系统：

指标 → 决策 → 执行 → 反馈

核心变量包括：

2. 削峰与容灾的结构意义

Serverless 通过：

将流量问题从“容量问题”转化为：

时间与顺序问题

这是分布式系统的经典降维手段。

六、流量与版本治理（能力模型三）

1. 灰度发布的本质

灰度发布并非 Serverless 独有，但在 Serverless 中具备天然优势：

本质是：

通过流量切分降低变更风险。

2. 流量转发的职责边界

在 Serverless 中：

这是一个典型的控制面 / 执行面分离模型。

七、状态与编排（能力模型四）

1. 为什么需要编排

当业务出现以下特征时：

单个函数已经不足以表达业务。

2. 编排系统的架构抽象

编排系统本质由两部分构成：

它是 Serverless 补齐“复杂业务表达力”的关键拼图。

八、BaaS：Serverless 的状态容器

BaaS 不是“配套服务”，而是：

Serverless 能成立的前提条件。

它们的共同特征是：

九、Serverless 的边界与反模式

Serverless 并非银弹。

不适合的场景：

是否使用 Serverless，本质是是否接受“计算瞬时性”的约束。

十、Serverless 平台设计的核心原则

平台设计不应从功能出发，而应从原则出发：

能力设计原则
函数管理不可变版本
权限最小权限
资源平台优先保护
可观测全链路先于业务

结语：Serverless 不是终点，而是一种架构取舍

Serverless 并不是要取代微服务、容器或 Kubernetes。

它的真正价值在于：

把“计算”从“长期资源”重新定义为“瞬时能力”。

这是一种架构哲学的转变，而不仅是云产品形态的变化。

关联内容（自动生成）