因此，我们决定在向微服务架构的迁移中使用 RabbitMQ 作为消息/事件总线，但我们无法找到放置队列的最佳方式的明确答案，我们有两个选择：
One main exchange which will be a Fanout exchange, which in turn will fan messages out to a main queue for logging and other purposes and another sub exchange which will be a topic exchange and route the messages to each desired queue using the message routing key. We expect the number of queues behind the sub-exchange to be some how a large number. This can be explained by this graph:
One main exchange, which will be a Topic exchange, with still one main queue bound to that exchange using "#" routing key. That main exchange will also handles main routing to other sub exchanges, so routing keys might be "agreements.#", "assignments.#", "messages.#", which are then used to bind multiple topic sub-exchanges, each will handle sub routing, so one sub exchange might be handling all "assignments" and queues bound to that exchange could be bound by routing keys like "assignments.accepted", "assignments.deleted"...In this scenario, we feel like the huge number of queues will be less per exchange, they will be somehow distributed between exchanges.
So, which of these scenarios could be the best approach? Faster on RabbitMQ, less overhead.
请记住，所有队列、交换和绑定都将从发布或订阅的服务中即时完成。
您可以在本主题中找到一些解释：RabbitMQ 主题交换：1 个交换与多个交换 https://stackoverflow.com/questions/11248510/rabbitmq-topic-exchanges-1-exchange-vs-many-exchanges
我使用 RabbitMQ 的方式与您在案例 2 中展示的方式非常相似，因为我发现了与本文中描述的相同的好处：https://skillachie.com/2014/06/27/rabbitmq-exchange-to-exchange-bindings-ampq/ https://skillachie.com/2014/06/27/rabbitmq-exchange-to-exchange-bindings-ampq/
交换到交换的绑定在您可以设计的拓扑方面更加灵活，促进解耦并减少绑定流失
据说交换到交换的绑定非常轻量，因此有助于提高性能*
根据我自己在交换到交换方面的经验，案例 2 很棒，它允许以非常快的方式创建/更改消息流拓扑。
