一、背景說明

vivo 在 2016 年引入 RabbitMQ，基于開源 RabbitMQ 進(jìn)行擴展，向業(yè)務(wù)提供消息中間件服務(wù)。

2016~2018年，所有業(yè)務(wù)均使用一個集群，隨著業(yè)務(wù)規(guī)模的增長，集群負(fù)載越來越重，集群故障頻發(fā)。

2019年，RabbitMQ 進(jìn)入高可用建設(shè)階段，完成了高可用組件 MQ 名字服務(wù)以及 RabbitMQ 集群的同城雙活建設(shè)。

同時進(jìn)行業(yè)務(wù)使用集群的物理拆分，嚴(yán)格按照集群負(fù)載情況和業(yè)務(wù)流量進(jìn)行業(yè)務(wù)使用集群的分配以及動態(tài)調(diào)整。

在 2019 年高可用建設(shè)后至今，業(yè)務(wù)流量增加了十倍，集群未出現(xiàn)過嚴(yán)重故障。

RabbitMQ 是實現(xiàn)了 AMQP 協(xié)議的開源消息代理軟件，起源于金融系統(tǒng)。

具有豐富的特性：

•  消息可靠性保證，RabbitMQ 通過發(fā)送確認(rèn)保證消息發(fā)送可靠、通過集群化、消息持久化、鏡像隊列的方式保證消息在集群的可靠、通過消費確認(rèn)保證消息消費的可靠性；
•  RabbitMQ 提供了多種語言的客戶端；
•  提供了多種類型的 exchange，消息發(fā)送到集群后通過exchange路由到具體的queue中；
•  RabbitMQ 提供了完善的管理后臺和管理 API，通過管理API可以快速與自建監(jiān)控系統(tǒng)整合。

RabbitMQ 在具體實踐中發(fā)現(xiàn)的問題：

•  為保障業(yè)務(wù)高可用使用多套集群進(jìn)行物理隔離，多套集群無統(tǒng)一平臺進(jìn)行管理；
•  原生RabbitMQ客戶端使用集群地址連接，使用多套集群時業(yè)務(wù)需要關(guān)心集群地址，使用混亂；
•  原生RabbitMQ僅有簡單的用戶名/密碼驗證，不對使用的業(yè)務(wù)應(yīng)用方進(jìn)行鑒權(quán)，不同業(yè)務(wù)容易混用exchange/queue信息，造成業(yè)務(wù)應(yīng)用使用異常；
•  使用的業(yè)務(wù)應(yīng)用方較多，無平臺維護(hù)消息發(fā)送方、消費方的關(guān)聯(lián)信息，多個版本迭代后無法確定對接方；
•  客戶端無限流，業(yè)務(wù)突發(fā)異常流量沖擊甚至擊垮集群；
•  客戶端無異常消息重發(fā)策略，需要使用方實現(xiàn)；
•  集群出現(xiàn)內(nèi)存溢出等造成集群阻塞時無法快速自動轉(zhuǎn)移到其它可用集群；
•  使用鏡像隊列，隊列的master節(jié)點會落在具體某個節(jié)點上，在集群隊列數(shù)較多時，容易出現(xiàn)節(jié)點負(fù)載不均衡的情況；
•  RabbitMQ無隊列自動平衡能力，在隊列較多時容易出現(xiàn)集群節(jié)點負(fù)載不均問題。

二、整體架構(gòu)

1、MQ-Portal--支持應(yīng)用使用申請

過往業(yè)務(wù)團隊適用RabbitMQ時，應(yīng)用申請的流量以及對接的應(yīng)用等信息都在線下表格記錄，較為零散，更新不及時，無法準(zhǔn)確了解業(yè)務(wù)當(dāng)前真實的使用情況，因此通過一個接入申請的流程可視化、平臺化建立應(yīng)用使用的元數(shù)據(jù)信息。

通過MQ-Portal的申請流程（如上圖），確定了消息發(fā)送應(yīng)用、消費應(yīng)用、使用exchange/queue、發(fā)送流量等信息使用申請?zhí)峤缓髮⑦M(jìn)入vivo內(nèi)部工單流程進(jìn)行審批。

工單流程審批通過后，通過工單的接口回調(diào)，分配應(yīng)用具體使用的集群，并在集群上創(chuàng)建exchange/queue已經(jīng)綁定關(guān)系。

由于采用多集群物理隔離的方式保證業(yè)務(wù)在正式環(huán)境的高可用，無法簡單通過一個exchange/queue的名稱定位到使用的集群。

