在进一步深入讲解这些用例把背后的的诉求前,说明一下客户端开启ACL是指在构建消息发送者、消息消费者时,传入与ACL相关的参数,截图如下:
接下来逐步分析上述测试用例的目的。
2.1 客户端不开启ACL,服务端开启ACL
例如像我们公司的技术架构,涉及到数据的流转,重度依赖MQ,目前应用中存在太多的低版本的MQ客户端,例如4.1.0,如果服务端开启了ACL,如果能兼容低版本客户端,那这样升级起来就会显得非常容易,但经过测试:结果为不兼容。其实这个也好理解,服务端开启了ACL,客户端没有授权信息,是肯定不会让你通过的。
2.2 客户端开启ACL,服务端不开启ACL
经过测试,服务端如果不开启ACL的话,尽管客户端在消息发送、消息消费等场景下发送了授权信息,但服务端会忽略这些信息,并不会触发ACL校验。
基于开源版本,通过上面的验证,其优雅升级思路:为各个客户端规划好用户名与密钥,并且对所有客户端进行改造,等待所有客户端都完成改造后,服务端再开启ACL。
通常在具体实践中,由于涉及所有客户端改造,可以分集群进行改造,由上到下推动该事项的执行,统一定好一个客户端改造的最后时间点,在该时间点后,服务端开启ACL,至此完成RocketMQ集群的授信访问。、
上述方案的缺点也是显而易见的,需要客户端先行改动,只有等所有客户端全部改造完成后,服务端才能开启ACL。
由于当时项目的升级的迫切性,基于官方版本这种升级方案显然无法满足我们当时的需求。回到文章开头部分说的紧迫诉求:当务之急是要限制生产环境任意一台机器对MQ集群的管理权限,即限制对MQ中topic、消费组的创建与删除,对Broker相关配置的修改。
为了解决上述问题,需要利用RocketMQ自定义的ACL校验机制,其策略概况如下:
-
对于需要admin权限的操作,服务端必须开启校验。
-
对于不需要admin权限的操作,例如消息的发送、消费,如果客户端没有上传校验信息,默认放行
基于上述这样的改造,暂时可以解决问题。
RocketMQ的acl校验器是基于SPI机制,可插拔,提供了org.apache.rocketmq.acl.AccessValidator接口,并且需要将具体实现类写入到broker/src/main/resources/META-INF.service /org.apache.rocketmq.acl. AccessValidat or文件中。
但需要注意的是,如果该文件中配置了多个校验器,会自动组装成链条。
在实际使用过程中,发现这种扩展机制从使用层面来看并不优好,校验器(策略)尽量参数化,即在broker中使用参数来指定。
小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
、讲解视频**
如果你觉得这些内容对你有帮助,可以添加下面V无偿领取!(备注Java)
[外链图片转存中…(img-RpTCyhNq-1710838638740)]