《RocketMQ 5.0: 存储计算分离新思路》笔记
rocketmq官微发布了一篇RocketMQ 5.0: 存储计算分离新思路的文章,讲述了5.0以及后续版本的改造方向,核心就是存储计算分离,使得存储模块和计算模块互不干扰,能各自进行扩缩容。更加云原生 😃
文中对现有问题和新架构能解决哪些问题都做了解释,感觉受益匪浅,于是做下笔记,加深理解。
建议看原文,因为笔记只记录了理解的部分,看不懂的部分都用…省略。
痛点
富客户端
所谓富客户端,就是客户端SDK集成功能很多,很重。目前rocketmq SDK干的活包括:顺序、广播消费,消费者负责均衡,重试,流控等等
这就有以下弊端
-
修改(或者是bug fix)上述功能中的一个时成本很高,因为需要让用户升级SDK版本,用户升级SDK需要修改业务代码的依赖文件(比如go.mod)、编译、CR&合并到主分支、上线… 如果SDK用户广泛(比如整个集团都在用),推动业务升级成本会极高
-
难以与service mash、dapr等云原生概念配合
-
高质量的多语言客户端维护成本高
…
计算存储一体化
目前rocketmq的Broker计算存储啥都干
-
计算:管理客户端连接、鉴权、编解码…
-
存储:基于分区的WAL存储、索引、多副本复制…
这种一体化的结构利于部署、运维,但也有弊端:
-
迭代效率低 & 稳定性风险:据维护团队统计,一般的功能迭代都是“计算”部分,存储部分很少涉及,所以一次“计算”的小改动需要上线整个Broker集群,迭代效率不高并且会有稳定性风险
-
资源利用率低:计算、存储有各自的IO、CPU资源的需求特点。当一体化的情况下,当扩缩容只能一起进行扩缩,整体资源利用率不如计算存储分离
…
客户端与Broker直连
我理解客户端与Broker直连带来运维的成本比较痛
-
直接暴露所有Broker,很多Broker运维操作都会让用户感知
-
Broker向外暴露是需要VIP的,但VIP申请、运维成本都相对比较高
…
存储计算分离架构
在现有的基础上引入一个“无状态”的Proxy模块来承担“计算”的职责,原有的“Broker”逐渐退化为专注于“高性能存储”的模块,同时引入一批基于gRPC的瘦客户端。
新架构借用service mesh中控制面、数据面以及xDS的概念来描述
什么是xDS:xDS · Istio Handbook - Istio 服务网格进阶实战 by ServiceMesher(服务网格社区)
官方新架构图:
组件解释
-
Navigation Server:通过LB Group面向客户端,提供Proxy接入点信息,同时使用EDS持续暴露Proxy接入点信息,通过EDS暴露比传统的DNS暴露会更智能、更容易精确进行多租户管理
-
NameServer:是原有的核心组件,之前是直接面向客户端,维护Topic、Consumer、Provider等信息;新架构中他不再直接面向客户端,其新职责是给Proxy提供Broker集群、Topic的路由发现服务
-
Proxy:新架构引入的无状态计算模块,承担鉴权、消息编解码、流控、客户端连接、资源计量等“计算“功能
-
Broker:独立为专门的存储节点,其计算的功能会慢慢迁移到Proxy
专注提供极具竞争力的高性能、低延迟的存储服务
-
多语言瘦客户端:之前是rocketmq专有协议,新客户端基于gRPC协议
其他
-
计算存储分离带来的成本
-
延迟增大:之前是客户端直连Broker,现在把Broker拆成Proxy和Broker了,多了一次调用,会增加网络的时间。但文章中说在阿里云上就算是跨AZ的通信,也只是在2ms以内,大部分业务可以接受
-
机器成本:Proxy和Broker分开部署势必会增加机器数量,但文章中的意思是分开部署会提高资源利用率,利用云的弹性能力,资源反而会降低(存疑…)
-
-
为了一体化架构”开箱即用、易于部署“等等其他优点,新架构的rocketmq还要支持”合并部署“,但编程上还是”计算“、”存储“两个模块,部署时也是两个进程,至于什么方式,用户可以自行选择:计算节点作为存储节点的sidecar、两个进程塞到同一台机器上