我有一个使用 Spring Integration + RabbitMQ 的项目。我们仍处于早期开发阶段，因此我们正在快速更改集成架构的拓扑结构，包括 RabbitMQ 配置。
我们还尝试通过免提部署来遵循持续部署。
我<rabbit:admin />在我的 spring 配置中声明了一个元素，它很好地处理了添加新的交换或队列。
但是，当我部署更改现有交换/队列配置的更新时，我发现它失败了。
最近，一些部署失败了，因为：
在这两种情况下，都需要对现有配置进行更改，而不仅仅是创建一个新实例。未应用这些更新，导致启动失败。
对于这两者，修复很简单——删除有问题的资源，重新启动应用程序，然后<rabbit:admin />用正确的定义替换它们。
但是，在生产系统中，我们不能这样做。此外，这目前还没有作为我们部署的一部分编写脚本，这使得持续部署更加麻烦。
哪些工具或策略可用于处理 RabbitMQ 拓扑更新的持续部署策略？
我听说这样做的一种方法是创建一个新的交换并将新的绑定添加到现有的队列中。在这种情况下，您可以将发布者转移到下一个交换，而消费者只需从同一个队列中消费。一旦每个人都移动过来，您就可以删除旧队列，可能需要重新创建并移回以前的名称。
对于队列更改，这会更加困难，因为如果您使用新设置创建一个新队列并绑定到相同的交换，您可能会收到重复的消息。如果这与新交换（与现有交换具有相同的配置）一起完成，那么您可以防止重复消息。
对于无法维持已删除队列的任何关键系统，我更倾向于创建一个新集群并将所有客户端移动到新的、正确配置的集群。您可以拆分现有集群并修复一个节点，擦除旧节点，然后将其加入新节点，而不是创建一个新集群。
我已经开始在 Chef 中管理交换/队列配置，这样这个过程会更容易一些，不需要注意发布者和消费者连接到新节点的顺序。
这些是我见过/听说过的最好的。在这方面，向后不兼容的 AMQP 更改类似于 DB 迁移。添加兼容的更改很容易自动化，但不兼容的更改需要小心。
即将发布的 1.2 版本（目前处于里程碑 1 - 1.2.0.M1）现在有一个选项来RabbitAdmin记录配置问题（而不是无法初始化）ignore-declaration-exceptions。
它不会更改现有配置，但它允许应用程序在记录警告时进行初始化。