大家好，我是【架構(gòu)擺渡人】，一只十年的程序猿。這是消息隊(duì)列的第六篇文章，這個(gè)系列會(huì)給大家分享很多在實(shí)際工作中有用的經(jīng)驗(yàn)，如果有收獲，還請(qǐng)分享給更多的朋友。

?

不知道大家發(fā)現(xiàn)沒有，雖然市面上已經(jīng)有很多優(yōu)秀的開源消息隊(duì)列了，但是一些公司還是熱衷于自研。并不是說開源的不好，而是開源的產(chǎn)品要考慮的是很多通用的場(chǎng)景，而公司內(nèi)部可以更加精細(xì)化的考慮公司內(nèi)部的場(chǎng)景，結(jié)合業(yè)務(wù)的特點(diǎn)來(lái)研發(fā)出更適合企業(yè)的框架。

?

無(wú)論是微服務(wù)，還是消息隊(duì)列，都會(huì)涉及到治理。那么消息我們到底需要進(jìn)行哪些治理呢？

?

強(qiáng)大的監(jiān)控體系

服務(wù)端監(jiān)控

MQ本身就是一個(gè)程序，那么這個(gè)程序本身的健康狀況我們需要關(guān)注，假設(shè)我們的MQ是Java開發(fā)的，那么JVM指標(biāo)也需要監(jiān)控。同時(shí)發(fā)消息的耗時(shí)啊等等都需要監(jiān)控。

?

服務(wù)器層面監(jiān)控

無(wú)論你的MQ是部署在物理機(jī)上還是容器上，MQ都依賴它。所以對(duì)于服務(wù)器層面的監(jiān)控也是必不可少。像CPU, 內(nèi)存，磁盤IO，網(wǎng)絡(luò)等等。

?

業(yè)務(wù)層面監(jiān)控

• 消息堆積

?

消息堆積對(duì)在線業(yè)務(wù)場(chǎng)景有很大的影響，必須具備實(shí)時(shí)監(jiān)控的能力。當(dāng)有消息堆積時(shí)及時(shí)通過 ?告警機(jī)制通知業(yè)務(wù)團(tuán)隊(duì)進(jìn)行處理。

?

• QPS飆升

?

當(dāng)整個(gè)集群或者某個(gè)Topic級(jí)別的消息發(fā)送量在1分鐘之內(nèi)極度飆升，那么需要及時(shí)關(guān)注。因?yàn)楹苡锌赡軙?huì)超過MQ本身的承受范圍，同時(shí)消費(fèi)方也會(huì)產(chǎn)生堆積問題。

?

• 死信消息

?

當(dāng)消費(fèi)者消費(fèi)某條消息一直失敗的時(shí)候，已經(jīng)超過了最大重試次數(shù)，這條消息會(huì)進(jìn)入死信隊(duì)列。這塊也是需要及時(shí)監(jiān)控，因?yàn)橐坏┯兴佬畔ⅲ簿褪且馕吨愕南M(fèi)邏輯存在問題，需要及時(shí)修復(fù)。

?

• 消費(fèi)失敗率

?

當(dāng)消費(fèi)方消息消息，頻繁失敗的時(shí)候，也需要有對(duì)應(yīng)的監(jiān)控告警。這個(gè)其實(shí)在MQ的client包里面就可以進(jìn)行數(shù)據(jù)的埋點(diǎn)上報(bào)。

強(qiáng)大的運(yùn)維體系

集群自動(dòng)化部署

當(dāng)規(guī)模到達(dá)一定的時(shí)候，一定要具備高度自動(dòng)化的能力。就像云產(chǎn)品一樣，今天業(yè)務(wù)團(tuán)隊(duì)需要一個(gè)新的集群，直接走工單審批，等審批通過后集群自動(dòng)創(chuàng)建好。

集群彈性擴(kuò)容