每一個exchange/queue與集群之間通過唯一的一對rmq.topic.key與rmq.secret.key進(jìn)行關(guān)聯(lián)，這樣SDK啟動過程中即可定位到具體使用的集群。

rmq.topic.key與rmq.secret.key將在工單的回調(diào)接口中進(jìn)行分配。

2、客戶端SDK能力概述

客戶端SDK基于spring-message和spring-rabbit進(jìn)行封裝，并在此基礎(chǔ)上提供了應(yīng)用使用鑒權(quán)、集群尋址、客戶端限流、生產(chǎn)消費重置、阻塞轉(zhuǎn)移等能力。

1）應(yīng)用使用鑒權(quán)

開源RabbitMQ僅通過用戶名密碼的方式判斷是否允許連接集群，但是應(yīng)用是否允許使用exchange/queue是未進(jìn)行校驗的。

為了避免不同業(yè)務(wù)混用exchange/queue，需要對應(yīng)用進(jìn)行使用鑒權(quán)。

應(yīng)用鑒權(quán)由SDK和MQ-NameServer協(xié)同完成。

應(yīng)用啟動時首先會上報應(yīng)用配置的rmq.topic.key信息到MQ-NameServer，由MQ-NameServer判斷使用應(yīng)用與申請應(yīng)用是否一致，并且在SDK發(fā)送消息過程中還會進(jìn)行二次校驗。 

/**  
  * 發(fā)送前校驗，并且獲取真正的發(fā)送factory，這樣業(yè)務(wù)可以聲明多個，  
  * 但是用其中一個bean就可以發(fā)送所有的消息，并且不會導(dǎo)致任何異常  
  * @param exchange 校驗參數(shù)  
  * @return 發(fā)送工廠  
*/  
public AbstractMessageProducerFactory beforeSend(String exchange) { 
    if(closed || stopped){  
        //上下文已經(jīng)關(guān)閉拋出異常，阻止繼續(xù)發(fā)送，減少發(fā)送臨界狀態(tài)數(shù)據(jù)  
        throw new RmqRuntimeException(String.format("producer sending message to exchange %s has closed, can't send message", this.getExchange()));  
    }  
    if (exchange.equals(this.exchange)){  
        return this;  
    }  
    if (!VIVO_RMQ_AUTH.isAuth(exchange)){  
        throw new VivoRmqUnAuthException(String.format("發(fā)送topic校驗異常，請勿向無權(quán)限exchange %s 發(fā)送數(shù)據(jù)，發(fā)送失敗", exchange));  
    }  
    //獲取真正的發(fā)送的bean，避免發(fā)送錯誤  
    return PRODUCERS.get(exchange);  
} 

2）集群尋址

前文說過，應(yīng)用使用RabbitMQ嚴(yán)格按照集群的負(fù)載情況和業(yè)務(wù)流量進(jìn)行集群的分配，因此具體某個應(yīng)用使用的的不同的exchange/queue可能是分配在不同的集群上的。

為了提升業(yè)務(wù)的開發(fā)效率， 需要屏蔽多集群對業(yè)務(wù)的影響，因此按照應(yīng)用配置的rmq.topic.key信息進(jìn)行集群的自動尋址。

3）客戶端限流

原生SDK客戶端不進(jìn)行發(fā)送流量限流，在部分應(yīng)用存在異常持續(xù)向MQ發(fā)送消息時，可能會沖垮MQ集群。并且一個集群為多應(yīng)用共同使用，單一應(yīng)用造成集群影響將會影響使用異常集群的所有應(yīng)用。

因此需要在SDK中提供客戶端限流的能力，必要時可以限制應(yīng)用向集群發(fā)送消息，保障集群的穩(wěn)定。

4）生產(chǎn)消費重置

①隨著業(yè)務(wù)規(guī)模增長，集群負(fù)載持續(xù)增加，此時需要進(jìn)行集群的業(yè)務(wù)拆分。為了減少在拆分過程中避免業(yè)務(wù)重啟，需要有生產(chǎn)消費重置功能。

②集群出現(xiàn)異常，可能會造成消費者掉線，此時通過生產(chǎn)消費重置可以快速拉起業(yè)務(wù)消費。

為了實現(xiàn)生產(chǎn)消費重置，需要實現(xiàn)一下流程：

•  重置連接工廠連接參數(shù)；
•  重置連接；
•  建立新的連接；
•  重新啟動生產(chǎn)消費。 

CachingConnectionFactory connectionFactory = new CachingConnectionFactory();  
connectionFactory.setAddresses(address);  
connectionFactory.resetConnection();  
rabbitAdmin = new RabbitAdmin(connectionFactory);  
rabbitTemplate = new RabbitTemplate(connectionFactory); 

