多个SQS队列与1个SNS主题

Question

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

我们有一种可以摄取“信息”的产品。每次收到新消息时，我们都需要将此数据发送到3个服务进行处理。

服务#1要求数据采用特殊格式。为此，我们将数据放在SQS中，服务从中读取数据。

服务#2读取消息字段: a、b、c，然后以协议格式发送。

服务#3读取消息字段: a、b、c、d、e，也可以读取协议。

对于服务#2和#3，我们将数据发送到两个独立的SQS队列中。但是，我们可以在队列#2和#3读取的SNS主题中发送数据。为此，我们将发送服务#3的协议has，因为它具有服务#2所需的所有字段。

编写服务#2的人不想这样做，因为他不想获得额外的数据，而这些数据将被忽略。

编写服务#3的人认为，当服务#2可以简单地读取protobuf #3并忽略不需要的字段时，系统将protobuf发送到2个单独的SQS队列而不是1个SNS主题，这是浪费资源。

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

Answer 1

当您想要“通知”其他服务某个事件时，请使用SNS -尤其是当有多个服务可能对该事件感兴趣时。

整个基于格式的区分看起来就像是一个人为的构造，使得使用SQS成为必要。SQS是点对点通信的最佳选择。

从一个服务发布到2-3个位置会使您的服务面临原子性和可靠性问题(发布到SQS之后，但在发布到SNS之前，发布服务会崩溃吗？)。拥有一个放置消息的单一系统可以使这些问题更容易解决。

最后，它归结为您的系统需要什么。如果由我决定，我会更改所有的下游服务，以便通过SNS获得通知(所有服务的格式都是一致的)。

Answer 2

你正在进行的辩论是自以为是的观点。这两种方法都需要权衡。最后，你应该为长期(比如一年后)变得更好而努力。

发布到多个SQS队列并不是真正有意义的，因为SNS-SQS只是为了实现高可用性。我建议在消费者端使用单一的发布者(最终数据集是相同的)和相同的合同。

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

发布者应该以从他们的角度来看最通用的格式来发布数据。这也确保了发布者应用程序不会跨越它们的域。

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