有了自動(dòng)化部署后，彈性擴(kuò)容也是水到渠成的事情。當(dāng)集群的QPS超過了本身能夠承載的量，必然會(huì)進(jìn)行限流，但是一旦限流，也就意味著業(yè)務(wù)功能有損。所以具備彈性擴(kuò)容的能力非常重要，最好是自動(dòng)化的彈性擴(kuò)容。

資源隔離

資源隔離非常重要，我們用MQ也是不同的業(yè)務(wù)場(chǎng)景，不同的場(chǎng)景對(duì)穩(wěn)定性的要求也不一樣。比如在線交易場(chǎng)景的穩(wěn)定性肯定要高于一些后臺(tái)操作類的場(chǎng)景。

?

比如訂單會(huì)將訂單的生命周期通過消息的形式發(fā)送出去，各個(gè)業(yè)務(wù)域按需進(jìn)行訂閱。如果訂單的集群跟其他業(yè)務(wù)共用一套，當(dāng)其他業(yè)務(wù)出現(xiàn)某些問題的時(shí)候，那么就會(huì)影響訂單的消息，所以要針對(duì)業(yè)務(wù)場(chǎng)景進(jìn)行資源的隔離。

強(qiáng)大的治理后臺(tái)

Topic&Group管理

Topic和Group的管理是最基本的功能，每個(gè)迭代都會(huì)有新增的Topic和Group，所以能夠通過后臺(tái)快速創(chuàng)建Topic和Group至關(guān)重要。

?

同時(shí)也能查看Topic中的消息，Group的在線情況，消費(fèi)情況等等信息。

賬號(hào)權(quán)限體系

當(dāng)公司組織規(guī)模大了后，嚴(yán)格的賬號(hào)權(quán)限體系必不可少。無(wú)論是Topic和Group的創(chuàng)建，還是消息查詢的權(quán)限，MQ吞吐量的數(shù)據(jù)等等，都需要嚴(yán)格控制權(quán)限，不能隨意公開。

?

其次，對(duì)于操作類的申請(qǐng)，要結(jié)合審批流進(jìn)行多層審批，提高安全系數(shù)。

消息軌跡

消息軌跡在實(shí)際排查問題的時(shí)候非常有用，通過消息軌跡，我們可以查看某條消息到底有沒有被消費(fèi)？是誰(shuí)消費(fèi)了這條消息？消費(fèi)耗時(shí)了多久？這個(gè)功能在很多MQ中都是支持的。

消費(fèi)位重置

消費(fèi)位重置指的是通過后臺(tái)，我們可以將消費(fèi)點(diǎn)進(jìn)行倒退到某一個(gè)時(shí)間點(diǎn)，然后重新將這個(gè)時(shí)間點(diǎn)之后的消息進(jìn)行投遞，讓消費(fèi)者再消費(fèi)一次的操作。一般情況下這個(gè)功能是用不到的，但是某些場(chǎng)景還是有可能用到。

?

其實(shí)最常用的就是某一條消息進(jìn)行重新投遞，比如我們?cè)跍y(cè)試環(huán)境出了一個(gè)什么問題，然后想驗(yàn)證下，這個(gè)時(shí)候可以去后臺(tái)將這個(gè)消息重新投遞一次，然后再觀察下日志，去排查問題。

總結(jié)

我這邊只是列了一些最基本的需要進(jìn)行治理的內(nèi)容，都是實(shí)實(shí)在在的需求，就是我們?cè)诠ぷ髦卸紩?huì)碰到這些場(chǎng)景。如果大家覺得有漏掉的其他比較重要的點(diǎn)，歡迎留言討論。

?

?

原創(chuàng)：架構(gòu)擺渡人（公眾號(hào)ID：jiagoubaiduren），歡迎分享，轉(zhuǎn)載請(qǐng)保留出處。

最后推薦一個(gè)基于Java Agent實(shí)現(xiàn)的自測(cè)，聯(lián)調(diào)Mock利器：

https://github.com/yinjihuan/fox-mock