大家好，我是【架構擺渡人】，一隻十年的程式猿。這是訊息佇列的第六篇文章，這個系列會給大家分享很多在實際工作中有用的經驗，如果有收穫，還請分享給更多的朋友。
不知道大家發現沒有，雖然市面上已經有很多優秀的開源訊息佇列了，但是一些公司還是熱衷於自研。並不是說開源的不好，而是開源的產品要考慮的是很多通用的場景，而公司內部可以更加精細化的考慮公司內部的場景，結合業務的特點來研發出更適合企業的框架。
無論是微服務，還是訊息佇列，都會涉及到治理。那麼訊息我們到底需要進行哪些治理呢？
強大的監控體系
服務端監控
MQ本身就是一個程式，那麼這個程式本身的健康狀況我們需要關注，假設我們的MQ是Java開發的，那麼JVM指標也需要監控。同時發訊息的耗時啊等等都需要監控。
伺服器層面監控
無論你的MQ是部署在物理機上還是容器上，MQ都依賴它。所以對於伺服器層面的監控也是必不可少。像CPU, 記憶體，磁碟IO，網路等等。
業務層面監控
-
訊息堆積
訊息堆積對線上業務場景有很大的影響，必須具備實時監控的能力。當有訊息堆積時及時通過 告警機制通知業務團隊進行處理。 -
QPS飆升
當整個叢集或者某個Topic級別的訊息傳送量在1分鐘之內極度飆升，那麼需要及時關注。因為很有可能會超過MQ本身的承受範圍，同時消費方也會產生堆積問題。 -
死信訊息
當消費者消費某條訊息一直失敗的時候，已經超過了最大重試次數，這條訊息會進入死信佇列。這塊也是需要及時監控，因為一旦有死信訊息，也就是意味著你的消費邏輯存在問題，需要及時修復。 -
消費失敗率
當消費方訊息訊息，頻繁失敗的時候，也需要有對應的監控告警。這個其實在MQ的client包裡面就可以進行資料的埋點上報。
強大的運維體系
叢集自動化部署
當規模到達一定的時候，一定要具備高度自動化的能力。就像雲產品一樣，今天業務團隊需要一個新的叢集，直接走工單審批，等審批通過後叢集自動建立好。
叢集彈性擴容
有了自動化部署後，彈性擴容也是水到渠成的事情。當叢集的QPS超過了本身能夠承載的量，必然會進行限流，但是一旦限流，也就意味著業務功能有損。所以具備彈性擴容的能力非常重要，最好是自動化的彈性擴容。
資源隔離
資源隔離非常重要，我們用MQ也是不同的業務場景，不同的場景對穩定性的要求也不一樣。比如線上交易場景的穩定性肯定要高於一些後臺操作類的場景。
比如訂單會將訂單的生命週期通過訊息的形式傳送出去，各個業務域按需進行訂閱。如果訂單的叢集跟其他業務共用一套，當其他業務出現某些問題的時候，那麼就會影響訂單的訊息，所以要針對業務場景進行資源的隔離。
強大的治理後臺
Topic&Group管理
Topic和Group的管理是最基本的功能，每個迭代都會有新增的Topic和Group，所以能夠通過後臺快速建立Topic和Group至關重要。
同時也能檢視Topic中的訊息，Group的線上情況，消費情況等等資訊。
賬號許可權體系
當公司組織規模大了後，嚴格的賬號許可權體系必不可少。無論是Topic和Group的建立，還是訊息查詢的許可權，MQ吞吐量的資料等等，都需要嚴格控制許可權，不能隨意公開。
其次，對於操作類的申請，要結合審批流進行多層審批，提高安全係數。
訊息軌跡
訊息軌跡在實際排查問題的時候非常有用，通過訊息軌跡，我們可以檢視某條訊息到底有沒有被消費？是誰消費了這條訊息？消費耗時了多久？這個功能在很多MQ中都是支援的。
消費位重置
消費位重置指的是通過後臺，我們可以將消費點進行倒退到某一個時間點，然後重新將這個時間點之後的訊息進行投遞，讓消費者再消費一次的操作。一般情況下這個功能是用不到的，但是某些場景還是有可能用到。
其實最常用的就是某一條訊息進行重新投遞，比如我們在測試環境出了一個什麼問題，然後想驗證下，這個時候可以去後臺將這個訊息重新投遞一次，然後再觀察下日誌，去排查問題。
總結
我這邊只是列了一些最基本的需要進行治理的內容，都是實實在在的需求，就是我們在工作中都會碰到這些場景。如果大家覺得有漏掉的其他比較重要的點，歡迎留言討論。
最後推薦一個基於Java Agent實現的自測，聯調Mock利器：