2. Serverless 发展史：从物理机到容器到 Serverless 的演进
理解 Serverless 的今天，必须回顾基础设施的演进路径。这条路径的核心驱动力是资源利用率与开发效率的持续博弈。我们从物理机时代开始，逐步拆解到容器化，最终抵达 Serverless。
2.1 基础设施演进三阶段
下图展示了从物理机到 Serverless 的核心架构变化，重点关注资源隔离粒度和运维责任边界的转移。
关键认知：Serverless 并非凭空出现，它是容器化与云原生理念的自然延伸。容器解决了环境一致性问题，Serverless 则进一步解决了资源闲置与运维复杂性问题。
2.2 各阶段核心对比
| 维度 | 物理机 | 虚拟机 (VM) | 容器 (Container) | Serverless |
|---|---|---|---|---|
| 资源粒度 | 整机 | 虚拟 CPU/内存 | 进程级 | 函数/请求级 |
| 启动时间 | 分钟级 | 分钟级 | 秒级 | 毫秒级 |
| 扩缩容能力 | 手动，小时级 | 半自动，分钟级 | 自动，秒级 | 自动，毫秒级 |
| 运维责任 | 全部自建 | 虚拟化层托管 | 编排层托管 | 全托管（除代码） |
| 资源利用率 | 5% - 15% | 10% - 30% | 30% - 50% | 接近 100% |
| 计费模式 | 包年包月 | 按实例付费 | 按实例付费 | 按调用次数 + 执行时长 |
2.3 主要云厂商 Serverless 产品矩阵
当前主流云厂商均已构建完整的 Serverless 产品体系，覆盖计算、存储、数据库、网络等核心领域。下表梳理了三大云厂商的核心产品对照。
| 产品类别 | AWS | Azure | 阿里云 |
|---|---|---|---|
| 函数计算 | AWS Lambda | Azure Functions | 函数计算 FC |
| API 网关 | API Gateway | API Management | API 网关 |
| 对象存储 | S3 | Blob Storage | OSS |
| 数据库 | DynamoDB / Aurora Serverless | Cosmos DB | Tablestore / PolarDB Serverless |
| 消息队列 | SQS / SNS | Queue Storage / Event Grid | MNS / RocketMQ |
| 工作流编排 | Step Functions | Logic Apps | Serverless Workflow |
| 容器 Serverless | Fargate | Container Instances | ECI (弹性容器实例) |
选型建议：如果团队已深度绑定某朵云，优先使用该云的原生 Serverless 产品，以获得最佳集成体验和性能。如果追求多云或开源方案，可关注 Knative、OpenWhisk 等开源 Serverless 框架。
2.4 Serverless 产品架构总览
下图以 AWS 为例，展示 Serverless 应用的核心组件及其协作关系。其他云厂商的产品架构逻辑与此高度相似。
2.5 演进背后的驱动力
- 成本压力：物理机时代资源利用率极低，虚拟化与容器化逐步提升了硬件复用率，Serverless 则实现了按需付费，彻底消除闲置成本。
- 效率诉求：开发团队希望从基础设施运维中解放出来，专注于业务代码。Serverless 将运维责任完全交给云厂商。
- 弹性需求：互联网应用的流量波动日益剧烈，传统架构难以应对突发峰值。Serverless 的毫秒级弹性成为标配能力。
- 生态成熟：云厂商提供了丰富的托管服务（数据库、消息队列、监控等），使得全栈 Serverless 成为可能。
避坑提示：Serverless 并非银弹。对于长时间运行、延迟敏感或状态复杂的应用，传统容器化方案可能更合适。选型时需评估业务场景与 Serverless 的匹配度。