随着公司业务量的增加，原本部署在Windows服务器的RabbitMQ集群(3.6.1)总是出现莫名其妙的问题,经查询官方Issue，确认是RabbitMQ 3.6.1 版本的bug。查看从3.6.1 版本至 3.7.9 版本的变更日志，可以发现RabbitMQ官方修复了不少bug，本着版本越新 bug相对越少且 新版本修复了当前我们经常遇到的版本bug，因此我们决定将其中一个MQ集群(Windows)升级至3.7.9(Centos),毕竟开源软件对于Linux的支持是更好的。
公司的业务不可能会因为要升级MQ集群而暂停，因此采取哪种形式进行迁移是我们要重点考虑的，
- Full Stop升级
需要将整个MQ集群停止，然后整体升级，PASS。 - 滚动升级
滚动升级对MQ的版本有要求，从3.6.1 升级至 3.7.9 不满足官方介绍的版本要求，PASS。 - blue-green升级
blue-green升级也成为蓝绿升级，升级过程不需要停止原有MQ集群，升级过程安全可控，但需要额外搭建一个新的集群。鉴于我们要将Windows部署的3.6.1 版本的MQ集群升级至Centos部署的3.7.9 版本，必须新搭建集群，因此采用该方案。
Blue-Green蓝绿部署是一个升级策略，它是基于在当前集群(blue)旁边创建第二个集群（green）的想法。当迁移结束后，应用程序会切换到”green”集群，”blue”集群会关闭，为了简化切换，可以使用 federated queues把已排队的消息从“blue”传递高”green”集群。
具体的搭建步骤：
1.准备Green集群(3.7.9)
1.1 搭建3.7.9 版本的MQ集群 。具体可参考centos安装RabbitMQ 3.7.9 (使用RPM) 及 Centos 7安装RabbitMQ 3.7.8版本(单机版)-不使用RPM。
1.2 Green 集群创建完毕后导入定义:exchange、queue、bindings。
从Blue 集群导出exchange、queue、bindings 的 元数据定义，导入到新搭建的Green集群
1.3 配置Federation Queue
Federation 作为RabbitMQ的一个插件而存在，本质上是连接green集群的消费者，会获取发布到blue集群的消息。 具体可参考官方文档：Upgrading RabbitMQ Using Blue-Green Deployment Strategy
将Blue 集群设置为上游，将Green设置为下游。实现发送至Blue集群的消息可以被Green集群的消费者消费。 用武林小说中的招式就是 乾坤大挪移。
2. 切换消费者连接到Green集群
2.1 修改客户端连接MQ集群地址，将消费者连接MQ集群地址从Blue切换至Green
切换客户端MQ连接之后，消费者会连接至Green集群。但生产者仍旧会发送消息至Blue集群
3.耗尽积压的消息
3.1 在切换生产者连接至Green集群之前，先耗尽Blue集群中积压的消息。避免出现消息丢失，出现不可逆转的错误。
4.切换生产者连接到Green集群
4.1 修改生产者程序MQ连接，将消息发送至Green集群。
5.将Blue集群下线
遇到的挑战：
1.由于生产者未将连接从Blue切换至Green集群之前，我们希望耗尽积压的所有消息。但由于公司业务不会停止，因此发送端会持续的进行消息推送，就永远不会出现队列消息为空的情况。如果强行切换生产者，那么可能会造成消息丢失。
解决办法：Blue集群的消费者暂时保留，生产者从Blue切换至Green后，保留的消费者会继续消费Blue集群的消息，直至消费完毕。然后就可以下线Blue集群。
2.监控插件通过3.6.1 版本RabbitMQ API进行数据读取及上报，在3.7.9 中，部分API进行了调整，因此对应的监控插件也需要对应调整。
3.此次操作是将部署在Windows的3.6.1 版本RabbitMQ 升级至 Centos 3.7.9 ，其中涉及的操作命令及部署方式均存在变化，需提前了解。
4.出现故障时，基本的Centos操作命令，需要了解。
附简单的升级思路：
