1. 课程导入与Serverless全景

在传统应用架构中，无论使用虚拟机还是容器，团队都要为“服务器是否存在、是否健康、容量是否足够”持续负责。Serverless 并不是“没有服务器”，而是把服务器的申请、扩缩容、补丁、可用性维护等责任转移给云平台，开发者只交付业务逻辑与事件处理规则。Azure 上的 Serverless 主要由 Azure Functions（计算）、Azure Logic Apps（工作流编排）、Azure Event Grid（事件路由）、Azure Service Bus / Event Hubs（消息与流）、Azure API Management（API 网关）以及 Azure Durable Functions（有状态编排）等组成。理解这些组件的分工，是后续 29 章能够落地的前提。

一、Serverless 的定义与核心价值

Azure Serverless 可以概括为三个特征：事件驱动、按需伸缩、按用量计费。以 Azure Functions 的消费计划为例，函数在无请求时可缩容到零，不产生计算费用；请求到来时由平台在数百毫秒到数秒内拉起实例。计费维度通常包括执行次数、执行时间（GB·s）和出站流量。这与 IaaS 中“先开一台 VM，再按小时付费”的模式有本质区别。

核心价值体现在四个方面：

• 降低运维负担：无需管理操作系统、运行时补丁和主机扩容。
• 成本与负载匹配：低频任务几乎不产生计算成本，突发流量由平台自动扩容。
• 加速交付：一个函数即可成为可部署单元，配合 CI/CD 可快速迭代。
• 天然集成事件生态：Blob 上传、队列消息、HTTP 请求、定时器、数据库变更都可作为触发器。

二、与 IaaS、PaaS 的边界

三者不是替代关系，而是责任划分不同。IaaS 中用户管理 OS 及以上全部内容；PaaS（如 App Service）中用户管理应用与配置，平台管理 OS 与运行时；Serverless 中用户只管理函数代码、绑定配置和少量应用设置，平台管理实例、伸缩与可用性。判断是否适合 Serverless，可以问三个问题：是否由事件驱动？负载是否波动或不可预测？单次执行是否较短（通常建议 5 分钟内，消费计划默认上限 10 分钟）？若三个答案都是“是”，Serverless 通常是优选；若需要长连接、常驻内存、极低延迟或特殊内核依赖，则更适合容器或 VM。

三、适用场景与不适用场景

典型适用场景包括：文件上传后生成缩略图、订单创建后发送通知、定时清理临时数据、Webhook 接收与转发、IoT 消息入库、轻量 API 后端。不适用场景包括：长时间运行的计算任务、需要 GPU 的工作负载、需要固定公网 IP 且长连接的服务、对冷启动极度敏感的毫秒级交易系统。需要说明的是，Azure Functions 也提供高级计划和专用计划，可预置实例、接入虚拟网络，从而缓解冷启动与网络隔离问题，但成本模型会相应变化。

四、本课程将构建的应用蓝图

为了让知识形成闭环，本课程将围绕一个“订单处理与通知”示例应用展开。它的数据流是：客户端通过 API Management 提交订单 → Functions 校验并写入 Cosmos DB → 通过 Service Bus 发送“订单已创建”消息 → 另一个 Functions 消费消息并调用通知服务 → 失败消息进入死信队列 → Durable Functions 负责超时补偿与状态查询。整个链路覆盖 HTTP 触发器、队列触发器、绑定、Durable 编排、Application Insights 监控与 Key Vault 密钥管理。下面的 SVG 展示了这一蓝图的结构与数据流向。

五、学习路径与关键判断

后续章节会按“先单点、后编排、再治理”的顺序推进：先掌握 Functions 的触发器与绑定，再引入 Service Bus 与 Event Grid 解耦，随后用 Durable Functions 处理长流程与补偿，最后补齐 API Management、监控告警、密钥管理与成本控制。学习过程中建议始终带着三个判断：这个环节是否真的需要 Serverless？失败时消息去了哪里？如何从 Application Insights 中定位一次失败调用？把这三个问题贯穿始终，就能把零散的服务串成可运行、可观测、可维护的架构。