隨着公司業務量的增加，原本部署在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操作命令，需要了解。
附簡單的升級思路：
