AWS结合Serverless框架实现订阅自动续费的最佳方案

你的核心需求是每个用户独立的30天延迟触发任务，不是固定周期跑全量批处理，别用网上很多教程提到的定时扫表方案，费钱还容易出问题，结合你已经在用Serverless框架的现状，直接用下面这套组合就行，改造成本极低：

核心架构 #

• 触发端直接用EventBridge Scheduler，别用老的CloudWatch定时规则
  用户付完订阅费的瞬间，直接在你的订阅创建接口里调用Scheduler的创建接口，建一个一次性调度任务，触发时间就设成当前时间加30天，目标直接绑定你已经部署好的Lambda函数就行。
  这个服务本身帮你存储所有定时任务，最长支持提前1年设置调度，触发精度到秒级，自带重试和死信队列能力，比你自己搭延迟队列、维护定时任务存储省90%的代码量，成本还极低——中小业务基本在免费额度覆盖范围内，超量后每百万次调度成本不到1美元，比其他方案性价比高很多。
• 计算层直接复用你现有Lambda就行，不用重构现有服务，单独加个对应handler处理调度请求即可，逻辑按这个顺序写能避开大部分坑：
  1. 先做幂等校验：拿调度传过来的用户ID、订阅单ID查MongoDB，确认这个订阅周期没扣过费、状态正常，防止重复扣款
  2. 校验通过后先执行扣余额逻辑，扣费成功再更新MongoDB里的订阅文档（比如续期30天、更新上次扣费时间），顺序别搞反，不然容易出现订阅续期但钱没扣到的资损问题
  3. 任何一步报错直接抛异常，让Scheduler按你配置的规则自动重试，别自己吞异常标记为成功处理
• 存储层你现有的MongoDB基本不用做架构改动，就给订阅文档加两个辅助字段：last_charged_at存上次扣费时间，idempotency_key存每次扣费的唯一标识，配合幂等校验逻辑防重复即可

避坑：不推荐的常见方案 #

• 别用固定速率定时任务+扫MongoDB的模式：比如每天跑一次Lambda扫所有到期待扣费的用户，一来触发精度最差能差24小时，用户体验差；二来用户量上来之后全表扫描性能差，Lambda执行时间拉长后费用变高，还容易漏处理数据
• 别用SQS延迟队列：SQS最长延迟时间只有15分钟，根本撑不起30天的延迟需求，自己做消息轮转的复杂度太高，完全没必要
• 别用Step Functions的等待状态：Step Functions按执行时长收费，一个任务等30天的成本是EventBridge Scheduler的几十倍，性价比极低

可选优化配置 #

• 要支持用户取消订阅、提前续费的话，直接在对应操作的接口里调用Scheduler的更新/删除接口，把之前创建的30天调度任务改时间或者删掉就行，不会出现取消订阅后还被扣费的问题
• 给Scheduler配置死信队列接收失败任务，超过最大重试次数的任务全存入队列，配个简单的告警，人工介入处理异常即可，基本不会丢任务
• 后续要是有固定每月指定日期统一扣费的需求，直接在同一个Scheduler里创建cron类型的周期调度就行，不用更换服务

实操提醒：记得给Scheduler配置对应的IAM权限，允许它调用你的Lambda；另外Lambda连接MongoDB记得复用连接池，别每次冷启动都新建连接，容易把MongoDB连接数打满。

内容的提问来源于stack exchange，提问作者Red Vic