什么是面向服务/微服务体系结构的好的事件存储/流中间件

Question

我正在构建一个微服务架构，我正在寻找一种很好的方式来流式传输事件。

目前，我有一个发布事件的服务，其他三个服务需要以某种方式对此事件做出反应，但是对此事件的反应应该只发生一次。

目前，我正在使用RabbitMQ，我的服务在单独的队列中发布三条消息，每个订阅服务监听一个队列。因此，只有一个服务实例可以实际接收消息并对其做出反应。

但是，我不喜欢这种方法，因为如果我想添加一个新的订阅者，我必须为发布服务添加一个新的队列。

我基本上是在寻找事件流上的某种中间件，它允许多个服务侦听一个事件，但确保每个服务只有一个实例实际对事件做出反应。

我还没有找到任何东西，所以我希望得到一些建议。

Answer 1

你可以看看this page，它解释了AMQP模型是如何工作的，从而解释了RabbitMQ。

您的邮件将发布到Exchange，而不是排队。交换将根据exchange类型以及绑定的关键字和路由关键字将消息路由到绑定的队列。

一般来说，发布者并不介意交换背后的路由。消费者关心的是根据他们想要消费什么以及如何消费来创建队列并将其绑定到交换。

因此，如果您的生产者使用例如direct exchange将其消息发布到ExchangeA，则服务A/B/C可以创建它们的队列并将其绑定到此交换，并且它们将接收每个发布的消息。如果产生了一个新的服务E，它也应该创建一个队列并将其绑定到此交换。因此，您不需要修改发布者。

Answer 2

我们的建议是使用带有RabbitMQ的发布/订阅模型，以便多个订阅者可以监听单个队列并采取相应的行动。请参阅：https://www.rabbitmq.com/tutorials/tutorial-three-python.html