Step Functions配套限流SQS消费者并发节流方案咨询

现有架构 #

现有架构如下图所示：

当前问题与已评估方案缺陷 #

当前架构存在核心瓶颈：单账户Lambda默认最大并发执行数上限为1000个，极易触发服务节流，需要落地可完全自主管控的限流能力。目前已完成7类常见方案的评估，均存在明显缺陷，无法满足需求：

• 方案1：申请Lambda并发配额提升
  该方案实现难度最低，但会大幅抬升系统潜在工作负载，既未触及问题根因，也无法提供自定义限流所需的灵活性。
• 方案2：API层限流
  该方案仅能覆盖API触发的Step Functions（以下简称SFN）执行场景，无法覆盖SFN的其他触发源；同时限流触发时会直接向客户端返回4xx响应，影响业务侧使用体验。
• 方案3：SFN前添加普通SQS队列
  队列可承接海量事件实现削峰填谷，是架构优化的可选方向，但普通SQS队列本身不具备限流能力，且SQS无法直接触发SFN执行，需新增中间层Lambda通过代码调用触发SFN，无额外管控逻辑的前提下无法解决并发超限问题。
• 方案4：SFN前添加FIFO SQS队列
  参考公开博客的实现思路，可通过虚拟消息组控制并行处理的消息数量，但该方案中SQS消费者仅负责触发SFN，无法反映系统实际工作负载，在工作负载不均的场景下，无法按实际负载分配并发，场景适配性较差。
• 方案5：使用Kinesis Data Stream
  通过预定义shards（分片）、*batch-sizes（批大小）*实现限流逻辑，但该方案存在和方案3完全一致的缺陷。
• 方案6：配置Provisioned Concurrency（预留并发）
  若已在SFN前部署SQS，可为SQS消费者Lambda配置固定预留并发，取值可结合账户最大允许并发配额、SFN单执行的并行任务数计算，但并发配额耗尽后SQS仍会重试投递消息，超过最大重试次数后消息会进入DLQ（死信队列），存在消息异常丢失风险。
• 方案7：基于CloudWatch指标切换EventSourceMapping（类熔断器模式）
  该方案基于SFN前部署SQS及消费者Lambda的架构，配置CloudWatch指标触发管控Lambda：指标达到阈值时临时禁用SQS到消费者Lambda的事件源映射，待系统负载降低后再重新启用映射，方案参考架构如下图：
  
  但该方案无法找到节流触发前的合适前置预警指标，且CloudWatch指标粒度为1分钟，管控动作存在明显滞后，无法提前规避节流问题。

咨询诉求 #

寻求可实现全链路限流管控、有效规避Lambda并发节流的可行技术方案。

内容的提问来源于stack exchange，提问作者Christopher Will