为了向云原生演进，提高资源利用和弹性能力，RocketMQ在5.0进行了架构的调整与升级，先来看新特性之一，增加了Proxy层。
计算存储分离
计算存储分离是一种分层架构，将计算层与存储层分开。
计算层指的是一些消耗计算资源的功能模块比如协议解析、消费管理等，存储指的是数据存储层，比如数据的存储格式、存储设计等与数据存储相关的功能。
应用通信协议
应用通信协议一般会包含协议头和协议体两部分。
协议头：主要是一些通用的信息，比如协议版本、请求标识、客户端信息等；
协议体：本次通信具体的数据内容，规定了数据的传输格式，比如数据是字符串、JSON格式数据或者二进制数据等；
RocketMQ 5.0以前架构
RocketMQ 5.0以前使用自定义的Remoting协议底层基于Netty进行网络通信，计算存储是一体的，都在Broker中，生产者和消费者从NameServer中拉取到路由信息，之后直接与Broker交互进行消息的生产与消费：
存在问题
（1）计算层和存储层都在Broker中，没有进行分离，不利于在云原生环境下实现弹性调度；
（2）Remoting协议是私有协议，每支持一种新的语言，一些基础的工作（比如网络通信、编解码）都需要重新开发，开发和维护成本高；
RocketMQ 5.0架构
5.0以后引入了弹性无状态的代理模式，对Broker的职责进行了拆分，将客户端协议适配、权限管理、消费管理等计算逻辑进行了抽离，放入Proxy层，Broker专注数据的存储，以便更好的适应云原生环境，实现资源弹性调度，并且5.0以后增加了gRPC（Google Remote Procedure Call）协议的支持，它是Google开源的高性能RPC框架，基于Protobuf序列化。
从架构上来看，增加Proxy代理层后，生产者和消费者不再直接与Broker通信，而是与Proxy层通信，Proxy层再与NameServer和Broker交互进行消息的发送和消费，如果需要提高计算层的能力，只需要增加Proxy层，如果需要提高存储层的能力，增加Broker的部署即可。
gRPC协议是公有协议，底层已经实现了网络通信、编解码等基础框架，提供了各个语言的开发库，使用非常轻便，在RocketMQ新增语言支持时可以省去繁杂重复的工作。
部署方式
在5.0版本中分为Local模式和Cluster模式。
Local模式：Broker和Proxy同进程部署，在部署时需要在原有的Broker配置上增加Proxy相关的配置，以Local模式运行可以实现与5.0以前版本架构完全一致的效果：
Cluster模式：Broker和Proxy是分别独立部署的，是实现存储和计算分离的部署方式：
