需要拥有什么才能达到丝滑的消息治理

[q464824151]

• 强大的监控体系：服务端监控。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中都是支持的。

• 消费位重置：消费位重置指的是通过后台，我们可以将消费点进行倒退到某一个时间点，然后重新将这个时间点之后的消息进行投递，让消费者再消费一次的操作。一般情况下这个功能是用不到的，但是某些场景还是有可能用到。

其实最常用的就是某一条消息进行重新投递，比如我们在测试环境出了一个什么问题，然后想验证下，这个时候可以去后台将这个消息重新投递一次，然后再观察下日志，去排查问题。