今年雙十一大促中，消息中間件 RocketMQ 發(fā)生了以下幾個(gè)方面的變化：
- 云原生化實(shí)踐。完成運(yùn)維層面的云原生化改造，實(shí)現(xiàn) Kubernetes 化。
- 性能優(yōu)化。消息過濾優(yōu)化交易集群性能提升 30%。
- 全新的消費(fèi)模型。對于延遲敏感業(yè)務(wù)提供新的消費(fèi)模式，降低因發(fā)布、重啟等場景下導(dǎo)致的消費(fèi)延遲。
云原生化實(shí)踐
背景
Kubernetes 作為目前云原生化技術(shù)棧實(shí)踐中重要的一環(huán)，其生態(tài)已經(jīng)逐步建立并日益豐富。目前，服務(wù)于集團(tuán)內(nèi)部的 RocketMQ 集群擁有巨大的規(guī)模以及各種歷史因素，因此在運(yùn)維方面存在相當(dāng)一部分痛點(diǎn)，我們希望能夠通過云原生技術(shù)棧來嘗試找到對應(yīng)解決方案，并同時(shí)實(shí)現(xiàn)降本提效，達(dá)到無人值守的自動化運(yùn)維。
消息中間件早在 2016 年，通過內(nèi)部團(tuán)隊(duì)提供的中間件部署平臺實(shí)現(xiàn)了容器化和自動化發(fā)布，整體的運(yùn)維比 2016 年前已經(jīng)有了很大的提高，但是作為一個(gè)有狀態(tài)的服務(wù)，在運(yùn)維層面仍然存在較多的問題。
中間件部署平臺幫我們完成了資源的申請，容器的創(chuàng)建、初始化、鏡像安裝等一系列的基礎(chǔ)工作，但是因?yàn)橹虚g件各個(gè)產(chǎn)品都有自己不同的部署邏輯，所以在應(yīng)用的發(fā)布上，就是各應(yīng)用自己的定制化了。中間件部署平臺的開發(fā)也不完全了解集團(tuán)內(nèi) RocketMQ 的部署過程是怎樣的。
因此在 2016 年的時(shí)候，部署平臺需要我們?nèi)ビH自實(shí)現(xiàn)消息中間件的應(yīng)用發(fā)布代碼。雖然部署平臺大大提升了我們的運(yùn)維效率，甚至還能實(shí)現(xiàn)一鍵發(fā)布，但是這樣的方案也有不少的問題。比較明顯的就是，當(dāng)我們的發(fā)布邏輯有變化的時(shí)候，還需要去修改部署平臺對應(yīng)的代碼，需要部署平臺升級來支持我們，用最近比較流行的一個(gè)說法，就是相當(dāng)不云原生。
同樣在故障機(jī)替換、集群縮容等操作中，存在部分人工參與的工作，如切流，堆積數(shù)據(jù)的確認(rèn)等。我們嘗試過在部署平臺中集成更多消息中間件自己的運(yùn)維邏輯，不過在其他團(tuán)隊(duì)的工程里寫自己的業(yè)務(wù)代碼，確實(shí)也是一個(gè)不太友好的實(shí)現(xiàn)方案，因此我們希望通過 Kubernetes 來實(shí)現(xiàn)消息中間件自己的 operator 。我們同樣希望利用云化后云盤的多副本能力來降低我們的機(jī)器成本并降低主備運(yùn)維的復(fù)雜程度。
經(jīng)過一段時(shí)間的跟進(jìn)與探討，最終再次由內(nèi)部團(tuán)隊(duì)承擔(dān)了建設(shè)云原生應(yīng)用運(yùn)維平臺的任務(wù)，并依托于中間件部署平臺的經(jīng)驗(yàn)，借助云原生技術(shù)棧，實(shí)現(xiàn)對有狀態(tài)應(yīng)用自動化運(yùn)維的突破。
實(shí)現(xiàn)
整體的實(shí)現(xiàn)方案如上圖所示，通過自定義的 CRD 對消息中間件的業(yè)務(wù)模型進(jìn)行抽象，將原有的在中間件部署平臺的業(yè)務(wù)發(fā)布部署邏輯下沉到消息中間件自己的 operator 中，托管在內(nèi)部 Kubernetes 平臺上。該平臺負(fù)責(zé)所有的容器生產(chǎn)、初始化以及集團(tuán)內(nèi)一切線上環(huán)境的基線部署，屏蔽掉 IaaS 層的所有細(xì)節(jié)。
Operator 承擔(dān)了所有的新建集群、擴(kuò)容、縮容、遷移的全部邏輯，包括每個(gè) pod 對應(yīng)的 brokerName 自動生成、配置文件，根據(jù)集群不同功能而配置的各種開關(guān)，元數(shù)據(jù)的同步復(fù)制等等。同時(shí)之前一些人工的相關(guān)操作，比如切流時(shí)候的流量觀察，下線前的堆積數(shù)據(jù)觀察等也全部集成到了 operator 中。當(dāng)我們有需求重新修改各種運(yùn)維邏輯的時(shí)候，也再也不用去依賴通用的具體實(shí)現(xiàn)，修改自己的 operator 即可。
最后線上的實(shí)際部署情況去掉了圖中的所有的 replica 備機(jī)。在 Kubernetes 的理念中，一個(gè)集群中每個(gè)實(shí)例的狀態(tài)是一致的，沒有依賴關(guān)系，而如果按照消息中間件原有的主備成對部署的方案，主備之間是有嚴(yán)格的對應(yīng)關(guān)系，并且在上下線發(fā)布過程中有嚴(yán)格的順序要求，這種部署模式在 Kubernetes 的體系下是并不提倡的。若依然采用以上老的架構(gòu)方式，會導(dǎo)致實(shí)例控制的復(fù)雜性和不可控性，同時(shí)我們也希望能更多的遵循 Kubernetes 的運(yùn)維理念。
云化后的 ECS 使用的是高速云盤，底層將對數(shù)據(jù)做了多備份，因此數(shù)據(jù)的可用性得到了保障。并且高速云盤在性能上完全滿足 MQ 同步刷盤，因此，此時(shí)就可以把之前的異步刷盤改為同步，保證消息寫入時(shí)的不丟失問題。云原生模式下，所有的實(shí)例環(huán)境均是一致性的，依托容器技術(shù)和 Kubernetes 的技術(shù)，可實(shí)現(xiàn)任何實(shí)例掛掉（包含宕機(jī)引起的掛掉），都能自動自愈，快速恢復(fù)。
解決了數(shù)據(jù)的可靠性和服務(wù)的可用性后，整個(gè)云原生化后的架構(gòu)可以變得更加簡單，只有 broker 的概念，再無主備之分。
大促驗(yàn)證
上圖是 Kubernetes 上線后雙十一大促當(dāng)天的發(fā)送 RT 統(tǒng)計(jì)，可見大促期間的發(fā)送 RT 較為平穩(wěn)，整體符合預(yù)期，云原生化實(shí)踐完成了關(guān)鍵性的里程碑。
性能優(yōu)化
背景
RocketMQ 至今已經(jīng)連續(xù)七年 0 故障支持集團(tuán)的雙十一大促。自從 RocketMQ 誕生以來，為了能夠完全承載包括集團(tuán)業(yè)務(wù)中臺交易消息等核心鏈路在內(nèi)的各類關(guān)鍵業(yè)務(wù)，復(fù)用了原有的上層協(xié)議邏輯，使得各類業(yè)務(wù)方完全無感知的切換到 RocketMQ 上，并同時(shí)充分享受了更為穩(wěn)定和強(qiáng)大的 RocketMQ 消息中間件的各類特性。
當(dāng)前，申請訂閱業(yè)務(wù)中臺的核心交易消息的業(yè)務(wù)方一直都在不斷持續(xù)增加，并且隨著各類業(yè)務(wù)復(fù)雜度提升，業(yè)務(wù)方的消息訂閱配置也變得更加復(fù)雜繁瑣，從而使得交易集群的進(jìn)行過濾的計(jì)算邏輯也變得更為復(fù)雜。這些業(yè)務(wù)方部分沿用舊的協(xié)議邏輯（Header過濾），部分使用 RocketMQ 特有的 SQL 過濾。
主要成本
目前集團(tuán)內(nèi)部 RocketMQ 的大促機(jī)器成本絕大部分都是交易消息相關(guān)的集群，在雙十一零點(diǎn)峰值期間，交易集群的峰值和交易峰值成正比，疊加每年新增的復(fù)雜訂閱帶來了額外 CPU 過濾計(jì)算邏輯，交易集群都是大促中機(jī)器成本增長最大的地方。
優(yōu)化過程
由于歷史原因，大部分的業(yè)務(wù)方主要還是使用Header過濾，內(nèi)部實(shí)現(xiàn)其實(shí)是aviator表達(dá)式（ https://github.com/killme2008/aviatorscript ）。仔細(xì)觀察交易消息集群的業(yè)務(wù)方過濾表達(dá)式，可以發(fā)現(xiàn)絕大部分都指定類似 MessageType == xxxx 這樣的條件。翻看aviator的源碼可以發(fā)現(xiàn)這樣的條件最終會調(diào)用JAVA的字符串比較 String.compareTo()。
由于交易消息包括大量不同業(yè)務(wù)的MessageType，光是有記錄的起碼有幾千個(gè)，隨著交易業(yè)務(wù)流程復(fù)雜化，MessageType的增長更是繁多。隨著交易峰值的提高，交易消息峰值正比增長，疊加這部分更加復(fù)雜的過濾，持續(xù)增長的將來，交易集群的成本極可能和交易峰值指數(shù)增長，因此決心對這部分進(jìn)行優(yōu)化。
原有的過濾流程如下，每個(gè)交易消息需要逐個(gè)匹配不同group的訂閱關(guān)系表達(dá)式，如果符合表達(dá)式，則選取對應(yīng)的group的機(jī)器進(jìn)行投遞。如下圖所示：
對此流程進(jìn)行優(yōu)化的思路需要一定的靈感，在這里借助數(shù)據(jù)庫索引的思路：原有流程可以把所有訂閱方的過濾表達(dá)式看作數(shù)據(jù)庫的記錄，每次消息過濾就相當(dāng)于一個(gè)帶有特定條件的數(shù)據(jù)庫查詢，把所有匹配查詢（消息）的記錄（過濾表達(dá)式）選取出來作為結(jié)果。為了加快查詢結(jié)果，可以選擇 MessageType 作為一個(gè)索引字段進(jìn)行索引化，每次查詢變?yōu)橄绕ヅ?MessageType 主索引，然后把匹配上主索引的記錄再進(jìn)行其它條件(如下圖的 sellerId 和 testA )匹配，優(yōu)化流程如下圖所示：
以上優(yōu)化流程確定后，要關(guān)注的技術(shù)點(diǎn)有兩個(gè)：
- 如何抽取每個(gè)表達(dá)式中的 MessageType 字段？
- 如何對 MessageType 字段進(jìn)行索引化？
對于技術(shù)點(diǎn) 1 ，需要針對 aviator 的編譯流程進(jìn)行 hook ，深入 aviator 源碼后，可以發(fā)現(xiàn) aviator 的編譯是典型的 Recursive descent ：
http://en.wikipedia.org/wiki/Recursive_descent_parser
同時(shí)需要考慮到提取后父表達(dá)式的短路問題。
在編譯過程中針對 messageType==XXX 這種類型進(jìn)行提取后，把原有的 message==XXX 轉(zhuǎn)變?yōu)?true/false 兩種情況，然后針對 true、false 進(jìn)行表達(dá)式的短路即可得出表達(dá)式優(yōu)化提取后的情況。例如：
表達(dá)式：
messageType=='200-trade-paid-done' && buyerId==123456
提取為兩個(gè)子表達(dá)式：
子表達(dá)式1（messageType==200-trade-paid-done）：buyerId==123456
子表達(dá)式2（messageType!=200-trade-paid-done）：false
具體到 aviator 的實(shí)現(xiàn)里，表達(dá)式編譯會把每個(gè) token 構(gòu)建一個(gè) List ，類似如下圖所示(為方便理解，綠色方框的是 token ，其它框表示表達(dá)式的具體條件組合)：
提取了 messageType ，有兩種情況：
- 情況一：messageType == '200-trade-paid-done'，則把之前 token 的位置合并成true，然后進(jìn)行表達(dá)式短路計(jì)算，最后優(yōu)化成 buyerId==123456 ，具體如下：
- 情況二：messageType != '200-trade-paid-done'，則把之前 token 的位置合并成 false ，表達(dá)式短路計(jì)算后，最后優(yōu)化成 false ，具體如下：
ashMap 的 key ，把提取后的子表達(dá)式作為 HashMap 的 value ，這樣每次過濾直接通過一次 hash 計(jì)算即可過濾掉絕大部分不適合的表達(dá)式，大大提高了過濾效率。
優(yōu)化效果
該優(yōu)化最主要降低了 CPU 計(jì)算邏輯，根據(jù)優(yōu)化前后的性能情況對比，我們發(fā)現(xiàn)不同的交易集群中的訂閱方訂閱表達(dá)式復(fù)雜度越高，優(yōu)化效果越好，這個(gè)是符合我們的預(yù)期的，其中最大的 CPU 優(yōu)化有 32% 的提升，大大降低了本年度 RocketMQ 的部署機(jī)器成本。
全新的消費(fèi)模型 —— POP 消費(fèi)
背景
RocketMQ的PULL消費(fèi)對于機(jī)器異常hang時(shí)并不十分友好。如果遇到客戶端機(jī)器hang住，但處于半死不活的狀態(tài)，與broker的心跳沒有斷掉的時(shí)候，客戶端rebalance依然會分配消費(fèi)隊(duì)列到hang機(jī)器上，并且hang機(jī)器消費(fèi)速度很慢甚至無法消費(fèi)的時(shí)候，這樣會導(dǎo)致消費(fèi)堆積。另外類似還有服務(wù)端Broker發(fā)布時(shí)，也會由于客戶端多次rebalance導(dǎo)致消費(fèi)延遲影響等無法避免的問題。如下圖所示：
當(dāng)Pull Client 2發(fā)生hang機(jī)器的時(shí)候，它所分配到的三個(gè)Broker上的Q2都出現(xiàn)嚴(yán)重的紅色堆積。對于此，我們增加了一種新的消費(fèi)模型——POP消費(fèi)，能夠解決此類穩(wěn)定性問題。如下圖所示：
POP消費(fèi)中，三個(gè)客戶端并不需要rebalance去分配消費(fèi)隊(duì)列，取而代之的是，它們都會使用POP請求所有的broker獲取消息進(jìn)行消費(fèi)。broker內(nèi)部會把自身的三個(gè)隊(duì)列的消息根據(jù)一定的算法分配給請求的POP Client。即使Pop Client 2出現(xiàn)hang，但內(nèi)部隊(duì)列的消息也會讓Pop Client1 和Pop Client2進(jìn)行消費(fèi)。這樣就hang機(jī)器造成的避免了消費(fèi)堆積。
實(shí)現(xiàn)
POP 消費(fèi)和原來 PULL 消費(fèi)對比，最大的一點(diǎn)就是弱化了隊(duì)列這個(gè)概念，PULL 消費(fèi)需要客戶端通過 rebalance 把 broker 的隊(duì)列分配好，從而去消費(fèi)分配到自己專屬的隊(duì)列，新的 POP 消費(fèi)中，客戶端的機(jī)器會直接到每個(gè) broker 的隊(duì)列進(jìn)行請求消費(fèi)， broker 會把消息分配返回給等待的機(jī)器。隨后客戶端消費(fèi)結(jié)束后返回對應(yīng)的 Ack 結(jié)果通知 broker，broker 再標(biāo)記消息消費(fèi)結(jié)果，如果超時(shí)沒響應(yīng)或者消費(fèi)失敗，再會進(jìn)行重試。
POP 消費(fèi)的架構(gòu)圖如上圖所示。Broker 對于每次 POP 的請求，都會有以下三個(gè)操作：
- 對應(yīng)的隊(duì)列進(jìn)行加鎖，然后從 store 層獲取該隊(duì)列的消息；
- 然后寫入 CK 消息，表明獲取的消息要被 POP 消費(fèi)；
- 最后提交當(dāng)前位點(diǎn)，并釋放鎖。
CK 消息實(shí)際上是記錄了 POP 消息具體位點(diǎn)的定時(shí)消息，當(dāng)客戶端超時(shí)沒響應(yīng)的時(shí)候，CK 消息就會重新被 broker 消費(fèi)，然后把 CK 消息的位點(diǎn)的消息寫入重試隊(duì)列。如果 broker 收到客戶端的消費(fèi)結(jié)果的 Ack ，刪除對應(yīng)的 CK 消息，然后根據(jù)具體結(jié)果判斷是否需要重試。
從整體流程可見，POP 消費(fèi)并不需要 reblance ，可以避免 rebalance 帶來的消費(fèi)延時(shí)，同時(shí)客戶端可以消費(fèi) broker 的所有隊(duì)列，這樣就可以避免機(jī)器 hang 而導(dǎo)致堆積的問題。
查看RocketMQ更多詳情：https://www.aliyun.com/product/rocketmq?spm=5176.19720258.J_8058803260.342.44882c4aHmUC1H