同時MQ-SDK中有異常消息重發(fā)策略，可以避免在生產(chǎn)重置過程中導(dǎo)致的消息發(fā)送異常。

5）阻塞轉(zhuǎn)移

RabbitMQ在內(nèi)存使用超過40%，或是磁盤使用超限制時會阻塞消息發(fā)送。

由于vivo中間件團隊已經(jīng)完成了RabbitMQ同城雙活的建設(shè)，因此在出現(xiàn)一個集群發(fā)送阻塞時可以通過生產(chǎn)消費重置到雙活集群完成阻塞的快速轉(zhuǎn)移。

6）多集群調(diào)度

隨著應(yīng)用的發(fā)展，單集群將無法滿足應(yīng)用的流量需求，并且集群隊列均為鏡像隊列，無法簡單的通過增加集群節(jié)點的方式實現(xiàn)業(yè)務(wù)支撐流量單集群的水平擴容。

因此需要SDK支持多集群調(diào)度能力，通過將流量分散到多個集群上滿足業(yè)務(wù)大流量需求。

3、MQ-NameServer--支持MQ-SDK實現(xiàn)故障快速切換

MQ-NameServer為無狀態(tài)服務(wù)，通過集群部署即可保障自身高可用，主要用于解決以下問題：

•  MQ-SDK啟動鑒權(quán)以及應(yīng)用使用集群定位；
•  處理MQ-SDK的定時指標(biāo)上報（消息發(fā)送數(shù)量、消息消費數(shù)量），并且返回當(dāng)前可用集群地址，確保SDK在集群異常時按照正確地址進(jìn)行重連；
•  控制MQ-SDK進(jìn)行生產(chǎn)消費重置。

4、MQ-Server高可用部署實踐

RabbitMQ 集群均采用同城雙活部署架構(gòu)，依靠MQ-SDK和MQ-NameServer提供的集群尋址、故障快速切換等能力保障集群的可用性。

1）集群腦裂問題處理

RabbitMQ官方提供了三種集群腦裂恢復(fù)策略。

①ignore

忽略腦裂問題不處理，在出現(xiàn)腦裂時需要進(jìn)行人為干預(yù)才可恢復(fù)。由于需要人為干預(yù)，可能會造成部分消息丟失，在網(wǎng)絡(luò)非?？煽康那闆r可以使用。

②pause_minority

節(jié)點在與超過半數(shù)集群節(jié)點失聯(lián)時將會自動暫停，直到檢測到與集群超半數(shù)節(jié)點的通信恢復(fù)。極端情況下集群內(nèi)所有節(jié)點均暫停，造成集群不可用。

③autoheal

少數(shù)派節(jié)點將自動重啟，此策略主要用于優(yōu)先保證服務(wù)的可用性，而不是數(shù)據(jù)的可靠性，因為重啟節(jié)點上的消息會丟失。

由于RabbitMQ集群均為同城雙活部署，即使單集群異常業(yè)務(wù)流量也可自動遷移到雙活機房集群，因此選擇使用了pause_minority策略避免腦裂問題。

2018年多次因網(wǎng)絡(luò)抖動造成集群腦裂，在修改集群腦裂恢復(fù)策略后，已未再出現(xiàn)腦裂問題。

2）集群高可用方案

RabbitMQ采用集群化部署，并且因為集群腦裂恢復(fù)策略采用pause_minority模式，每個集群要求至少3個節(jié)點。

推薦使用5或7節(jié)點部署高可用集群，并且控制集群隊列數(shù)量。

集群隊列均為鏡像隊列，確保消息存在備份，避免節(jié)點異常導(dǎo)致消息丟失。

exchange、queue、消息均設(shè)置為持久化，避免節(jié)點異常重啟消息丟失。

隊列均設(shè)置為lazy queues，減少節(jié)點內(nèi)存使用的波動。

3）同城雙活建設(shè)

雙機房部署等價集群，并且通過Federation插件將雙集群組成聯(lián)盟集群。

本機房應(yīng)用機器優(yōu)先連接本機房MQ集群，避免因?qū)＞€抖動造成應(yīng)用使用異常。

通過MQ-NameServer心跳獲取最新的可用集群信息，異常時重連到雙活集群中，實現(xiàn)應(yīng)用功能的快速恢復(fù)。

三、未來挑戰(zhàn)與展望

目前對RabbitMQ的使用增強主要在MQ-SDK和MQ-NameServer側(cè)，SDK實現(xiàn)較為復(fù)雜，后期希望可以構(gòu)建消息中間件的代理層，可以簡化SDK并且對業(yè)務(wù)流量做更加細(xì)致化的管理。