01
消息場(chǎng)景
Cloud Native
RocketMQ 5.0 是消息事件流一體的實(shí)時(shí)數(shù)據(jù)處理平臺(tái),是業(yè)務(wù)消息領(lǐng)域的事實(shí)標(biāo)準(zhǔn),很多互聯(lián)網(wǎng)公司在業(yè)務(wù)消息場(chǎng)景會(huì)使用 RocketMQ。
我們反復(fù)提到的“消息、業(yè)務(wù)消息”,指的是分布式應(yīng)用解耦,是 RocketMQ 的業(yè)務(wù)基本盤。通過本文,我們將深入了解 RocketMQ 5.0 在業(yè)務(wù)消息場(chǎng)景的優(yōu)勢(shì)能力,了解為什么 RocketMQ 能夠成為業(yè)務(wù)消息領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。
RocketMQ 在業(yè)務(wù)消息領(lǐng)域的經(jīng)典場(chǎng)景是應(yīng)用解耦,這也是 RocketMQ 誕生初期解決阿里電商分布式互聯(lián)網(wǎng)架構(gòu)的核心場(chǎng)景,主要承擔(dān)分布式應(yīng)用(微服務(wù))的異步集成,達(dá)到應(yīng)用解耦的效果。解耦是所有的軟件架構(gòu)最重要的追求。
分布式應(yīng)用(微服務(wù))采用同步 RPC 與異步消息的對(duì)比。比如在業(yè)務(wù)系統(tǒng)中,有三個(gè)上游應(yīng)用與 4 個(gè)下游應(yīng)用,采用同步 RPC 的方式,會(huì)有 3*4 的依賴復(fù)雜度;而采用異步消息的方式則可以化繁為簡(jiǎn),簡(jiǎn)化為 3+4 的依賴復(fù)雜度,從乘法簡(jiǎn)化為加法。
通過引入消息隊(duì)列實(shí)現(xiàn)應(yīng)用的異步集成可以獲得四大解耦優(yōu)勢(shì)。
代碼解耦 極大提升業(yè)務(wù)敏捷度。如果用同步調(diào)用的方式,每次擴(kuò)展業(yè)務(wù)邏輯都需要上游應(yīng)用顯式調(diào)用下游應(yīng)用接口,代碼直接耦合,上游應(yīng)用要做變更發(fā)布,業(yè)務(wù)迭代互相掣肘。而通過使用消息隊(duì)列擴(kuò)展新的業(yè)務(wù)邏輯,只需要增加下游應(yīng)用訂閱某個(gè) Topic,上下游應(yīng)用互相透明,業(yè)務(wù)可以保持靈活獨(dú)立快速迭代。
延遲解耦 如果使用同步調(diào)用的方式,隨著業(yè)務(wù)邏輯的增加,用戶操作的遠(yuǎn)程調(diào)用次數(shù)會(huì)越來越多,業(yè)務(wù)響應(yīng)越來越慢,性能衰減,業(yè)務(wù)發(fā)展不可持續(xù)。而使用消息隊(duì)列,無論增加多少業(yè)務(wù),上游應(yīng)用只需調(diào)用一次消息隊(duì)列的發(fā)送接口即可響應(yīng)線上用戶,延遲為常量,基本在 5ms 以內(nèi)。
可用性解耦 如果使用同步調(diào)用的方式,任何下游業(yè)務(wù)不可用都會(huì)導(dǎo)致整個(gè)鏈路失敗。該種結(jié)構(gòu)下類似于串聯(lián)電路,甚至在部分調(diào)用失敗的情況下,還會(huì)出現(xiàn)狀態(tài)不一致。而采用 RocketMQ 進(jìn)行異步集成,只要 RocketMQ 服務(wù)可用,用戶的業(yè)務(wù)操作便可用。RocketMQ 服務(wù)通過多對(duì)主備組成的 broker 集群提供,只要有一對(duì)主備可用,則整體服務(wù)可用,作為基礎(chǔ)軟件,可用性遠(yuǎn)大于普通的業(yè)務(wù)應(yīng)用,下游應(yīng)用的業(yè)務(wù)推進(jìn)都可以通過 MQ 的可靠消息投遞來達(dá)成。
流量解耦
即削峰填谷。如果采用同步調(diào)用的方式,上下游的容量必須對(duì)齊,否則會(huì)出現(xiàn)級(jí)聯(lián)不可用。容量完全對(duì)齊需要投入大量精力進(jìn)行全鏈路壓測(cè)與更多機(jī)器成本。而通過引入 RocketMQ,基于 RocketMQ 億級(jí)消息的堆積能力,對(duì)于實(shí)時(shí)性要求不高的下游業(yè)務(wù),可以盡最大努力消費(fèi),既保證了系統(tǒng)穩(wěn)定性,又降低了機(jī)器成本與研發(fā)運(yùn)維成本。
02
基礎(chǔ)特性
Cloud Native
阿里的交易應(yīng)用流程為:用戶在淘寶上下單時(shí)會(huì)調(diào)用交易應(yīng)用創(chuàng)建訂單,交易應(yīng)用將訂單落到數(shù)據(jù)庫(kù),然后生產(chǎn)一條訂單創(chuàng)建的消息到 RocketMQ,返回給終端用戶訂單創(chuàng)建成功的接口。完成的交易流程推進(jìn)則是依賴 RocketMQ 將訂單創(chuàng)建消息投遞給下游應(yīng)用,會(huì)員應(yīng)用收到訂單消息,需要給買家贈(zèng)送積分、淘金幣,觸發(fā)用戶激勵(lì)相關(guān)的業(yè)務(wù)。購(gòu)物車應(yīng)用則是負(fù)責(zé)刪除在購(gòu)物車?yán)锩娴?a target="_blank">商品,避免用戶重復(fù)購(gòu)買。同時(shí),支付系統(tǒng)與物流系統(tǒng)也都會(huì)基于訂單狀態(tài)的變更,推進(jìn)支付環(huán)節(jié)與履約環(huán)節(jié)。
過去十年多年,阿里電商業(yè)務(wù)持續(xù)蓬勃發(fā)展,交易的下游應(yīng)用已達(dá)數(shù)百個(gè),并且還在不斷增加。基于 RocketMQ 的電商架構(gòu)極大提高了阿里電商業(yè)務(wù)的敏捷度,上游核心的交易系統(tǒng)完全無需關(guān)心哪些應(yīng)用在訂閱交易消息,交易應(yīng)用的延遲與可用性也一直保持在很高水準(zhǔn),只依賴少量的核心系統(tǒng)與 RocketMQ,不會(huì)受數(shù)百個(gè)下游應(yīng)用的影響。
交易的下游業(yè)務(wù)類型不一,有大量的業(yè)務(wù)場(chǎng)景不需要實(shí)時(shí)消費(fèi)交易數(shù)據(jù),比如物流場(chǎng)景能容忍一定的延遲。通過 RocketMQ 的億級(jí)堆積能力,極大降低了機(jī)器成本。RocketMQ 的 shared-nothing 架構(gòu)具備無限橫向擴(kuò)展的能力,已經(jīng)連續(xù) 10 年支撐了高速增長(zhǎng)的雙十一消息峰值,在幾年前達(dá)到億級(jí) TPS。
03
增強(qiáng)能力
Cloud Native
經(jīng)典場(chǎng)景下,RocketMQ 相對(duì)于其他消息隊(duì)列,擁有諸多差異化優(yōu)勢(shì)與增強(qiáng)。
首先,穩(wěn)定性方面,穩(wěn)定性交易是金融場(chǎng)景最重要的需求。RocketMQ 的穩(wěn)定性不僅限于高可用架構(gòu),而是通過全方位的產(chǎn)品能力來構(gòu)建穩(wěn)定性競(jìng)爭(zhēng)力。比如重試隊(duì)列,當(dāng)下游消費(fèi)者因?yàn)闃I(yè)務(wù)數(shù)據(jù)不 ready 或其他原因?qū)е履硹l消息消費(fèi)失敗,RocketMQ 不會(huì)因此阻塞消費(fèi),而是能將此消息加入到重試隊(duì)列,然后按時(shí)間衰減重試。如果某條消息因?yàn)槟承┮蛩亟?jīng)過十幾次重試始終無法消費(fèi)成功,則 RocketMQ 會(huì)將它轉(zhuǎn)到死信隊(duì)列,用戶可以通過其他手段來處理失敗的消息,是金融行業(yè)的剛需。
同時(shí),消費(fèi)成功后如果因?yàn)榇a bug 導(dǎo)致業(yè)務(wù)不符合預(yù)期,應(yīng)用可以對(duì)業(yè)務(wù) bug 進(jìn)行修復(fù)并重新發(fā)布,然后應(yīng)用消息回溯的功能將消息拉回到之前的時(shí)間點(diǎn),讓業(yè)務(wù)按照正確邏輯重新處理。
RocketMQ 的消費(fèi)實(shí)現(xiàn)機(jī)制采用自適應(yīng)拉模式的消費(fèi),在極端的場(chǎng)景下能夠避免消費(fèi)者被大流量打垮。同時(shí),在消費(fèi)者的 SDK 里,做了緩存本地的消息數(shù)量與消息內(nèi)存占用的閾值保護(hù),防止消費(fèi)應(yīng)用的內(nèi)存風(fēng)險(xiǎn)。
其次,RocketMQ 還具備優(yōu)秀的可觀測(cè)能力,是穩(wěn)定性的重要輔助手段。
RocketMQ 是業(yè)界第一個(gè)提供消息消息級(jí)別可觀測(cè)能力的消息隊(duì)列,每條消息都可以帶上業(yè)務(wù)主鍵,比如在交易場(chǎng)景,用戶可以將訂單 ID 作為消息的業(yè)務(wù)主鍵。當(dāng)某個(gè)訂單的業(yè)務(wù)需要排查,用戶可以基于訂單 ID 查詢?cè)摋l消息的生成時(shí)間以及消息內(nèi)容。消息的可觀測(cè)數(shù)據(jù)還能繼續(xù)下鉆,通過消息軌跡查看消息由哪臺(tái)生產(chǎn)者機(jī)器發(fā)送、由哪些消費(fèi)者機(jī)器在什么時(shí)間消費(fèi)、消費(fèi)狀態(tài)是成功或失敗等。
除此之外,它支持了幾十種核心的度量數(shù)據(jù),包括集群生產(chǎn)者流量分布、慢消費(fèi)者排行、消費(fèi)的平均延遲、消費(fèi)堆積數(shù)量、消費(fèi)成功率等。基于豐富的指標(biāo),用戶可以搭建更加完善的監(jiān)控報(bào)警體系來進(jìn)一步加固穩(wěn)定性。
為了支撐更靈活的應(yīng)用架構(gòu),RocketMQ 在生產(chǎn)與消費(fèi)等關(guān)鍵接口提供了多種模式。
生產(chǎn)者接口:RocketMQ 同時(shí)提供了同步發(fā)送接口與異步發(fā)送接口。同步發(fā)送是最常用的模式,業(yè)務(wù)流程的編排是串行的,在應(yīng)用發(fā)完消息、Broker 完成存儲(chǔ)后返回成功后,應(yīng)用再執(zhí)行下一步邏輯。然而在某些場(chǎng)景下,完成業(yè)務(wù)涉及多個(gè)遠(yuǎn)程調(diào)用,應(yīng)用為了進(jìn)一步降低延遲、提高性能,會(huì)采用全異步化的方式,并發(fā)發(fā)出遠(yuǎn)程調(diào)用(可以是多次發(fā)消息或 RPC 的組合),異步收集結(jié)果推,進(jìn)業(yè)務(wù)邏輯。
在消費(fèi)者的接口方面也提供了兩種方式:
監(jiān)聽器模式被動(dòng)消費(fèi) 這是目前使用最廣泛的方式,用戶無需關(guān)心客戶端何時(shí)去 Broker 拉取消息,何時(shí)向 Broker 發(fā)出消費(fèi)成功的確認(rèn),也無需維護(hù)消費(fèi)線程池、本地消息緩存等細(xì)節(jié)。只需要寫一段消息監(jiān)聽器的業(yè)務(wù)邏輯,根據(jù)業(yè)務(wù)執(zhí)行結(jié)果返回 Success 或 Failure。它屬于全托管的模式,用戶可以專注于業(yè)務(wù)邏輯的編寫,而將實(shí)現(xiàn)細(xì)節(jié)完全委托給 RocketMQ 客戶端。
主動(dòng)消費(fèi)模式
將更多的自主權(quán)交給用戶,也稱為 Simple Consumer。在該種模式下,用戶可以自己決定何時(shí)去 Broker 讀取消息、何時(shí)發(fā)起消費(fèi)確認(rèn)消息。對(duì)業(yè)務(wù)邏輯的執(zhí)行線程也有自主可控性,讀取完消息后,可以將消費(fèi)邏輯放在自定義的線程池執(zhí)行。在某些場(chǎng)景下,不同消息的處理時(shí)長(zhǎng)與優(yōu)先級(jí)會(huì)有所不同,采用 Simple Consumer 的模式,用戶可根據(jù)消息的屬性、大小做二次分發(fā),隔離到不同的業(yè)務(wù)線程池執(zhí)行處理。該模式還提供了消息粒度消費(fèi)超時(shí)時(shí)間的設(shè)定能力,針對(duì)某些消費(fèi)耗時(shí)長(zhǎng)的消息,用戶能夠調(diào)用 change Invisible Duration 接口,延長(zhǎng)消費(fèi)時(shí)間,避免超時(shí)重試。
04
總結(jié)
Cloud Native
消息經(jīng)典場(chǎng)景:應(yīng)用解耦;
RocketMQ 基礎(chǔ)特性:發(fā)布訂閱、可靠消息、億級(jí)堆積、無限擴(kuò)展;
業(yè)務(wù)消息場(chǎng)景的增強(qiáng)能力:穩(wěn)定性、可觀測(cè)、多樣化接口。
審核編輯:劉清
-
存儲(chǔ)器
+關(guān)注
關(guān)注
38文章
7455瀏覽量
163624 -
衰減器
+關(guān)注
關(guān)注
4文章
635瀏覽量
34310 -
RPC
+關(guān)注
關(guān)注
0文章
111瀏覽量
11515 -
TPS
+關(guān)注
關(guān)注
0文章
83瀏覽量
36189 -
解耦控制
+關(guān)注
關(guān)注
0文章
29瀏覽量
10208
原文標(biāo)題:RocketMQ在業(yè)務(wù)消息場(chǎng)景的優(yōu)勢(shì)詳解
文章出處:【微信號(hào):OSC開源社區(qū),微信公眾號(hào):OSC開源社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論