转载本文请联系中间件兴趣圈公众号。RocketMQ集群的升级方案和实现自然落在了我的头上。这篇文章不仅介绍了作者是如何升级的，还想展示作为架构师处理这些问题的方法论，展示大厂的架构师们。工作常规。温馨提示：关于ACL相关内容，后续文章会分享从4.1.0版本升级到4.8并启用ACL的曲折经历。1.版本升级的紧迫性让人惭愧。作为RocketMQ社区的优秀布道者，笔者所在公司的RocketMQ服务器版本还是4.1.0。RocketMQ在4.4.0之前的版本不支持ACL（AccessControl）。对应生产环境中的任何机器都可以订阅任何主题，在任何生产应用服务器上都可以安装一个rocketmq-console来控制整个集群，并拥有删除主题和消费组的权限。.2.升级方案2.1确定要升级的版本打开RocketMQ升级日志。RocketMQ官方在4.4.0版本引入了ACL机制，所以版本至少要升级到4.4.0。业界使用开源版本有个不成文的规定：一般不要用最新版本，不要当小白鼠。但是RocketMQ可以算是一个特例。仔细浏览RocketMQ的版本变更记录不难发现，与RocketMQClient相关的变更非常少，即与用户密切相关的消息发送和消息消费的代码非常稳定，基本没有理论上没有兼容性问题。而且每个版本都修复了一些重大的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存储目录，也就是直接升级软件。使用旧的配置文件。想法有了，接下来就是验证方案的可行性了。2.3程序验证理论是理论上的。在生产环境中进行任何更改之前，必须进行充分的测试验证。版本升级的重点需要验证兼容性问题。2.2.1服务器版本兼容性验证搭建一个上述的MQ集群，其核心点：高版本Broker是否可以向低版本NameServer注册路由低版本Broker是否可以通过rocketmq向高版本NameServer注册路由-console，创建多个topic，查看它们的路由信息??是否正确，是否经过验证，是否符合预期。2.2.2客户端和服务端兼容性验证RocketMQ的客户端API比较简单，无非就是消息发送、批量发送、消息消费。由于4.1版本不支持交易消息，本次升级甚至不需要验证交易消息。要点：低版本的客户端是否可以正常向高版本的broker发送消息，高版本消费消息的客户端是否可以向低版本的broker发送消息，在哪里消费message测试用例来自，其实不需要我们自己写。可以直接使用官方Demo，代码截图如下：在客户端验证的实际实现过程中，其实比服务器之间的验证要复杂。因为每个项目组使用的客户端版本不同，甚至有的项目组会使用c++、Python等其他非Java客户端。如何准确找到集群中所有客户端的连接信息（客户端版本、语言类型）非常重要。正式版对消费群体的连接信息更加友好。我们可以先写脚本查询系统中所有的消费组，然后遍历每个消费组，查询这些消费组的IP地址和客户端。版本，使用的语言等，但是开源版本对生产者不友好，没有可以获取所有发送者的接口。获取消费组消费端的连接方式如下图所示：所以我们采用的方式主要是根据失败消费组的客户端类型。在这次升级的过程中，我也对RocketMQ做了一些定制化的开发，可以很方便的获取所有发过来的Fang的链接信息，以后会通过提交PR的方式贡献给官方。2.2.3Broker端存储格式验证由于没有空闲资源，本次使用的升级方式是直接升级软件，但是新旧版本共享存储目录，消息存储协议基于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实施方案有了以上升级方案，并做了充分的验证，就可以在生产环境中执行了。在执行之前，需要对理论设计输出一个可执行的实施方案。实施计划必须包括回滚操作，而且这个回滚操作必须是比较容易执行的，否则你的解决方案一定不那么可靠。接下来，我们将重点介绍实现过程中的一些关键步骤。整个升级过程只能进行滚动升级，即逐个升级。1.关闭一个Broker的写权限关闭Broker的写权限，这样应用就可以平滑的把流量迁移到其他节点上，可以有效避免重启机器时对业务的影响。sh./mqadminupdateBrokerConfig-b192.168.x.x:10911-n192.168.xx.xx:9876-kbrokerPermission-v42，带Broker写入，当消费tps接近0时，关闭brokerps-ef|grepjavakillpid3，使用新版本启动Broker注意这个过程中使用的配置文件是老版本的配置，所以此时没有开启写权限，启动不会影响客户端消息的写入。4.启用写入权限。新版本启动成功后，可以开启写权限sh./mqadminupdateBrokerConfig-b192.168.xx.xx:10911-n192.168.xx.xx:9876-kbrokerPermission-v6来观察流量。重复以上步骤完成Broker升级。名称服务器的升级更容易。滚动升级用于杀死旧版本的名称服务器并在原始机器上启动新版本的名称服务器。
