8

【RocketMQ】RocketMQ5.0新特性(一)- Proxy - shanml

 11 months ago
source link: https://www.cnblogs.com/shanml/p/17742136.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

为了向云原生演进,提高资源利用和弹性能力,RocketMQ在5.0进行了架构的调整与升级,先来看新特性之一,增加了Proxy层。

增加Proxy代理层

计算存储分离
计算存储分离是一种分层架构,将计算层与存储层分开。
计算层指的是一些消耗计算资源的功能模块比如协议解析、消费管理等,存储指的是数据存储层,比如数据的存储格式、存储设计等与数据存储相关的功能。

应用通信协议
应用通信协议一般会包含协议头和协议体两部分。
协议头:主要是一些通用的信息,比如协议版本、请求标识、客户端信息等;
协议体:本次通信具体的数据内容,规定了数据的传输格式,比如数据是字符串、JSON格式数据或者二进制数据等;

RocketMQ 5.0以前架构
RocketMQ 5.0以前使用自定义的Remoting协议底层基于Netty进行网络通信,计算存储是一体的,都在Broker中,生产者和消费者从NameServer中拉取到路由信息,之后直接与Broker交互进行消息的生产与消费:

2612945-20230925174004045-190220761.png

存在问题
(1)计算层和存储层都在Broker中,没有进行分离,不利于在云原生环境下实现弹性调度;
(2)Remoting协议是私有协议,每支持一种新的语言,一些基础的工作(比如网络通信、编解码)都需要重新开发,开发和维护成本高;

RocketMQ 5.0架构
5.0以后引入了弹性无状态的代理模式,对Broker的职责进行了拆分,将客户端协议适配、权限管理、消费管理等计算逻辑进行了抽离,放入Proxy层,Broker专注数据的存储,以便更好的适应云原生环境,实现资源弹性调度,并且5.0以后增加了gRPC(Google Remote Procedure Call)协议的支持,它是Google开源的高性能RPC框架,基于Protobuf序列化。

2612945-20230925173922046-1361287033.png

从架构上来看,增加Proxy代理层后,生产者和消费者不再直接与Broker通信,而是与Proxy层通信,Proxy层再与NameServer和Broker交互进行消息的发送和消费,如果需要提高计算层的能力,只需要增加Proxy层,如果需要提高存储层的能力,增加Broker的部署即可。

gRPC协议是公有协议,底层已经实现了网络通信、编解码等基础框架,提供了各个语言的开发库,使用非常轻便,在RocketMQ新增语言支持时可以省去繁杂重复的工作。

部署方式
在5.0版本中分为Local模式和Cluster模式。

  • Local模式:Broker和Proxy同进程部署,在部署时需要在原有的Broker配置上增加Proxy相关的配置,以Local模式运行可以实现与5.0以前版本架构完全一致的效果:

    2612945-20230925180528990-532082949.png
  • Cluster模式:Broker和Proxy是分别独立部署的,是实现存储和计算分离的部署方式:

    2612945-20230925180340877-238710823.png

参考
RocketMQ5.0速览
许文强-深入拆解消息队列 47 讲


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK