RabbitMQ 3.6.1 升級至 3.7.9 版本(Windows 升級至Centos)

    隨着公司業務量的增長，本來部署在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操做命令，須要瞭解。

附簡單的升級思路：