使用 AWS 构建任务处理的最佳实践是什么？答案

【问题标题】：What is the best practice to architect tasks processing using AWS?使用 AWS 构建任务处理的最佳实践是什么？
【发布时间】：2021-04-08 23:23:14
【问题描述】：

我想知道如何配置 AWS Lambda、SNS 和 SQS 来处理后台任务。

我想到了三种方式。

选项 1。一个叫做consumer的函数可以通过从队列中接收任务来执行worker。

选项 2。将所有任务发送到 SNS。一名工作人员和一名 SQS 从 SNS 接收和工作。

选项 3。直接将任务从APP转发给1个SQS和1个lambda。

最关心的是是直接在应用中调用Lambda，还是使用SQS或SNS的任务消费者。

【问题讨论】：

【解决方案1】：

这取决于您当前和未来的要求：

选项 1：选择消费者 lambda 将允许您在事件中添加验证和操作。但是您的消费者 lambda 将一直运行，直到您的工作人员 lambda 运行为止。

选项 2：SNS 让您可以灵活地在未来添加新事件和新订阅者，您的应用将只需要处理 SNS。

选项 3：如果您确定将来不会有这样的其他 lambda。在这种情况下，您的应用需要配置哪种类型的事件将转到哪个 SQS。

您可以根据自己的要求选择任何选项，但我建议您选择选项 2，因为您的应用程序需要仅向 SNS 推送通知（单一集成）。在 SNS 中，您可以为不同类型的事件添加过滤器。从 SNS 也可以直接触发 lambda。

如果您的应用中不需要输出 lambda 函数，您应该使用 SNS/SQS 进行异步处理。

【讨论】：

感谢您的回答。如果有三个以上的任务，什么是好方法？如果像 SNS 或 SQS 这样的消费者出现问题，工人就会出现问题，因此您认为选项 3 是好的，您对此有何看法？
如果您将来想要添加更多任务，则选项 2 将是最好的，因为您只需要向您的 SNS 添加新订阅。 SNS 或 SQS 出错是什么意思？你能详细说明一下吗？在选项 3 中，您还拥有 SQS。
感谢您的回答。例如，它提醒我 SNS 因 AWS 而死，或者 SQS 因错误编写触发 SQS 的 lambda 函数而无法工作。我想不出一个确切的例子，但我担心存在瓶颈的风险。
如果您正确配置了应用程序，以后应该不会给您带来任何问题。 SQS 和 SNS 都是无服务器服务，因此您无需担心维护和配置。

【解决方案2】：

典型的模式是：

我猜这符合您的选项 1，但 AWS Lambda 服务充当触发各个 Lambda 函数的“消费者”。

如果有不同类型的输入（例如三个不同的任务），每个都需要不同的 Lambda 函数，则创建 3 个单独的队列，每个队列都链接到自己的 Lambda 函数（您的选项 3）。

在中间插入 Amazon SNS（如您的选项 2 所示）可以更轻松地“分叉”信息，例如为每条消息添加另一个订阅者，以防它们需要并行处理。否则就没有必要了。

【讨论】：

感谢您的回答。所以这是一种更好的方式来触发像选项 3 这样的应用程序，而无需使用消费者？
当然。 AWS Lambda 可以为您管理激活各个 Lambda 函数。没有必要写一个“消费者”。如果您不使用 AWS Lambda，则该架构将是在 Amazon EC2 实例上运行的多个工作人员。这些工人中的每一个都是他们自己的“消费者”，从队列中提取消息。但是，对于 Lambda，您将使用 推送架构，由 AWS Lambda 服务触发各个函数。