建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「Java極客技術(shù)」，作者鴨血粉絲。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java極客技術(shù)公眾號(hào)。
創(chuàng)新互聯(lián)建站專注于企業(yè)網(wǎng)絡(luò)營(yíng)銷推廣、網(wǎng)站重做改版、韶關(guān)網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計(jì)、成都商城網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為韶關(guān)等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
阿粉之前看了一場(chǎng)架構(gòu)師之路沈劍老師的一場(chǎng)直播，最近又重溫了一下，根據(jù)自己的認(rèn)知總結(jié)了一下，分享給大家。
MQ 想必大家或多或少都用過(guò)，接入 MQ 之后的整體架構(gòu)如下：
可以看到使用 MQ 之后，上下游通信就變成圖上的這種方式。
這種跨進(jìn)程的通信方式，我們還有一種常用的解決方案，使用 Dubbo 等這類 RPC 服務(wù)。
理論上使用 RPC 的跨進(jìn)程通信的場(chǎng)景，使用 MQ 也能解決，當(dāng)然反過(guò)來(lái)也能說(shuō)通。
那為什么不都用 RPC，或者 MQ 來(lái)解決那?
這其實(shí)都是業(yè)務(wù)場(chǎng)景決定的，拋開業(yè)務(wù)場(chǎng)景來(lái)談架構(gòu)都是耍流氓!沒(méi)有全能的架構(gòu)，只要適合的架構(gòu)。
下面我們來(lái)看看哪些場(chǎng)景適合 RPC，而哪些場(chǎng)景適合 MQ。
RPC 場(chǎng)景
使用 RPC 的場(chǎng)景一般都是上游服務(wù)需要實(shí)時(shí)依賴下游服務(wù)的返回。
我們以一個(gè)登錄服務(wù)為例，架構(gòu)圖如下：
用戶發(fā)起的登錄請(qǐng)求首先由對(duì)外的 WEB 服務(wù)接受，然后 WEB 服務(wù)服務(wù)調(diào)用用戶服務(wù)查詢用戶信息，然后比對(duì)用戶密碼。
也就是說(shuō)我們的 WEB 應(yīng)用需要實(shí)時(shí)依賴用戶服務(wù)返回的用戶信息，如果沒(méi)有返回，這次登錄將會(huì)失敗。
假如這個(gè)場(chǎng)景我們用 MQ 代替， WEB 應(yīng)用發(fā)送 MQ 消息之后，然后流程就結(jié)束了，此時(shí) WEB 應(yīng)用無(wú)法拿到用戶信息。
所以說(shuō)對(duì)于這種需要強(qiáng)依賴下游返回的場(chǎng)景，使用 MQ 將會(huì)帶來(lái)以下不足：
- 上游無(wú)法直接得到下游結(jié)果
- 增加一個(gè) MQ 組件，系統(tǒng)更復(fù)雜
MQ 場(chǎng)景
上游不關(guān)心下游結(jié)果的場(chǎng)景舉個(gè)例子，在我們第三方支付系統(tǒng)中，每支付成功一筆，都需要計(jì)算手續(xù)費(fèi)。
這個(gè)場(chǎng)景我們顯然可以使用 RPC 完成調(diào)用，但是實(shí)際上，支付系統(tǒng)是不關(guān)心的計(jì)費(fèi)系統(tǒng)的結(jié)果，兩個(gè)系統(tǒng)不存在直接強(qiáng)依賴的關(guān)系。
大家可以想象一下，用戶實(shí)際上已經(jīng)收到銀行卡扣款短信了，但是支付系統(tǒng)因?yàn)橛?jì)費(fèi)系統(tǒng)失敗，導(dǎo)致對(duì)外返回是失敗的結(jié)果。這對(duì)于用戶來(lái)講，不能接受啊。我都付錢了，你卻告訴我支付異常。
所以對(duì)于這種場(chǎng)景，直接使用 RPC 調(diào)用由以下幾點(diǎn)不足：
- 系統(tǒng)整體調(diào)用延時(shí)增加
- 下游服務(wù)異常，影響上游服務(wù)。兩者物理以及邏輯依賴嚴(yán)重
- 若后面再增加一個(gè)下游系統(tǒng)，需要知道支付成功的結(jié)果，上游系統(tǒng)需要改動(dòng)代碼。這種情況對(duì)于上游情況來(lái)講，就會(huì)很煩。明明與上游系統(tǒng)沒(méi)有什么關(guān)系，卻需要修改代碼。
那一定要用 MQ 解決嗎?
其實(shí)不一定，對(duì)于我們上面舉的場(chǎng)景，我們其實(shí)可以使用異步 RPC 或者線程池異步調(diào)用 RPC 就可以解決。
畢竟增加一個(gè) MQ， 系統(tǒng)就變得更加復(fù)雜，我們還要單獨(dú)運(yùn)維 MQ，這對(duì)于小團(tuán)隊(duì)來(lái)講，工作量還是很大的。
但是這種方式，還是解決不了，增加一個(gè)下游系統(tǒng)，上游系統(tǒng)還要改動(dòng)的代碼囧境。
增加 MQ 解耦
這個(gè)場(chǎng)景使用 MQ 解耦，帶來(lái)幾點(diǎn)優(yōu)點(diǎn)：
- 任務(wù)一：上游系統(tǒng)執(zhí)行時(shí)間變短
- 任務(wù)二：上下游邏輯解耦，物理解耦
- 任務(wù)三：最重要一點(diǎn)，增加一個(gè)下游服務(wù)，其只要訂閱即可，上游服務(wù)無(wú)需要改動(dòng)代碼
數(shù)據(jù)驅(qū)動(dòng)的定時(shí)任務(wù)場(chǎng)景舉個(gè)例子，支付公司每日都需要對(duì)賬，主要目的是核實(shí)自己系統(tǒng)的應(yīng)收的錢與支付渠道端是否一致，主要流程分為以下幾步：
定時(shí)任務(wù)下載渠道對(duì)賬文件，下載方式可能為 Http 接口下載，也有可能 SFTP 下載
定時(shí)任務(wù)解析對(duì)賬文件，然后將對(duì)賬數(shù)據(jù)入庫(kù)
定時(shí)任務(wù)將自己本端支付數(shù)據(jù)與對(duì)賬數(shù)據(jù)核對(duì)
上面的定時(shí)任務(wù)使用 Spring-Schedule 調(diào)度，假設(shè)各個(gè)定時(shí)任務(wù)下載時(shí)間如下所示：
上圖中三個(gè)任務(wù)，任務(wù)二需要依賴任務(wù)一完成，而任務(wù)三又需要依賴任務(wù)二完成。
我們之前使用這種模式，通常會(huì)碰到幾個(gè)問(wèn)題：
- 通常 06:00 就能下載到對(duì)賬文件，但是有時(shí)候渠道端對(duì)賬文件延遲，就會(huì)導(dǎo)致任務(wù)一執(zhí)行失敗，這樣就會(huì)后續(xù)兩個(gè)定時(shí)任務(wù)也會(huì)執(zhí)行失敗
- 假設(shè)任務(wù)二數(shù)據(jù)過(guò)多，執(zhí)行時(shí)間過(guò)長(zhǎng)，任務(wù)三執(zhí)行時(shí)還沒(méi)結(jié)束，這就導(dǎo)致任務(wù)三無(wú)法拿到全量數(shù)據(jù)，導(dǎo)致對(duì)賬異常
- 整體任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)
- 任務(wù)一若調(diào)整時(shí)間，可能導(dǎo)致任務(wù)二，任務(wù)三都需要調(diào)整時(shí)間
使用 MQ解耦
使用 MQ 解耦之后架構(gòu)圖如下：
這種方式，只要任務(wù)一的定時(shí)任務(wù)準(zhǔn)時(shí)啟動(dòng)，任務(wù)一完成之后發(fā)送 MQ 消息，任務(wù)二收到之后就會(huì)啟動(dòng)任務(wù)，結(jié)束之后再發(fā)送消息給 MQ。任務(wù)三流程同任務(wù)二
使用這種方式存在優(yōu)點(diǎn)為：
- 下游任務(wù)只要收到消息就能立刻執(zhí)行，不需要額外等待，整體任務(wù)執(zhí)行時(shí)間變短
- 上游任務(wù)時(shí)間變動(dòng)，無(wú)需修改下游任務(wù)時(shí)間。我們這個(gè)例子，只需要任務(wù)一的實(shí)際即可
總結(jié)
對(duì)于上游需要關(guān)注下游返回結(jié)果的場(chǎng)景，不適合使用 MQ。
適合使用 MQ 的場(chǎng)景有：
上游不關(guān)心下游結(jié)果的場(chǎng)景
數(shù)據(jù)驅(qū)動(dòng)的定時(shí)任務(wù)依賴
新聞標(biāo)題：RPC用著好好的？為什么還需要使用MQ？
網(wǎng)址分享：http://www.5511xx.com/article/dpsodhe.html
