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