如何让AWS Lambda按设定间隔运行项目，迁移VM上crontab执行的带参jar任务

你当前的定时执行jar的场景，首先需要确认是否符合Lambda的基础使用限制，只要满足以下条件，Lambda是提升服务uptime的合适选择，AWS官方Lambda的SLA可达99.95%，无需自行维护服务器运行状态、系统补丁、故障恢复等运维工作：

• 单jar任务单次执行最长不超过15分钟（Lambda运行时长硬上限）
• 任务为定时触发的离散执行任务，无需常驻后台进程
• 任务运行时无需持久化存储大体积本地文件，临时文件可存放在Lambda自带的/tmp目录（上限10GB）

1. 代码适配
   Lambda要求Java程序实现RequestHandler接口作为执行入口，你可以将原有main方法的逻辑直接迁移到handleRequest方法中，也可以直接在该方法中调用原有jar的main方法，仅需将Lambda接收到的触发参数转换为main方法的入参数组即可，无需修改核心业务逻辑。
2. 打包Fat Jar
   使用maven的shade插件或者gradle的shadow插件，将业务代码和所有依赖打包成包含全部依赖的fat jar，需提前引入Lambda Java核心SDK依赖，Maven配置示例：

<dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-lambda-java-core</artifactId>
    <version>1.2.21</version>
</dependency>

3. 创建Lambda函数
   在AWS控制台选择对应JDK版本的Java运行时，上传打包好的fat jar，配置函数执行角色（若任务无需访问其他AWS服务，使用默认基础执行角色即可）、内存规格、超时时间（超时时间需设置为大于任务最长执行时长）。
4. 配置定时触发规则
   使用Amazon EventBridge创建定时触发规则，完全兼容原有crontab的时间表达式，触发目标选择你创建的Lambda函数，原本crontab携带的执行参数可以直接写在EventBridge的事件内容模板中，会作为入参传入Lambda函数。
5. 验证测试
   手动触发Lambda函数验证执行逻辑、参数传入是否正常，执行日志默认自动上报到CloudWatch，可直接查看执行结果、报错信息。

选择EC2更合适的场景 #

• 你的任务不符合Lambda的使用限制：比如单次执行时长超过15分钟、需要常驻进程、需要大体积持久化本地存储
• 你已经有成熟的EC2运维体系，包含监控告警、故障自动恢复、crontab执行校验等能力，无需额外学习Lambda的配置逻辑
• 任务执行频率极高，核算后Lambda的执行成本高于长期运行低配置EC2的成本

选择EC2的劣势是你仍然需要自行维护服务器的运行稳定性，包括系统补丁更新、实例故障恢复、crontab执行状态监控等，uptime需要靠自己的运维能力保障，无法直接解决你原本的uptime不足的问题。

选择Lambda更合适的场景 #

• 符合Lambda的使用限制，全托管的运行模式无需你投入任何服务器运维成本，uptime直接由AWS保障
• 任务执行频率较低，按执行时长计费的Lambda比长期运行EC2的成本更低
• 无需额外配置监控告警能力，CloudWatch默认自带执行成功率、执行时长、错误日志等观测能力

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