Serverless 概述#

凌晨 2 点，团队刚完成一次大促扩容。运维工程师盯着监控大屏，看着服务器数量从 20 台飙升到 200 台，心跳都快了几分。这些服务器大多数时间都在空跑，只有大促那几天派上用场。更扎心的是，每台服务器每月要烧掉几百块大洋，而利用率可能连 10% 都不到。

这就是传统架构的尴尬：为峰值购买冗余，为空闲支付账单。

Serverless 的出现，正是为了解决这个痛点。在 Serverless 的世界里，服务器这个概念对开发者消失了——你不需要关心有多少台机器在跑，不需要半夜爬起来扩容，也不需要为闲置资源买单。你的代码跑在云厂商的「黑箱」里，云负责扩缩容、负责资源分配、负责底层运维。你只管写业务逻辑，按实际执行时间付费。

#Serverless 的定义

Serverless 并非真的「没有服务器」，而是一种让开发者不再感知服务器存在的架构范式。它由两大核心组成：

• FaaS（Function as a Service，函数即服务）：将业务逻辑拆分为独立的函数，每个函数响应一个事件，执行完成后即释放资源。AWS Lambda、阿里云函数计算、华为云 FunctionGraph 都属于此类。
• BaaS（Backend as a Service，后端即服务）：直接使用云厂商提供的后端服务，如数据库（ DynamoDB、CosmosDB）、认证（Auth0、Cognito）、存储（S3、GCS）等，无需自己搭建和维护。

flowchart TB
    subgraph Client["客户端"]
        WebApp[Web 应用]
        MobileApp[移动应用]
        IoTDevice[IoT 设备]
    end

    subgraph FaaS["FaaS 层"]
        Function1[函数：订单处理]
        Function2[函数：用户验证]
        Function3[函数：数据转换]
    end

    subgraph BaaS["BaaS 层"]
        DB[云数据库]
        Storage[对象存储]
        Auth[认证服务]
        Cache[缓存服务]
    end

    Client --> FaaS
    FaaS --> BaaS

    style FaaS fill:#e3f2fd
    style BaaS fill:#fff3e0

FaaS 和 BaaS 通常配合使用：FaaS 处理业务逻辑和事件驱动的工作流，BaaS 提供数据持久化和基础服务。

#Serverless 的价值主张

#成本优化：按执行计费

传统模式下，无论服务器是否在处理请求，你都得为它付钱。Serverless 采用按执行时长计费，粒度通常低至 100ms。

假设一个 API 平均每天被调用 1 万次，每次执行 50ms：

实际成本取决于厂商定价，但 Serverless 在低流量场景下的成本优势是显著的。

#弹性扩展：零到百万的瞬间跨越

传统架构的扩容需要：评估容量 → 申请机器 → 等待采购/开通 → 部署服务 → 接入负载均衡。这套流程快则几小时，慢则几天。

Serverless 函数可以在毫秒级完成从 0 到数千并发的扩展。云厂商的调度系统会根据请求量自动启动新的函数实例，无需人工干预。

sequenceDiagram
    participant Client as 客户端
    participant LB as 负载均衡器
    participant F1 as 函数实例 1
    participant F2 as 函数实例 2
    participant F3 as 函数实例 N

    Client->>LB: 请求 1
    LB->>F1: 路由
    Client->>LB: 请求 2
    Client->>LB: 请求 3
    Client->>LB: 请求 1000
    Note over LB: 自动扩容
    LB->>F1: 路由
    LB->>F2: 路由
    LB->>F3: 路由

#开发效率：从运维中解放

Serverless 极大简化了 DevOps 工作：

• 无需容量规划：云负责资源分配
• 无需服务器维护：安全补丁、操作系统更新由云负责
• 无需部署流水线复杂化：函数代码即部署单元
• 更快的迭代周期：函数独立部署，回滚粒度更细

开发团队可以更专注于业务逻辑的实现，而不是基础设施的运维。

#演进历程

Serverless 的发展经历了几个重要阶段：

Serverless 最初主要用于 Web 后端和事件处理，如今已扩展到数据工程（ETL、流处理）、机器学习（模型推理）、IoT 等多个领域。

#生态全景图

#主流云厂商 FaaS 平台

#开源 Serverless 框架

#Serverless 配套工具链

flowchart LR
    subgraph 开发["开发阶段"]
        IDE[本地调试]
        CLI[CLI 工具]
        SAM[ SAM/Serverless Framework]
    end

    subgraph 部署["部署与监控"]
        CI[CI/CD 集成]
        Monitor[监控/日志]
        Trace[链路追踪]
    end

    subgraph 运维["运维与治理"]
        Cost[成本分析]
        Sec[安全扫描]
        Policy[策略管理]
    end

    开发 --> 部署 --> 运维

#与容器相比

Serverless 和容器是两种互补的部署范式，而非简单的替代关系：

#权衡矩阵

#延伸思考

Serverless 带来了前所未有的敏捷性，但也引入了新的复杂性：供应商锁定、调试困难、执行时长限制、长连接场景不友好。

当你决定采用 Serverless 时，需要回答几个问题：

• 业务场景是否适合函数粒度的拆分？
• 如何处理函数间的状态共享和事务一致性？
• 如果云厂商涨价或服务不可用，迁移成本有多高？

Serverless 不是银弹，但它确实在特定场景下带来了巨大价值。理解它的边界，比盲目追逐它更重要。