1. 无服务器架构核心概念与AWS服务全景
无服务器（Serverless）并不是“没有服务器”，而是把服务器的采购、补丁、扩缩容、可用性维护这些工作从应用团队身上移走，交给云平台。开发者只交付代码、配置和事件源，按实际调用次数、运行时长或请求量付费。理解这一点非常关键：无服务器首先是一种责任边界与计费模型的转移，其次才是一组具体服务。
以 AWS Lambda 为例，一个函数在未被调用时不产生计算费用；被调用时，平台在毫秒级拉起执行环境，执行结束后冻结或回收。与之相对，EC2 虚拟机需要你选择实例类型、维护操作系统、处理扩容；容器（ECS/EKS/Fargate）介于两者之间——Fargate 已经免去节点运维，但你仍需管理镜像、任务定义与服务编排。三者的差异可以用一张对比表看清：
| 维度 | 虚拟机 EC2 | 容器 Fargate | 无服务器 Lambda |
|---|---|---|---|
| 运维对象 | OS、补丁、扩缩容 | 镜像、任务、服务 | 仅函数代码与配置 |
| 伸缩粒度 | 实例级，分钟级 | 任务级，秒级 | 请求级，毫秒级 |
| 空闲成本 | 持续计费 | 按任务运行计费 | 近乎为零 |
| 最长执行 | 无限制 | 无限制 | 15 分钟 |
| 典型场景 | 常驻服务、数据库 | 长时任务、Web 服务 | 事件处理、API 后端 |
无服务器的核心运行模型是事件驱动。事件源产生事件，事件被路由到计算单元，计算单元处理后可能写入存储或再发出新事件。AWS 的服务全景正是围绕这条链路组织的：
- 计算：Lambda 执行函数；Step Functions 编排多步工作流。
- 接入：API Gateway 把 HTTP 请求转为 Lambda 事件；ALB 也可作为入口。
- 存储：S3 存对象，DynamoDB 存键值与文档，二者都按用量计费、自动扩展。
- 消息与事件：SQS 做队列缓冲，SNS 做发布订阅，EventBridge 做事件总线与规则路由。
这些服务不是孤立堆叠，而是通过事件契约连接。下面这张图展示了本节最值得记住的一条典型数据流：客户端请求经 API Gateway 进入 Lambda，Lambda 读写 DynamoDB，并把异步任务投递到 SQS，由另一个 Lambda 消费；同时 S3 事件与 EventBridge 规则也能触发函数，Step Functions 负责把多个 Lambda 串成有状态工作流。
从图中可以读出无服务器架构的三个关键特征。第一，入口与计算解耦：API Gateway 只负责协议转换、鉴权与限流，业务逻辑在 Lambda 中，二者可独立演进。第二，同步与异步分离：面向用户的读写在同步链路完成，耗时或易失败的任务投入 SQS 异步处理，避免请求超时。第三，事件源多样化：S3 的对象创建、EventBridge 的自定义事件、SNS 的广播都能触发同一批函数，函数成为可复用的处理单元。
无服务器并非没有代价。Lambda 单次执行最长 15 分钟，冷启动会带来几十到几百毫秒的额外延迟；函数无状态，会话与连接必须外置到 DynamoDB 或 ElastiCache；本地调试与分布式追踪比单体应用更复杂；高频调用下按量计费也可能超过预留实例的成本。因此选型时要问三个问题：负载是否突发且不可预测？任务能否拆成短时、无状态的处理单元？团队是否愿意用运维复杂度换取弹性与低空闲成本？
把上述服务串起来，一个最小可用的无服务器应用通常长这样：API Gateway 暴露 POST /orders，Lambda 校验参数后写入 DynamoDB 的 Orders 表，同时向 SQS 发送一条消息；另一个 Lambda 消费该消息完成库存扣减与通知，失败时由 SQS 的死信队列兜底。若流程涉及多个步骤与人工审批，则用 Step Functions 定义状态机，把每个 Lambda 作为状态节点，天然获得重试、超时与执行历史。这套组合覆盖了接入、计算、存储、消息与编排五类能力，也是后续章节逐一展开的主线。
最后需要建立的心智模型是：无服务器架构由事件源、计算单元、状态存储、编排与可观测性五部分构成，服务之间通过事件契约而非直接调用耦合。掌握这条主线后，再学习 Lambda 的并发模型、DynamoDB 的单表设计或 Step Functions 的状态定义，都能落到具体位置上，而不是零散地记忆服务名称。