為了向雲原生演進，提高資源利用和彈性能力，RocketMQ在5.0進行了架構的調整與升級，先來看新特性之一，增加了Proxy層。 增加Proxy代理層 計算存儲分離 計算存儲分離是一種分層架構，將計算層與存儲層分開。 計算層指的是一些消耗計算資源的功能模塊比如協議解析、消費管理等，存儲指的是數據存儲 ...
為了向雲原生演進，提高資源利用和彈性能力，RocketMQ在5.0進行了架構的調整與升級，先來看新特性之一，增加了Proxy層。
增加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是分別獨立部署的，是實現存儲和計算分離的部署方式：
參考
RocketMQ5.0速覽
許文強-深入拆解消息隊列 47 講
