为了向云原生演进，提高资源利用和弹性能力，RocketMQ在5.0进行了架构的调整与升级。
Proxy代理层
RocketMQ5.0以前架构:
RocketMQ5.0以前使用自定义的Remoting协议底层基于Netty进行网络通信，计算存储是一体的，都在Broker中。
生产者和消费者从NameServer中拉取到路由信息，之后直接与Broker交互进行消息的生产与消费。
图片
RocketMQ5.0架构：
5.0以后引入了弹性无状态的代理模式，对Broker的职责进行了拆分。
将客户端协议适配、权限管理、消费管理等计算逻辑进行了抽离，放入Proxy层，Broker专注数据的存储。
- 以便更好的适应云原生环境，实现资源弹性调度。
并且5.0以后增加了GRPC协议的支持。
- 它是Google开源的高性能RPC框架，基于Protobuf序列化。
图片
POP消费模式
RocketMQ5.0之前：
消费有两种方式可以从Broker获取消息，分别为Pull模式和Push模式。
Pull模式：
消费需要不断的从阻塞队列中获取数据，如果没有数据就等待，这个阻塞队列中的数据由消息拉取线程从Broker拉取消息之后加入的。
所以Pull模式下消费需要不断主动从Broker拉取消息。
Push模式：
需要注册消息监听器，当有消息到达时会通过回调函数进行消息消费，从表面上看就像是Broker主动推送给消费者一样，所以叫做推模式。
底层依旧是消费者从Broker拉取数据然后触发回调函数进行消息消费，只不过不需要像Pull模式一样不断判断是否有消息到来。
RocketMQ5.0
将负载均衡、消费位点管理等功能放到了Broker端，减少客户端的负担，使其变得轻量级，并且5.0之后支持消息粒度的负载均衡。
消息粒度负载均衡:
消息粒度负载均衡策略中，同一消费组内的多个消费者将按照消息粒度平均分摊主题中的所有消息。
- 即同一个队列中的消息，可被平均分配给组内多个消费者共同消费。
POP消息消费：
首先客户端（消费者）向服务端（Broker）发送Pop请求，Broker端收到请求后以Pop模式获取消息，之后返回给客户端。
客户端消费消息成功之后，向Broker发送ACK请求确认消息消费成功。
图片
Controller模式
在RocketMQ5.0以前，有两种集群部署模式，分别为主从模式（Master-Slave模式）和Dledger模式。
RocketMQ5.0以后推出了Controller模式，它的特点如下：
在主从部署模式下就具有自动切换Master的能力，5.0之前需要使用DLedger才可以。
可以利用RocketMQ原生存储复制能力，并统一RocketMQ的存储和复制能力。
RocketMQ5.0对Broker选主相关的功能进行了抽离，放在Controller中。
实现了在主从部署模式下就可以自动切换Master，Controller可以独立部署也可以嵌入在NameServer中部署。
独立部署下的Controller：
图片
嵌入NameServer中的部署图如下：
图片
参考：
https://rocketmq.apache.org/version/
https://developer.aliyun.com/article/801815
https://rocketmq.apache.org/zh/docs/deploymentOperations/03autofailover/
