隨著公司業務量的增加，原本部署在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叢集而暫停，因此採取哪種形式進行遷移是我們要重點考慮的，

1. Full Stop升級
   需要將整個MQ叢集停止，然後整體升級，PASS。
2. 滾動升級
   滾動升級對MQ的版本有要求，從3.6.1 升級至 3.7.9 不滿足官方介紹的版本要求，PASS。
3. 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操作命令，需要了解。

附簡單的升級思路：