《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、两个进程塞到同一台机器上