大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第六篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

不知道大家发现没有，虽然市面上已经有很多优秀的开源消息队列了，但是一些公司还是热衷于自研。并不是说开源的不好，而是开源的产品要考虑的是很多通用的场景，而公司内部可以更加精细化的考虑公司内部的场景，结合业务的特点来研发出更适合企业的框架。

无论是微服务，还是消息队列，都会涉及到治理。那么消息我们到底需要进行哪些治理呢？

强大的监控体系

服务端监控

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利器：

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