English version GitHub: https://github.com/geekchow/aws-lambda-guide背景本文选自开源学习指南《AWS Lambda 心智模型》中英双语。全书用一个贯穿示例串联网店 ShopFast 的checkout函数周四通过prod别名把 v7 金丝雀发布到 v8周五黑五开售前把预置并发PCProvisioned Concurrency提到 400文中的第 N 步即指该示例中的步骤完整场景见 04 贯穿示例。你在这里第 5 阶段深入 4 / 7。示例第4步Alice 被准入、第7步09:00 第一波、第8步PC 已满但 Bob 仍被准入、第9步Carol 被限流。读完本文你将知道在任何代码运行之前请求经历了什么、并发如何计算、账号并发与预留并发以及扩缩速率限制如何工作以及限流的真正含义。1. 角色回顾负责准入决策——调用方是否被允许、指的是哪个版本、是否还有并发余量出场于第 4、7、8 步准入与第 9 步以 429 拒绝。2. 内部设计2.1 调用前端Invoke Frontend位于 Region 级 Lambda 端点之后、跨多个 AZAvailability Zone可用区的无状态请求处理集群。对每个Invoke认证SigV4Signature Version 4签名版本 4签名API Gateway 以其服务主体签名。依据函数的基于资源的策略授权lambda:InvokeFunction可限定到某个Qualifier。从缓存加载函数/限定符的元数据把别名解析为版本05.2、内存大小、限额。向计数服务申请一个并发单位。向分配服务申请一个环境05.5把负载流式发送过去等待结果。释放并发单位并返回响应。调用类型改变的是谁在等待而不是核心路径类型调用方体验路径同步RequestResponse——API Gateway、Function URL、SDKSoftware Development Kit软件开发工具包等待结果限流时直接看到 429前端 → 环境如上所述异步Event——S3Simple Storage Service简单存储服务、SNSSimple Notification Service简单通知服务、EventBridge立即得到202前端放入内部队列内部轮询器稍后同步调用失败重试默认 2 次遇到限流则退避轮询式ESMEvent Source Mapping事件源映射——SQSSimple Queue Service简单队列服务、Kinesis、DynamoDB Streams没有直接调用方Lambda 托管的轮询器批量读取并同步调用2.2 并发——Lambda 唯一据以扩缩的数字并发 在途调用数 忙碌环境数 ≈ RPSRequests Per Second每秒请求数× 平均时长秒。流量平均时长并发2,000 RPS150 ms3004,500 RPS150 ms6754,500 RPS600 ms冷启动拉长时长2,700最后一行是陷阱慢代码或冷启动会成倍放大并发。缩短时长本身就是容量优化。2.3 计数服务执行的限额Region 账号限额默认 1,000ShopFast 为 3,000为 checkout 预留 800既是下限也是上限为其他函数预留未预留池始终 ≥ 100其中 prod 的 PC:50 → 400checkout 剩余的按需余量图注并发如何被切分——预留并发是一块私有切片PC 位于其内。限额作用范围触达时的效果账号并发限额Region 内所有函数无预留并发的函数共享剩余部分多出的请求 → 429预留并发RCReserved Concurrency预留并发单个函数为该函数提供保障并设上限。RC 0 表示始终限流紧急关闭开关。扩缩速率单个函数每 10 秒最多新增 1,000 个环境连续补充不累积RPS 限额单个函数可用并发 × 10防止极短调用压垮系统计数服务是一个按函数、按账号的低延迟复制计数器准入时加一完成时减一。由于它必须在远低于一毫秒内回答 Region 内的每一次调用它被分区并保存在内存中以牺牲绝对的全局精确换取速度——限额会被紧密执行但并非每一瞬间都精确到个位。2.4 限流是什么以及不是什么限流是计数服务在说没有容量预算——而不是没有机器。它表现为429 TooManyRequestsException带有ReservedFunctionConcurrentInvocationLimitExceeded或ConcurrentInvocationLimitExceeded等原因。它廉价且即时没有触碰任何环境也不计费。3. 交互分配服务计数服务调用前端API Gateway分配服务计数服务调用前端API Gateway运行并等待结果alt[未超任何限额][触达某项限额]Invoke checkout:prod (SigV4)认证、策略检查别名 → v8acquire(checkout, 账号)准许申请环境 (checkout, v8)环境租约释放200 负载拒绝附原因429 TooManyRequests图注准入握手——计数服务决定能否运行分配服务决定在哪里运行。4. ⚓ 回到示例——第 4、7、8、9 步第 4 步Alice周四 14:05。前端验证 API Gateway 的签名找到允许apigateway.amazonaws.com调用checkout:prod的策略语句把别名解析为 v8并询问计数服务checkout为 20/800账号为 140/3,000 → 准许。第 7 步周五 09:00。2,000 RPS300 在途。计数300/800 → 全部准许。这 300 个请求占用了 400 个 PC 环境中的 300 个。第 8 步Bob09:05。675 在途。计数675/800 →准许。注意计数服务既不知道也不关心 PC 已满它只检查预算。Bob 拿到热环境还是冷环境是分配服务的事05.5。那 275 个溢出环境都是新建的按需环境——在扩缩速率每 10 秒 1,000之内所以没有因扩缩而被限流。第 9 步Carol09:06。需求瞬间达到约 850。Bob 等人的冷启动拉长了平均时长推高了并发。Carol 的请求到达时checkout已有 800 在途{Type:User,message:Rate Exceeded.,Reason:ReservedFunctionConcurrentInvocationLimitExceeded}API Gateway 把 Lambda 的 429 映射为返回给 Carol 浏览器的错误客户端带抖动在 300 毫秒后重试并成功。CloudWatch 显示某一分钟Throttles 0。ShopFast 为什么接受这一点因为 RC 800 是刻意设置的护栏它保护下游支付服务商只允许约 800 个并行连接并保证其他函数保有账号 3,000 中属于它们的份额。5. 失败行为失败行为设计应对吵闹函数耗尽账号限额所有未预留的函数都被限流为关键函数设预留并发为吵闹函数设 RC 上限。突发速度超过扩缩速率429ConcurrentExecutions图呈阶梯状用 PC 应对突发或用队列SQS削峰。时长退化依赖变慢同样的 RPS 下并发暴涨 → 限流下游调用设超时对Duration和ConcurrentExecutions设告警。前端主机在请求中途宕机同步调用方看到错误/超时异步事件从内部队列重试让 handler 幂等异步与 ESM 投递是至少一次。下一篇 →05.5 分配与放置 ·返回03 概念地图 返回专栏目录