AWS上微服务之间的消息传递

Question

下面是一个场景：

我们正在使用API和EC2实例在AWS上运行一个微服务风格的体系结构。假设有五种服务:照片服务、主题服务、用户发布服务、用户消息服务和用户配置文件服务。还有一个SQS消费者服务，“消息工作者”。每个微型服务都有自己的数据库。以下是用户向用户Posts服务(例如)发出请求时发生的一系列事件：

API网关将请求路由到用户Posts服务。用户Posts更新其数据库中的必要项。用户Posts服务将消息发布到消息工作者(SQS)。消息工作者复制所需的多个服务的消息，即如果用户评论服务、用户配置文件服务和用户消息服务都需要更新，则重复消息3次。消息工作者通过HTTP将数据发送到每个服务，每个服务通过HTTP进行响应，指示他们已经收到消息或消息更新失败。这是处理微服务之间消息传递的有效方法吗？一个问题是，消息工作人员是一个单一的失败点，但还有什么可供选择的呢？我们正在考虑为每个微服务创建一个队列，并通过SNS将消息发布到队列中。还有其他的建议来提高效率吗？

由于遵从性，我们在可以使用哪些服务方面受到限制，因此不可能使用带有消息代理功能(如ZeroMQ / RabbitMQ )的“智能队列”。

Answer 1

“我们正在考虑为每个微服务创建一个队列，并通过SNS将消息发布到队列中。”

是的，这样您的队列就可以订阅通知，并且不再需要消息服务。本质上是它的扇出路线。您的微服务将成为队列工作人员。

然而，许多队列和通知可能变得复杂。SQS + SNS在某些方面有点笨重。我会倾向于将它的使用限制在肯定有长期运行异步任务的情况下。

如果您可以在一个ec2实例上安装4或5个微服务，因为它们都是小的、简单的、不受压力的操作，那么您只需将它们分开来考虑体系结构问题。如果需要的话，让他们互相打电话也许是值得的。

很容易将队列排到第n级，并通过sns消息进行数百万个nano服务的通信。这并不是说它不起作用，但您必须监视这些队列，并担心丢失和双发送的消息、全队列、错误队列等。