建站
咨詢
售后
建站咨詢
新聞中心
簡(jiǎn)單介紹了服務(wù)網(wǎng)關(guān)，并對(duì)SpringCloud Gateway的核心架構(gòu)進(jìn)行了簡(jiǎn)要說明，也在項(xiàng)目中整合了SpringCloud
Gateway網(wǎng)關(guān)實(shí)現(xiàn)了通過網(wǎng)關(guān)訪問后端微服務(wù)，同時(shí)，也基于SpringCloud Gateway整合Sentinel實(shí)現(xiàn)了網(wǎng)關(guān)的限流功能，詳細(xì)介紹了SpringCloud Gateway網(wǎng)關(guān)的核心技術(shù)。
創(chuàng)新互聯(lián)10多年企業(yè)網(wǎng)站設(shè)計(jì)服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及高端網(wǎng)站定制服務(wù),企業(yè)網(wǎng)站設(shè)計(jì)及推廣,對(duì)高空作業(yè)車租賃等多個(gè)領(lǐng)域擁有多年的營(yíng)銷推廣經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。
在鏈路追蹤章節(jié)，我們開始簡(jiǎn)單介紹了分布式鏈路追蹤技術(shù)與解決方案，隨后在項(xiàng)目中整合Sleuth實(shí)現(xiàn)了鏈路追蹤，并使用Sleuth整合ZipKin實(shí)現(xiàn)了分布式鏈路追蹤的可視化 。
今天，我們正式進(jìn)入消息服務(wù)章節(jié)，首先，我們來簡(jiǎn)單的聊聊MQ的使用場(chǎng)景，引入MQ后的注意事項(xiàng)以及MQ的選型對(duì)比。
本章總覽
MQ的使用場(chǎng)景
MQ的英文全稱是Message Queue，翻譯成中文就是消息隊(duì)列，隊(duì)列實(shí)現(xiàn)了先進(jìn)先出(FIFO)的消息模型。通過消息隊(duì)列，我們可以實(shí)現(xiàn)多個(gè)進(jìn)程之間的通信，例如，可以實(shí)現(xiàn)多個(gè)微服務(wù)之間的消息通信。MQ的最簡(jiǎn)模型就是生產(chǎn)者生產(chǎn)消息，將消息發(fā)送到MQ，消息消費(fèi)者訂閱MQ，消費(fèi)消息。
MQ的使用場(chǎng)景通常包含：異步解耦、流量削峰。
異步解耦
關(guān)于異步的場(chǎng)景，我們這里舉一個(gè)用戶下單成功后，向用戶發(fā)送通知消息，為用戶增加積分和優(yōu)惠券的場(chǎng)景。
同步耦合場(chǎng)景分析
如果是同步調(diào)用的場(chǎng)景，則具體業(yè)務(wù)為：當(dāng)用戶提交訂單成功后，訂單系統(tǒng)會(huì)調(diào)用通知系統(tǒng)為用戶發(fā)送消息通知，告知用戶下單成功，訂單系統(tǒng)調(diào)用積分系統(tǒng)為用戶增加積分，訂單系統(tǒng)調(diào)用優(yōu)惠券系統(tǒng)為用戶增加優(yōu)惠券。整個(gè)調(diào)用流程如下所示。
通過上圖的分析，可以看到，用戶調(diào)用訂單系統(tǒng)下單時(shí)，總共會(huì)經(jīng)過8個(gè)步驟。并且每個(gè)步驟都是緊密耦合在一起串行執(zhí)行，如下所示。
此時(shí)，訂單系統(tǒng)、通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)是緊密耦合在一起的，訂單系統(tǒng)下單、通知系統(tǒng)發(fā)通知、積分系統(tǒng)發(fā)積分和優(yōu)惠券系統(tǒng)發(fā)優(yōu)惠券，四個(gè)任務(wù)全部完成后，才會(huì)給用戶返回提交訂單的結(jié)果信息。
用戶提交訂單花費(fèi)的總時(shí)間為調(diào)用訂單系統(tǒng)下單的時(shí)間+訂單系統(tǒng)調(diào)用通知系統(tǒng)發(fā)送通知的時(shí)間+訂單系統(tǒng)調(diào)用積分系統(tǒng)發(fā)放積分的時(shí)間+訂單系統(tǒng)調(diào)用優(yōu)惠券系統(tǒng)發(fā)放優(yōu)惠券的時(shí)間。
注意：這里為了更好的說明系統(tǒng)之間串行執(zhí)行的問題，忽略了網(wǎng)絡(luò)的延遲時(shí)間。
這種串行化的系統(tǒng)執(zhí)行方式，在高并發(fā)、大流量場(chǎng)景下是不可取的。另外，如果其中一個(gè)系統(tǒng)異?；蛘咤礄C(jī)，勢(shì)必會(huì)影響到訂單系統(tǒng)的可用性。在系統(tǒng)維護(hù)上，只要任意一個(gè)系統(tǒng)的接口發(fā)生變動(dòng)，訂單系統(tǒng)的邏輯也要跟著發(fā)生變動(dòng)。
異步解耦場(chǎng)景分析
既然在高并發(fā)、大流量場(chǎng)景下使用訂單系統(tǒng)直接串行調(diào)用通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)的方式不可取。那我們是否能夠使用異步解耦的方式呢。
其實(shí)，在用戶提交訂單的場(chǎng)景中，用戶最關(guān)心的是自己的訂單是否提交成功，由于下單時(shí)，訂單系統(tǒng)會(huì)直接返回是否下單成功的提示。
對(duì)于通知、積分和優(yōu)惠券可以以異步的方式延后一小段時(shí)間執(zhí)行。并且通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)之間不存在必然的業(yè)務(wù)關(guān)聯(lián)邏輯，它們之間可以以并行的方式執(zhí)行。
所以，可以使用MQ將訂單系統(tǒng)與通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)進(jìn)行解耦，用戶調(diào)用訂單系統(tǒng)的接口下單時(shí)，訂單系統(tǒng)向數(shù)據(jù)庫(kù)寫入訂單數(shù)據(jù)后，向MQ寫入消息，就可以直接返回給用戶下單成功的提示，此時(shí)通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)都訂閱MQ中的消息，收到消息后各自執(zhí)行自身的業(yè)務(wù)邏輯即可。
當(dāng)引入MQ進(jìn)行異步解耦之后，用戶調(diào)用訂單系統(tǒng)的接口下單，訂單系統(tǒng)執(zhí)行完業(yè)務(wù)邏輯將訂單數(shù)據(jù)入口，會(huì)向MQ發(fā)送一條消息，隨后便直接返回用戶下單成功的提示。通知系統(tǒng)、積分系統(tǒng)和優(yōu)惠券系統(tǒng)會(huì)同時(shí)訂閱MQ中的消息，當(dāng)收到消息時(shí)，它們各自會(huì)執(zhí)行自身的業(yè)務(wù)邏輯，并且它們是以并行的方式執(zhí)行各自的業(yè)務(wù)邏輯。
從執(zhí)行的時(shí)間線上可以看出，當(dāng)引入MQ進(jìn)行異步解耦之后，通知系統(tǒng)、積分系統(tǒng)、優(yōu)惠券系統(tǒng)和訂單系統(tǒng)回復(fù)響應(yīng)都是并行執(zhí)行的，大大提高系統(tǒng)的執(zhí)行性能。
并且解耦后，任意一個(gè)系統(tǒng)異常或者宕機(jī)，都不會(huì)影響到訂單系統(tǒng)的可用性。只要訂單系統(tǒng)與其他系統(tǒng)提前約定好發(fā)送的消息格式和消息內(nèi)容，后續(xù)任意一個(gè)系統(tǒng)的業(yè)務(wù)邏輯變動(dòng)，幾乎都不會(huì)影響到訂單系統(tǒng)的邏輯。
流量削峰
MQ在高并發(fā)、大流量的場(chǎng)景下可以用作削峰填谷的利器，例如，12306的春運(yùn)搶票場(chǎng)景、高并發(fā)秒殺場(chǎng)景、雙十一和618的大促場(chǎng)景等。
在高并發(fā)、大流量業(yè)務(wù)場(chǎng)景下，瞬間會(huì)有大量用戶的請(qǐng)求涌入系統(tǒng)，如果不對(duì)這些流量做處理的話，直接讓這些流量進(jìn)入下游系統(tǒng)，則很可能由于下游系統(tǒng)無法支撐如此高的并發(fā)而導(dǎo)致系統(tǒng)崩潰或宕機(jī)。為了解決這些問題，可以引入MQ進(jìn)行流量的削峰填谷。
將流量發(fā)送到MQ中后，下游系統(tǒng)根據(jù)自身的處理能力進(jìn)行消費(fèi)即可。保證了下游系統(tǒng)的高可用性。
引入MQ后的注意事項(xiàng)
引入MQ最大的優(yōu)點(diǎn)就是異步解耦和流量削峰，但是引入MQ后也有很多需要注意的事項(xiàng)和問題，主要包括：系統(tǒng)的整體可用性降低、系統(tǒng)的復(fù)雜度變高、引入了消息一致性的問題。
系統(tǒng)的整體可用性降低
在對(duì)一個(gè)系統(tǒng)進(jìn)行架構(gòu)設(shè)計(jì)時(shí)，引入的外部依賴越多，系統(tǒng)的穩(wěn)定性和可用性就會(huì)降低。系統(tǒng)中引入了MQ，部分業(yè)務(wù)就會(huì)出現(xiàn)強(qiáng)依賴MQ的現(xiàn)象，此時(shí)，如果MQ宕機(jī)，則部分業(yè)務(wù)就會(huì)變得不可用。所以，引入MQ時(shí)，我們就要考慮如何實(shí)現(xiàn)MQ的高可用。
系統(tǒng)的復(fù)雜度變高
引入MQ后，會(huì)使之前的同步接口調(diào)用變成通過MQ的異步調(diào)用，在實(shí)際的開發(fā)過程中，異步調(diào)用會(huì)比同步調(diào)用復(fù)雜的多。并且異步調(diào)用出現(xiàn)問題后，重現(xiàn)問題，定位問題和解決問題都會(huì)比同步調(diào)用復(fù)雜的多。
并且引入MQ后，還要考慮如何保證消息的順序等問題。
消息一致性問題
引入MQ后，不得不考慮的一個(gè)問題就是消息的一致性問題。這期間就要考慮如何保證消息不丟失，消息冪等和消息數(shù)據(jù)處理的冪等性問題。
MQ選型對(duì)比
目前，在行業(yè)內(nèi)使用的比較多的MQ包含RabbitMQ、Kafka和RocketMQ。這里，我將三者的對(duì)比簡(jiǎn)單整理了個(gè)表格，如下所示。
|
消息中間件(MQ) |
優(yōu)點(diǎn) |
缺點(diǎn) |
使用場(chǎng)景 |
|
RabbitMQ |
功能全面、消息的可靠性比較高 |
吞吐量低，消息大量積累會(huì)影響性能，使用的開發(fā)語言是erlang，不好定制功能。 |
規(guī)模不大的場(chǎng)景 |
|
Kafka |
吞吐量最高，性能最好，集群模式下高可用 |
功能上比較單一，會(huì)丟失部分?jǐn)?shù)據(jù) |
日志分析，大數(shù)據(jù)場(chǎng)景 |
|
RocketMQ |
吞吐量高，性能高，可用性高，功能全面。使用Java語言開發(fā)，容易定制功能。 |
開源版不如阿里云上版，文檔比較簡(jiǎn)單。 |
幾乎支持所有場(chǎng)景，包含大數(shù)據(jù)場(chǎng)景和業(yè)務(wù)場(chǎng)景。 |
網(wǎng)站欄目：消息服務(wù)：MQ使用場(chǎng)景與選型對(duì)比
文章出自：http://m.fisionsoft.com.cn/article/djijeoh.html
