多个SQS队列 vs 一个SNS主题

Question

今天我们进行了一场关于最佳解决方案的辩论，但双方都没有达成一致意见。

我们有一个产品，可以接收“消息”。每次我们接收一条新消息时，需要将这些数据发送到3个用于处理的服务中。

第1个服务需要数据采用特定格式。为此，我们将数据放入 SQS 中，该服务从其中读取数据。

服务 #2 读取消息字段：[a、b、c]，我们以 protobuf 格式发送。

服务 #3 读取消息字段：[a、b、c、d、e]，也是 protobuf 格式。

对于服务 #2 和 #3，我们将数据分别发送到 2 个独立的 SQS 队列中。

然而，我们可以将数据发送到 SNS 主题，队列 #2 和 #3 会从中读取数据。为此，我们将服务 #3 的 protobuf 发送，因为它包含了服务 #2 所需的所有字段。

编写服务 #2 的人不希望这样做，因为他不想获取多余的数据，这些数据只会被忽略掉。

编写服务 #3 的人认为，与其将数据以 protobuf 格式发送到 2 个独立的 SQS 队列中，不如将数据发送到一个 SNS 主题中，让服务 #2 直接读取 protobuf #3，并忽略掉不需要的字段，这样更节省资源。

从架构角度来看，谁是正确的？

- Steffan Perry

---

你最终决定做什么了？ - committedandroider

Answer 1

当您想要“通知”其他服务发生事件时，请使用SNS - 特别是如果有多个可能对该事件感兴趣的服务。

整个基于格式的区分似乎是一种人工构造，使得使用SQS成为必需。 SQS最适合点对点通信。

从一个服务发布到2-3个位置会使您的服务面临原子性和可靠性问题（如果在发布到SQS后但在发布到SNS之前发布服务崩溃会发生什么？）。 有一个单一的系统来放置消息，这些问题就更容易解决了。

最终，这取决于您的系统需要什么。 如果由我决定，我会更改所有下游服务，以便通过SNS获取通知（对于所有这些服务采用一致的格式）。

- rdas

---

我会更改所有下游服务，以通过SNS获取通知（并为它们所有人使用一致的格式）。我也在考虑这个。这种方法的缺点是所有三个服务都必须进行自己的转换，对吧？ - committedandroider

Answer 2

你们正在进行的辩论是关于观点的。两种方法都有权衡之处。最终，你应该努力追求长期更好的方案（比如从现在起一年后）。

当SNS-SQS已经具备高可用性并且可以将消息发布到多个SQS队列时，将消息发布到多个SQS队列并没有太大意义。我建议只使用单个发布者（因为最终数据集相同），并在消费者端使用相同的契约。

让消费者决定他们想要对数据做什么（丢弃事件；丢弃字段）。如果消费者真的不想要额外的字段，可以实现一个额外的反腐层（这个ACL将在消费者域内）。

发布者应该以最通用的形式发布数据，以确保发布者应用程序不跨越其域。

以牺牲服务耦合度为代价来优化资源将是一种非常糟糕的方法。

- Ashwani Agarwal

---

你能详细说明一下你刚才说的最后一句话吗 - “以优化资源为代价来耦合服务将是一个非常糟糕的方法。” 我无法理解问题中的例子以及它如何优化资源。另一个回答者rdas的答案在资源方面似乎也是最优的 - SNS，每个服务都订阅消息的部分，因为每个服务都需要这些部分。 - committedandroider