RocketMQ 5.0 时代，6 张图带你理解 Proxy！
大家好，我是君哥。今天来聊一聊 RocketMQ 5.0 中的 Proxy。
RocketMQ 5.0 为了更好地拥抱云原生，引入了无状态的 Proxy 模块，新的架构图如下：
引入 Proxy 模块后，Proxy 承担了协议适配、权限管理、消息管理等计算功能，Broker 则更加专注于存储。这样存储和计算相分离，在云原生环境下可以更好地进行资源调度。
1.Proxy 介绍
RocketMQ 5.0 把客户端的部分功能下沉到 Proxy，Proxy 承接了之前 客户端的计算能力，客户端变得更加轻量级。
1.1 NameServer
从上面的架构图可以看到，Producer/Consumer 不再需要注册到 NameServer，这一部分功能下移到了 Proxy，由 Proxy 跟 NameServer 进行交互，比如查询 TopicRouteData。代码如下：
public CompletableFuture queryRoute(ProxyContext ctx, QueryRouteRequest request) {
CompletableFuture future = new CompletableFuture<>();
try {
//省略部分代码
ProxyTopicRouteData proxyTopicRouteData = this.messagingProcessor.getTopicRouteDataForProxy(
ctx, addressList, topicName);
List messageQueueList = new ArrayList<>();
Map> brokerMap = buildBrokerMap(proxyTopicRouteData.getBrokerDatas());
TopicMessageType topicMessageType = messagingProcessor.getMetadataService().getTopicMessageType(topicName);
for (QueueData queueData : proxyTopicRouteData.getQueueDatas()) {
String brokerName = queueData.getBrokerName();
Map brokerIdMap = brokerMap.get(brokerName);
if (brokerIdMap == null) {
break;
}
for (Broker broker : brokerIdMap.values()) {
messageQueueList.addAll(this.genMessageQueueFromQueueData(queueData, request.getTopic(), topicMessageType, broker));
}
}
QueryRouteResponse response = QueryRouteResponse.newBuilder()
.setStatus(ResponseBuilder.getInstance().buildStatus(Code.OK, Code.OK.name()))
.addAllMessageQueues(messageQueueList)
.build();
future.complete(response);
} catch (Throwable t) {
future.completeExceptionally(t);
}
return future;
}
Proxy 适配多种协议，比如 HTTP、gRPC、remoting 等，不同协议的客户端跟 Proxy 建立连接后，Proxy 统一使用 remoting 协议跟 Broker、NameServer 进行通信。
1.2 流量控制
客户端所有的请求都要经过 Proxy，Proxy 将流量分发到 Broker。这样在 Proxy 可以进行流量控制和流量治理。
1.3 POP 模式
我们知道，PUSH 消费模式下，Broker 中的每个 MessageQueue 只能被同一个 Consumer Group 中的一个消费者消费，如下图：
PUSH 模式存在下面几个问题：
-
消费者最大数量只能等于 MessageQueue 的数量，消费者数量等于 MessageQueue 的数量后，再增加消费者，也不能提高消费能力了；
-
客户端的处理逻辑比较多，比如负载均衡、offset 管理、消费失败后的处理（比如失败消息发送回 Broker）；
-
如果一个消费者机器故障，比如上图中 Consumer0 这个消费者 hang 住了，Topic1 下的两个 MessageQueue 就不能被消费了，导致消息积压，最终只能是重启或下线 Consumer0，Consumer 做重平衡；
-
客户端很重，如果要用其他语言编写，工作量很大。
基于 PUSH 模式的不足，RocketMQ 5.0 引入了 POP 消费模式，如下图：
跟 PUSH 模式消费者相比，POP 模式客户端有如下优势：
-
POP 模式消费者可以拉取所有的 MessageQueue，这样即使某个消费者 hang 住，也不会影响某一个 MessageQueue 的消费；
-
POP 模式消费者不再会重平衡，因为每个消费者默认会去所有的 MessageQueue 拉取消息；
-
因为消费者可以拉取所有的 MessageQueue 消息，所以，增加消费者数量，是可以提高消费能力的；
-
消费者减少了很多逻辑，变得户端轻量化了，可以方便多语言实现；
-
消费者不再维护 offset（offset 由 Broker 维护），变成了无状态组件。
注意：消费者请求 Proxy 时，POP 模式和 PUSH 模式都可以使用，而 Proxy 请求 Broker 时，使用的是 POP 模式，这样可以避免上面提到的一系列问题。如下图：
1.4 gRPC
Proxy 基于 gRPC 的标准性、兼容性和多语言传输层代码生成能力，可以轻松构建多语言的轻量级客户端。
2 部署方式
根据不同的场景，Proxy 有两种部署方式，LOCAL 模式和 CLUSTER 模式。
2.1 LOCAL 模式
RocketMQ 4.x 版本 Client 和 Broker 直接通信，RocketMQ 5.0 引入 Proxy 后，Client 和 Broker 之间的通信多了一道网络，也增加了一次序列化和反序列化的过程，这势必增加了延迟，对于延迟敏感的场景可能不能接受。RocketMQ 5.0 引入了 LOCAL 模式部署 Proxy，如下图：
Proxy 仍然可以适配多种语言的客户端，而且 Proxy 和 Broker 部署在一起，通信方式使用进程内通信，这样可以减少因为多一道网络带来的延迟，提高吞吐量。同时运维也变得简单，运维成本降低。
LOCAL 模式有一个缺点，因为 Proxy 部署在 Broker 端，受网络环境的限制，对于多网络接入的情况并不友好，成本高。
2.2 CLUSTER 模式
CLUSTER 模式主要用于对延迟不敏感的场景，Proxy 独立部署，在 Proxy 层适配多网络的接入，同时 Proxy 和 Broker 可以独立扩容，互不影响。如下图：
2.3 总结
LOCAL 模式更适合对延迟敏感、期望运维成本低、网络接入类型单一的场景。
CLUSTER 模式更适合对延迟要求低、网络接入类型多样的场景。
3 总结
RocketMQ 5.0 跟之前的版本相比，改动很大，更加地拥抱云原生。学习 RocketMQ 5.0，首先要理解 Proxy，希望本文能对您理解 Proxy 有所帮助。