RocketMQ是一款非常优秀的主流中间件，本文是RocketMQ系列的第52篇文章，重点阐述笔者在公司升级RocketMQ集群并开启ACL的真实经历，并且遇到的一些问题及其解决方案，实战性非常强。
1、ACL机制的重要性
某一天突然接到安全团队的通知，公司内网部署的RocketMQ集群安全性非常低，需要立马整改。
接到安全团队的通知，马上开启了复盘，公司内部的RocketMQ集群还是基于RocketMQ4.1搭建的，存在重大安全隐患，因为生产环境的任意一台机器，不需要知道RocketMQ集群所在机器的密码，就能拥有最高的控制权，说明如下：
试想一下，如果在生产环境任意一台机器上部署一个rocketmq-console，就可以通过rocketmq-console新增、删除topic，其危害性非常之大，是不是后背发凉。
出现这个问题的本质原因：MQ集群没有开启授权访问。
2、迎来曙光
为了解决上述重大安全问题，RocketMQ官方在4.4.0版本引入了ACL,提供访问控制，客户端在创建TOPIC、发送消息、消息消息时首先会判断该客户端是否拥有权限，安全性得到增强。
关于如何搭建ACL已在 ACL使用详解已有详细介绍，本文不做详细介绍，本文主要是阐述从4.1.0版本升级到4.8.0之后，开启ACL的可行性研究。
在升级之前，公司几千个应用客户端使用的是4.1.0版本，升级成4.8.0并开启ACL，我们需要重点验证其兼容性。升级后的部署架构如下图所示：
主要几个测试用例：
- 客户端不开启ACL，服务端开启ACL
- 客户端开启ACL，服务端不开启ACL
在进一步深入讲解这些用例把背后的的诉求前，说明一下客户端开启ACL是指在构建消息发送者、消息消费者时，传入与ACL相关的参数，截图如下：
接下来逐步分析上述测试用例的目的。
2.1 客户端不开启ACL，服务端开启ACL
例如像我们公司的技术架构，涉及到数据的流转，重度依赖MQ，目前应用中存在太多的低版本的MQ客户端，例如4.1.0，如果服务端开启了ACL，如果能兼容低版本客户端，那这样升级起来就会显得非常容易，但经过测试：结果为不兼容。其实这个也好理解，服务端开启了ACL，客户端没有授权信息，是肯定不会让你通过的。
2.2 客户端开启ACL，服务端不开启ACL
经过测试，服务端如果不开启ACL的话，尽管客户端在消息发送、消息消费等场景下发送了授权信息，但服务端会忽略这些信息，并不会触发ACL校验。
3、优雅升级与弊端
基于开源版本，通过上面的验证，其优雅升级思路：为各个客户端规划好用户名与密钥,并且对所有客户端进行改造，等待所有客户端都完成改造后，服务端再开启ACL。
通常在具体实践中，由于涉及所有客户端改造，可以分集群进行改造，由上到下推动该事项的执行，统一定好一个客户端改造的最后时间点，在该时间点后，服务端开启ACL，至此完成RocketMQ集群的授信访问。、
上述方案的缺点也是显而易见的，需要客户端先行改动，只有等所有客户端全部改造完成后，服务端才能开启ACL。
4、自定义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中使用参数来指定。
