English version GitHub: https://github.com/geekchow/aws-lambda-guide你在这里第 6 阶段 / 共 6 阶段完整走查。读完本文你将知道把整个贯穿示例作为一个连续故事在每一跳都看到各组件的内部机制来自深入篇。A 部分——周四安全地上线 v8本图回答新代码如何在不改动任何调用方的情况下进入生产放置服务PC 管理器别名 prodCodeDeploy版本存储CI/CD 流水线放置服务PC 管理器别名 prodCodeDeploy版本存储CI/CD 流水线10 分钟: v8 告警安静UpdateFunctionCode → $LATEST1PublishVersion(code-sha256)2版本 8不可变3CreateDeploymentprod: 7 → 8, Canary10%4路由 {7: 0.9, 8: 0.1}5目标集合变化6创建约 5 个 v8 环境(Init 不在请求路径)7FunctionVersion8, routing {}8目标集合变化9v8 环境补到 50淘汰 v7 环境10图注部署 发布不可变快照再分步、受守护地移动指针PC 跟随指针。图中缩写CI/CDContinuous Integration / Continuous Delivery持续集成/持续交付、PCProvisioned Concurrency预置并发。$LATEST→ v805.1。UpdateFunctionCode只改变草稿。PublishVersion把代码按CodeSha256和完整配置Node.js 22、1,024 MB、10 秒冻结为版本8。这个编号永不复用、永不可改。别名变为加权05.2。prod{主版本 7, 附加 {8: 0.10}}。APIApplication Programming Interface应用程序编程接口Gateway 仍调用checkout:prod。PC 跟随05.3。prod上的 PC 50 被重新分配为约 45 个 v7 / 5 个 v8。每个新 v8 环境现在就运行InitAWS_LAMBDA_INITIALIZATION_TYPEprovisioned-concurrency在任何顾客到来前加载好优惠券规则。B 部分——周四 14:05Alice 的热请求金丝雀期间本图回答对一个热请求每个组件做了什么每一跳传递了什么env-v8-pc-03分配服务计数服务调用前端API GatewayAlice 浏览器env-v8-pc-03分配服务计数服务调用前端API GatewayAlice 浏览器POST /checkout{购物车, 优惠码 BF26}1Invoke checkout:prodSigV4 事件 JSON2策略通过, prod →随机 0.07 低于 0.10 → v83acquire(checkout)20/800, 账号 140/30004准许5acquire(checkout, v8)6租用 env-v8-pc-03(空闲, 预置)7经 Runtime API 投递事件8解冻, handler 148 ms(ddb, 优惠规则已在内存)9POST /response10释放11200 负载12200 {orderId: 9917}13图注一次预置的热调用——没有启动、没有 Init约 150 毫秒 handler 加几毫秒路由。跳传递的数据内部发生了什么来自深入篇G → FE已签名的Invoke请求、事件 JSON前端认证检查资源策略是否允许apigateway.amazonaws.com调用限定符prod05.4FE别名prod记录无状态的单请求掷币 → v8记为ExecutedVersion805.2FE → CSacquire(checkout)计数器函数 20/800账号 140/3,000 → 准许05.4FE → ASacquire(checkout, v8)找到空闲的预置 v8 条目 → 租出05.5FE → E经 Runtime API 的事件解冻已冻结的微虚拟机handler 使用 Init 时的状态运行05.6E → FE → G响应 ≤ 6 MB环境回到空闲释放并发单位REPORT行没有Init Duration图中缩写SigV4Signature Version 4签名版本 4。C 部分——周五大促08:30——预热Application Auto Scaling 的计划任务在function:checkout:prod上设置MinCapacity400。PC 状态IN_PROGRESSPC 管理器请放置服务再创建 350 个 v8 环境分散在三个 AZAvailability Zone可用区。每个工作节点启动一个 Firecracker 微虚拟机、拉取 v8、运行 Init。分配服务把每个环境登记为空闲预置。约 08:33Allocated400, StatusREADY。09:00–09:06——全景本图回答需求上升时PC、溢出和限流如何层层叠加否: 第 801 个起是有: 前 400 个没有有没有需求上升09:00 300 并发09:05 675 并发09:06 850 并发计数服务:在途低于 800?429 限流(Carol)分配服务: 有空闲 v8 PC 环境?热 PC 环境约 150 ms(09:00 第一波)有可复用的空闲按需环境?热按需环境约 150 ms放置服务新建Init 约 600 ms(Bob)图注严格顺序的三层——预算计数服务、预热池PC、然后按需创建。09:00——第一波。2,000 RPSRequests Per Second每秒请求数× 0.15 秒 300并发。计数300/800准许。分配400 个预置环境中 300 个忙碌。利用率 0.75溢出 0p9999th percentile第 99 百分位延迟约 180 毫秒。09:05——Bob。约 4,500 RPS →675并发。前端把prod解析为 v8此时已无权重。计数675/800 →准许。它不知道 PC 已满它只守护预算。分配400/400 预置环境忙碌最近新建的按需环境也忙碌 → 请求放置服务。放置服务选中工作节点w-1c-1172微虚拟机启动拉取代码Init在 Bob 的请求内部运行initTypeon-demand其中优惠券拉取约 400 毫秒。handler 151 毫秒。Bob 看到约 750 毫秒。REPORT … Init Duration: 600.47 ms。指标ProvisionedConcurrencySpilloverInvocations把他计入。新环境之后保持空闲→ 下一位顾客热复用它。目标跟踪看到利用率 1.0开始把 PC 推向 600——但要几分钟后。09:06——Carol。冷启动拉长了平均时长于是所需并发冲到约 850。Carol 的请求到达时已有 800 在途计数800/800 →拒绝原因ReservedFunctionConcurrentInvocationLimitExceeded。没有触碰任何环境不计费。API Gateway 返回错误Carol 的客户端带抖动重试300 毫秒后成功。这正是护栏在起作用checkout背后的支付服务商只能承受约 800 个并行连接而其他函数也保住了账号 3,000 中属于它们的份额。带标注的架构图与 03-concept-map.md §3.3 相同的协作图现在在每一跳叠加了示例数据。包含控制面的泳道版本见 diagrams/lambda-architecture.drawio。SigV4 Invokeacquire: 675/800 通过第 801 个 → 429申请 v8400 个 PC 环境热租用溢出:新建启动 Init600 ms制品制品PC 400API Gatewaycheckout:prod调用前端prod → v8计数服务分配服务v8 PC 环境08:30 已 Init放置服务v8 按需环境(Bob)版本 8zip 1,024 MB / 10 s自动扩缩08:30 → 400D 部分——大促之后12:00计划任务设置MinCapacity50PC 环境退役Shutdown 阶段扩展刷出遥测数据。复盘指标0 错误约 2% 溢出调用1 分钟限流约 0.3% 的请求均已重试成功。行动项明年计划 PC 700缩短 Init懒加载优惠券以降低溢出延迟保留 RCReserved Concurrency预留并发800因为下游限制是真实存在的。v7 仍在原封未动——在团队清理旧版本之前它一直是回滚目标。回顾问题已被解决第 1 阶段的痛点是必须在需求到来之前决定容量以及通过修改运行中的服务器来部署。在这次走查中ShopFast 从未给机群定过规模计数服务按并发预算准入请求分配服务复用热环境放置服务只在需要时创建新的 Firecracker 微虚拟机。在冷启动不可接受的地方预置并发把 Init 挪到了 08:30。而部署从未触碰任何运行中的服务器或调用方v8 是一个不可变版本生产通过移动prod别名切换过去——带着十分钟的金丝雀以及随时可用的一条命令回滚。下一篇 →07 自测与实验 ·返回03 概念地图 返回专栏目录