0

在 AWS IoT 中，我可以创建一个规则来路由传入的 mqtt 有效负载以由 lambda 处理。同样，我可以编写一个 lambda 来将 mqtt 消息发送到设备（传出）。我的问题：

  1. 是否存在 IoT Core 可能永远无法将传入消息移交给 lambda 的风险？
  2. 同样，是否存在 lambda 永远无法将传出的 mqtt 消息发送到设备的风险？

换句话说，我如何保证（或在架构上提出至少提高交付可靠性而又不会过度使用的解决方案）lambda 接收/发送 mqtt 消息？这就是为什么要使用 SQS 的原因吗？我们将要发送的传出消息作为 SQS 主题。Lambda 接收它并使用 mqtt 协议中的至少一次传递选项发送消息。如果出于某种原因我没有收到 ACK 我从 SQS 回滚出队或将其放入不同的“稍后处理”队列（或 DLQ）？

4

1 回答 1

0

如果我们谈论的是非超大规模物联网应用程序，AWS 在服务之间丢弃消息不应该让您夜不能寐。IoT Core -> Lambda 设置非常好。AWS 服务非常可靠。建筑之神不会因为这个选择而对你皱眉。*

不过，在我们大喊YAGNI并回家之前，我们应该承认正常大小的应用程序有充分的理由对消息进行排队（IoT Core -> SQS -> Lambda）。

SQS 队列有很多花里胡哨，但对于普通人来说可能不是必备品。相反，正常大小的 MVP 应用程序尽早跳上 SQS 列车的情况归结为两个原因：

  1. 错误处理的便利性： 让我们面对现实吧，比起 AWS 错误，我们可能更应该担心我们自己的错误导致 lambda 错误。队列为我们提供了暂停和重播功能，以防我们的 lambda 代码失败。错误显示在 DLQ 中，而不是日志中。
  2. 便宜： SQS 不是脑部手术，既不复杂也不昂贵。那为什么不呢？

* 如果您热衷于担心可靠性，备份和跨区域冗余可能是更好的投资选择。

于 2021-11-05T10:58:58.560 回答