企业官网建设流程全解析

🇬🇧 English version ｜ 📦 GitHub: https://github.com/geekchow/aws-lambda-guide

背景：本文选自开源学习指南《AWS Lambda 心智模型》（中英双语）。全书用一个贯穿示例串联：网店 ShopFast 的checkout函数，周四通过prod别名把 v7 金丝雀发布到 v8，周五黑五开售前把预置并发（PC，Provisioned Concurrency）提到 400；文中的"第 N 步"即指该示例中的步骤，完整场景见 04 贯穿示例。

你在这里：第 5 阶段，深入 5 / 7。示例第4步（Alice 拿到热 PC 环境）、第6步（创建 400 个 PC 环境）、第8步（为 Bob 按需创建环境）。
读完本文你将知道：Lambda 如何决定由哪个环境服务请求、新环境如何落到某台机器上，以及为什么热复用是常态。

这些是内部服务，依据 AWS 公开的 re:Invent 架构演讲描述。请把它们当作心智模型；名称和细节会演进。

1. 角色回顾

负责：为已准入的请求匹配一个对应版本的空闲环境——或在有余量的工作节点上创建新环境。出场于：第 4 步（热匹配）、第 6 步（为 PC 批量创建）、第 8 步（为 Bob 冷创建）。

2. 内部设计

2.1 两个服务，两个问题

把二者分开，热路径（分配服务，每次请求都调用）就能保持小而快，而缓慢的、感知容量的决策（放置服务，只在冷启动和 PC 分配时调用）则被挡在热路径之外。

2.2 分配服务眼中的环境状态

图注：分配服务追踪的生命周期——"热"仅仅意味着存在对应版本的一条空闲记录。

分配服务是分区、复制、跨 AZ（Availability Zone，可用区）部署的服务；每个分区负责一组函数的环境，并复制其状态，这样某台主机故障时不会忘记哪些环境存在。租约确保一个环境同一时刻只交给一个请求。

2.3 选择策略（简化版）

图注：先热（PC，然后复用的按需环境），冷只是最后手段。

为什么热复用是常态：响应返回后，环境被冻结而非销毁，并保持空闲一段时间（通常数分钟；不保证）。在稳定流量下，几乎每个请求都能找到一个。冷启动集中在扩容时刻、部署之后（新版本 = 还没有热环境）以及闲置期之后。

2.4 放置

放置服务选择工作节点（一台运行大量 Firecracker 微虚拟机的 EC2（Elastic Compute Cloud，弹性计算云）裸金属 Nitro 主机）时考虑：

• 容量——为 1,024 MB 插槽预留的内存/CPU（Central Processing Unit，中央处理器）余量；
• 分散——同一函数的环境分布在多个 AZ 和主机上，单台主机丢失影响很小；
• 装箱——混合不同客户/函数的负载以高效利用主机（得益于微虚拟机隔离，这是安全的，见 05.6）；
• 代码局部性——工作节点拉取版本制品（来自 S3（Simple Storage Service，简单存储服务）的 zip，或带缓存的容器镜像分块），所以热缓存有帮助。

3. 交互

4. ⚓ 回到示例——第 4、6、8 步

第 4 步（Alice，周四 14:05）。前端请求acquire(checkout, v8)。分配服务中负责checkout的分区列出 5 个预置的 v8 环境，其中 4 个空闲。它把工作节点w-1a-0419上的env-v8-pc-03租出并返回地址。前端发送 Alice 的事件；约 150 毫秒后该环境重新变为空闲。

第 6 步（周五 08:30）。PC 管理器再请求 350 个 v8 环境。放置服务把它们分散到三个 AZ（每个约 117 个）和众多工作节点；每个节点启动微虚拟机、拉取checkoutv8、运行 Init。每完成一个，分配服务就将其记为空闲（预置）。Allocated从 50 升至 400。

第 8 步（Bob，09:05）。前端请求acquire(checkout, v8)。400 个预置条目全部忙碌；过去一分钟新建的少数按需 v8 环境也都在忙。分配服务向放置服务再要一个。放置服务选中工作节点w-1c-1172；微虚拟机启动（数十毫秒），拉取代码，运行 Init（约 600 毫秒），分配服务直接把新环境交给 Bob 的请求。Bob 的响应约 750 毫秒到达，而不是约 150 毫秒。Bob 的请求完成后，这个按需环境保持空闲，下一位顾客就能热复用它。

5. 失败行为

下一篇 →05.6 执行环境 ·返回03 概念地图

📚 返回专栏目录