其他分享
首页 > 其他分享> > 消息治理,到底需要治理哪些内容?

消息治理,到底需要治理哪些内容?

作者:互联网

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

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

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

强大的监控体系

服务端监控

MQ本身就是一个程序,那么这个程序本身的健康状况我们需要关注,假设我们的MQ是Java开发的,那么JVM指标也需要监控。同时发消息的耗时啊等等都需要监控。

服务器层面监控

无论你的MQ是部署在物理机上还是容器上,MQ都依赖它。所以对于服务器层面的监控也是必不可少。像CPU, 内存,磁盘IO,网络等等。

业务层面监控

强大的运维体系

集群自动化部署

当规模到达一定的时候,一定要具备高度自动化的能力。就像云产品一样,今天业务团队需要一个新的集群,直接走工单审批,等审批通过后集群自动创建好。

集群弹性扩容

有了自动化部署后,弹性扩容也是水到渠成的事情。当集群的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

标签:场景,Group,到底,哪些,Topic,MQ,消息,监控,治理
来源: https://www.cnblogs.com/jiagoubaiduren/p/16323267.html