1. Serverless架构总览
Serverless（无服务器）并不是“没有服务器”，而是“开发者不再直接管理服务器”。计算、存储、网络、扩缩容、补丁、可用性这些底层职责被云平台接管，开发者只交付业务逻辑与配置。理解 Serverless，关键要抓住三个特征：无需预置容量、按实际使用计费、自动弹性伸缩。以 AWS Lambda 为例，函数未执行时不产生计算费用；一次调用按毫秒计费，并配有免费额度。这与“先买一台 EC2，再按小时付费”的模型有本质区别。
需要澄清一个常见误区：Serverless 不等于“只有函数计算”。完整的 Serverless 应用通常由事件源、计算、数据、集成与可观测性共同组成。AWS 的 Serverless 技术栈可以按职责分层理解：
- 计算层：AWS Lambda（函数）、AWS Fargate（容器化无服务器计算）。
- API 与集成层：Amazon API Gateway（REST/HTTP/WebSocket）、AWS AppSync（GraphQL）、Amazon EventBridge（事件总线）、AWS Step Functions（工作流编排）。
- 数据层：Amazon S3（对象存储）、Amazon DynamoDB（NoSQL）、Amazon Aurora Serverless（关系型按需扩缩）。
- 消息与流：Amazon SQS（队列）、Amazon SNS（发布订阅）、Amazon Kinesis（流数据）。
- 身份与安全：AWS IAM（最小权限）、Amazon Cognito（用户认证）。
- 可观测性：Amazon CloudWatch（日志、指标、告警）、AWS X-Ray（分布式追踪）。
下面这张图把“事件源 → 计算 → 数据/集成 → 可观测”的典型链路与各层代表服务放在一起，便于建立整体心智模型：
与传统架构相比，Serverless 的差异不只是“少管几台机器”，而是资源模型和成本模型的改变。传统三层架构通常需要预置 EC2 实例、负载均衡器、数据库实例，并自行处理扩缩容与高可用；Serverless 则把“容量”变成按需申请的资源。下表给出一个直观对比（示例场景：一个日请求量约 50 万的 API 服务）：
| 对比维度 | 传统架构（EC2 + RDS） | Serverless（Lambda + DynamoDB） |
|---|---|---|
| 容量规划 | 需预估峰值并预留实例 | 无需预置，按请求自动扩缩 |
| 计费方式 | 按实例小时计费，空闲也收费 | 按调用次数与执行时长计费 |
| 扩缩容 | 需配置 Auto Scaling，有冷启动/预热 | 平台自动并发扩展 |
| 运维职责 | 补丁、监控、容量、高可用均需自管 | 平台负责底层，开发者关注代码与配置 |
| 典型延迟 | 稳定，但需管理连接池 | 存在冷启动，可通过预置并发缓解 |
| 适用场景 | 长连接、稳定高负载、复杂中间件 | 事件驱动、突发流量、短时任务 |
选型时不要只看“是否流行”，而要看业务形态是否匹配。以下判断依据在实践中比较实用：
- 流量是否突发或不可预测：如促销活动、IoT 上报、文件上传触发处理，Serverless 的按需扩缩优势明显。
- 任务是否短时且无状态：Lambda 单次执行最长 15 分钟，适合短任务；长时任务应选 Fargate 或 Step Functions 编排。
- 是否事件驱动：S3 上传触发转码、DynamoDB 流触发同步、EventBridge 定时触发报表，都是典型 Serverless 场景。
- 团队运维成本：若团队规模小、希望聚焦业务，Serverless 能显著降低基础设施负担。
- 成本结构：低频或波动负载通常更省；持续高负载且稳定时，预留实例或容器可能更经济。
教学示例：假设一个图片处理服务，用户上传原图到 S3，触发 Lambda 生成缩略图并写入另一个 S3 桶，元数据写入 DynamoDB。若每天上传 2 万张图，每张处理耗时约 800ms、内存 512MB，则 Lambda 计算量约为 2 万 × 0.8s = 16000 GB·s/天。按需计费下，未上传时几乎不产生计算费用；若改用常驻 EC2，则需为峰值预留实例，空闲时段仍要付费。这个例子说明：Serverless 的成本优势来自“用多少付多少”，而不是单价绝对更低。
最后要建立边界意识：Serverless 并非万能。需要长连接、超低延迟稳定响应、复杂本地缓存或特定中间件的场景，传统架构或容器化方案可能更合适。实际项目中，常见做法是混合架构——核心交易走容器，事件处理与后台任务走 Serverless。理解每一层服务的职责与限制，才能在设计时做出合理取舍。