使用 AWS lambda 的异步后台作业答案

【问题标题】：Async background jobs with AWS lambda使用 AWS lambda 的异步后台作业
【发布时间】：2020-09-15 12:17:41
【问题描述】：

我想创建一个 REST API，让调用者提交作业的输入，该作业将在后台运行一分钟左右。因此，API 应该生成一个后台作业并立即返回一个作业 ID。然后，客户端可以向另一个端点查询作业状态和结果。

我脑子里第一个跳出来的想法是这样的：

API“提交作业 lambda”在数据库中创建作业记录并将输入提交到 SQS 队列
“Worker lambda”轮询 SQS，执行工作并更新数据库中的工作
API“查询作业 lambda”从数据库返回作业记录

为此，worker lambda 必须有足够的超时时间才能完成一项大型工作。 API lambdas 总是很快的，因为它们只是进行数据库操作并提交给 SQS。

我仍然需要 2 个 lambda 表达式让我很困扰。但是如果我理解正确的话，在它向调用者返回响应后，就不可能继续执行 lambda 函数了。我还考虑过可能对事件使用 Kinesis 而不是 SQS，因为执行顺序并不重要，每个调用者都希望在合理的时间内完成他的工作。我的流量模式可能是 100.000 个工作岗位的爆发，然后几天什么都没有。我也在考虑在每个工作中支持多个子工作，这样每个工作实际上就是 1-100 个工作单位。

我不想为工作人员托管实例，例如ECS 上的容器；我只想依赖无服务器概念。

这是一个不错的设置还是有更好的设置？

【问题讨论】：

听起来不错，我会尝试这种方法。请注意，我按小时支付 kinesis，因此 SQS 听起来是一个更好的计划，请尝试一下，如果有任何问题，稍后再决定切换。

标签： amazon-web-services aws-lambda amazon-sqs amazon-kinesis

【解决方案1】：

这看起来是 AWS Step Functions 的一个很好的用例。

您可以从API Gateway 启动状态机执行，这将返回执行 ID。

该执行 ID 可用于执行的query the status，它正在执行所有必要的后台处理

【讨论】：

我也是这么想的！这消除了对一个 Lambda 函数的需求。给 OP 的一个注释：你说的是 10 万个工作的爆发。这对 Step Functions 来说已经足够了，但如果您的系统变得更大，Step Functions 的并发执行次数限制为 1m。 docs.aws.amazon.com/step-functions/latest/dg/… 只是为了让你意识到它;-)
仅供参考，虽然步进函数看起来很棒，但在这种规模下运行它们比 SQS 更昂贵。每 10 万个带步骤的作业将花费 7.5 美元，而使用 SQS 则不到 0.1 美元。请参阅 aws.amazon.com/step-functions/pricing 和 aws.amazon.com/sqs/pricing 如果这个想法是每隔几天就爆发到 100k，它可以很快加起来，可能值得额外的开发。
成本绝对是一个因素。当您认为代码是您的团队在维护、安全和理解方面的责任时，增加的成本（以货币计）可能值得 Step Functions 路线可以给您带来的安心和简单。正确答案取决于团队:)

【解决方案2】：

您使用 SQS 的方法听起来不错 - 100.000 并不是什么大问题，即使使用 dynamodb 作为数据存储，我也会完全无服务器。

当然有 2 个 lambda，一个用于处理 HTTP 请求，第二个用于完成工作。确保启用预置并发以正确处理预期流量 - https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/

关于 Kinesis ，对于您的方案来说，这听起来并不完美，因为您可能有数天没有任何流量，但 kinesis 流按小时计费，您无法将其关闭但删除。

我会坚持计划尽可能简单，如果出现任何阻止程序，我会尝试其他方法。

【讨论】：