接安所有门的行政要求，生产环境上百台RocketMQ机器必须在半个月内升级，必须支持ACL，规避安全风险。java
RocketMQ集群的升级方案、落地实施就天然而然的落到了个人头上，本文不只要介绍一下笔者是如何升级的，更想展现做为一名架构师，处理这些问题的方法论，展现大厂架构师的工做平常。c++
>舒适提示：关于ACL相关的内容，后续文章会单独分享从4.1.0版本升级到4.８并开启ACL的曲折经历。shell
一、版本升级的迫切性
说来惭愧，做为RocketMQ社区优秀布道师，笔者所在公司的RocketMQ服务端版本居然仍是4.1.0，RocketMQ在4.4.0版本以前是不支持ACL(访问控制)，对应生产环境中任意一台机器均可以订阅任意topic，在任意一台生产应用服务器均可以安装一个rocketmq-console，从而控制整个集群，拥有删除主题、删除消费组的权限，想一想是否是后背发凉.安全
二、升级方案
2.1 肯定升级到的版本
翻开RocketMQ升级日志，RocketMQ在4.4.0版本正式引入了ACL机制，故版本至少要升级到4.4.0，在业界使用开源版本有一个不成文的规则：一般不要使用最新的版本，不要充当小白鼠。服务器
但RocketMQ能够算是一个特殊。微信
经过仔细浏览RocketMQ的版本变动记录，咱们不难发现RocketMQ Client 相关的变动很是少，即与用户关系紧密的消息发送、消息消费这块的代码很是的稳定，理论上基本不存在兼容性问题。而且每个版本都修复了一些重大的BUG，性能提高也比较明显，故笔者此次决定“冒天下之大不韪”，决定将帮升级到最新版本4.8.0。架构
在这里在啰嗦一些，简单介绍一下RocketMQ几个具备里程杯意义的版本。运维
- RocketMQ4.3.0正式引入了事务消息，若是你们但愿使用事务消息，其版本最低建议为 4.6.1。
- RocketMQ4.4.0引入了ACL、消息轨迹，若是须要使用这些功能，其版本最低建议为 4.7.0。
- RocketMQ4.5.0引入了多副本（主从切换），其版本建议使用4.7.0。
- RocketMQ4.6.0引入了请求-响应模型。
2.2 升级思路
版本升级的基本要求：业务不能停机，即要作到对业务无感知的升级。性能
若是机器足够的备用机器，最佳的版本迁移方案应该是先扩容再缩容，其示例图以下： 
其主要的思路是先对Broker进行扩容，加入两台高版本的Broker服务器，加入到集群中，而后关闭低版本Broker的写权限，待消息过时后，将低版本移除，最后升级NameServer，完成不停机的在线迁移。测试
因为这次升级须要在半个月左右的时间内将RocketMQ集群全部的节点所有升级，没法提供这么多冷备节点，故先扩容、再缩容没法知足本次需求，本次只能基于已有的机器进行升级。
可否直接升级Broker端代码，但高版本的Broker直接使用低版本的Broker存储目录，即直接升级软件，其示例图以下： 核心思想是先中止老版本的Broker，而后使用新版本启动Broker，但使用旧的配置文件。
有了思路，接下来就是要验证方案的可行性。
2.3 方案验证
理论归理论，在生产环境作任何变动以前，必须有充分的测试验证，版本升级重点须要验证兼容性问题。
2.2.1 服务端版本兼容性验证
搭建一个上述MQ集群，其核心要点：
- 高版本的Broker是否能向低版本的NameServer注册路由
- 低版本的Broker是否能向高版本的NameServer注册路由
经过rocketmq-console，去建立多个个topic，看看其路由信息是否正确，经验证，符合预期。
2.2.2 客户端与服务端兼容性验证
RocketMQ的客户端API其实比较单一，无非就是消息发送、批量发送，消息消费，因为4.1版本不支持事务消息，此次升级甚至都无需验证事务消息，验证的要点：
- 低版本的客户端是否能正常向高版本Broker发送消息，消费消息
- 高版本的客户端是否能向低版本的Broker发送消息，消费消息
测试案例来自哪，其实都不须要咱们本身写，直接用官方的Demo便可，其代码截图以下： 客户端验证在真正实施过程当中，其实比服务端之间的验证要复杂的多，因为各个项目组使用的客户端版本不一，甚至有些项目组会使用c++、Python等其余非Java客户端，如何精确找到该集群中全部客户端的链接信息(客户端版本、语言类型)相当重要。
官方提供的版本，对消费组的链接信息仍是支持的比较友好，咱们能够经过写脚本，先查询系统中全部的消费组，而后遍历每个消费组，能够查询这些消费组的IP地址、客户端版本、使用的语言等信息，但开源版本对生产者支持的不友好，没有一个可获取全部发送者相关的接口。
获取消费组消费端的链接方式以下图所示： 故咱们采起的方式，主要是基于消费组失败客户端类型，本次升级过程当中，我也对RocketMQ作了一些定制化开发，可方便获取全部发送方的连接信息，后续会已提交PR的方式贡献给官方。
2.2.3 Broker端存储格式验证
因为没有空闲资源，本次要使用的升级方式是直接升级软件，但新老版本共用存储目录，基于RocketMQ的消息存储协议，从4.0.0版本以后就一直没有变化，其验证的关键点以下：
- 4.8.0版本是否能够直接使用4.1.0生成的存储文件(commitlog等文件)
- 4.1.0版本是否能够直接使用4.8.0生成的存储文件
为何须要验证4.1.0版本能兼容4.8.0呢？由于若是升级失败，须要回滚，若是4.1.0版本不能兼容4.8.0的话，会让你没有退路，这在架构设计中是绝对不容许的。
通过验证发现，存储文件是相互兼容的。
2.2.4 测试环境验证
通过上面三步的验证，已经能够进行升级了，但升级以前，还要在测试环境稳定运行一天，能够将测试环境升级成以下架构： 即不一样版本的混搭模式，接受测试环境全部应用服务器的验证，若是测试环境运行没有问题，便可在生产环境进行升级。
2.4 实施方案
有了上面升级方案，而且已经作了充分的验证，是能够在生产环境执行了，在执行以前，须要对理论设计输出可执行可落地的实施方案，实施方案必需要包括回滚操做，而且这个回滚操做必定要比较容易执行，不然你的方案必定是不那么可靠的。
接下来重点阐述一下实施过程当中一些关键步骤，整个升级步骤才有滚动升级，即逐台升级。
一、关闭一个Broker的写权限
关闭Broker写权限，让应用将流量平滑迁移到其余节点，这样能够有效避免在对该机器进行重启时对业务形成的影响。
sh ./mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 4
二、带Broker写入、消费tps接近０时，关闭broker
ps -ef | grep java kill pid
三、使用新版本启动Broker
注意，此过程使用的配置文件为老版本的配置，故此时并无开启写权限，启动并不会对客户端消息写入形成影响。
４、开启写权限
待新版本启动成功后，既能够开启写权限
sh ./mqadmin updateBrokerConfig -b 192.168.xx.xx:10911 -n 192.168.xx.xx:9876 -k brokerPermission -v 6
观察流量。
重复上述步骤便可完成Broker的升级。
关于Nameserver的升级就更加容易了，采用滚动升级，kill掉老版本的nameserver，在原机器上启动新版本的nameserver便可。
三、花絮
最后和你们再分享一个小小的插曲。尽管上面的方案很是详细，而且通过反复的测试，但MQ在咱们公司的重要性实在过重要，运维小伙伴在操做时不敢下手，在操做时他要我在身边看着，这个时候，做为架构师的咱们要勇于承担责任，明确告知，只要你操做正确，出力故障由我来承担，这也是我我的以为做为架构师一个很是重要的软技能：对你负责的技术具备掌控力，而且勇于担当。
好了，本文就介绍到这里了，您的一键三连是对我最大的鼓励，固然能够加笔者微信：dingwpmz，备注CSDN，共同交流探讨。
最后分享笔者一个硬核的RocketMQ电子书，您将得到千亿级消息流转的运维经验。 获取方式：微信搜索【中间件兴趣圈】，回复RMQPDF便可获取。