我们正在使用微服务架构在nodejs中实现Web-API。每个服务都会公开HTTP端点，以便应用程序/网站可以与其互动。为了同步不同的数据库，我们目前正在使用RabbitMQ。微服务可以在fanout交换器上发布消息，每个订阅的微服务都会接收到该消息。
这种架构存在两个问题：
1. 如果我们想添加一个微服务的第二个实例（例如负载均衡），那么如果第二个服务订阅相同的fanout交换，则消息将被消费两次。 2. 无论是确认在fanout交换中不起作用还是我做错了什么，当我在没有订阅者的fanout交换上发布消息时，消息会立即消失而未被确认。
这导致我的问题。RabbitMQ是否是微服务同步的好选择，或者我们应该改变我们的架构。以下是我希望它能够工作的简短示例：
1. 用户创建新账户。 2. auth-mc将用户插入其数据库并发布'user.created'事件。 3. a1-mc、a2-mc（相同的mc，只是负载均衡）和b1-mc都是交换的订阅者。a1或a2以及b1都会接收事件并将用户插入各自的数据库中。 4. 只有在确认后，事件才会从每个微服务的队列中删除。
这样，我可以确保每个微服务（负载均衡或非负载均衡）都会收到消息一次。是否可以使用RabbitMQ实现这样的模式？
编辑：如果有任何建议，也希望了解有关微服务的良好文献。
这种架构存在两个问题：
1. 如果我们想添加一个微服务的第二个实例（例如负载均衡），那么如果第二个服务订阅相同的fanout交换，则消息将被消费两次。 2. 无论是确认在fanout交换中不起作用还是我做错了什么，当我在没有订阅者的fanout交换上发布消息时，消息会立即消失而未被确认。
这导致我的问题。RabbitMQ是否是微服务同步的好选择，或者我们应该改变我们的架构。以下是我希望它能够工作的简短示例：
1. 用户创建新账户。 2. auth-mc将用户插入其数据库并发布'user.created'事件。 3. a1-mc、a2-mc（相同的mc，只是负载均衡）和b1-mc都是交换的订阅者。a1或a2以及b1都会接收事件并将用户插入各自的数据库中。 4. 只有在确认后，事件才会从每个微服务的队列中删除。
这样，我可以确保每个微服务（负载均衡或非负载均衡）都会收到消息一次。是否可以使用RabbitMQ实现这样的模式？
编辑：如果有任何建议，也希望了解有关微服务的良好文献。