本文介绍了Apache RocketMQ 5.0的新架构，强调了SDK的全面异步化和可观测性的增强。新架构中，网络拓扑模型更新，使用gRPC代替RemotingCommand协议。SDK实现了全链路异步化，通过Future统一同步和异步API。此外，增强了可观测性，包括全链路Tracing、Metrics和Logging。Tracing采用了OpenTelemetry标准，Metrics提供了多维度监控，Logging遵循了规范化的日志级别。新SDK还简化了消费模型，提升了兼容性，并确保了高质量的测试覆盖。
作者 | 凌楚
引言
长久以来，RocketMQ 易于部署、高性能、高可用的架构，支撑了数十年来集团内外海量的业务场景。时至今日，为了迎接如今云原生时代的新挑战，我们重磅推出了 RocketMQ 5.0 新架构。
在 5.0 新架构中，我们更新了整个 RocketMQ 的网络拓扑模型，着眼于将更上层的业务逻辑从 broker 中剥离到无状态的 proxy ，这样独立的计算节点可以无损地承担日后的升级发布任务，与此同时将 broker 解放出来承担纯粹的存储任务，为未来打造更强的消息存储引擎做好铺垫。通信层方面，出于标准化，多语言的考虑我们摒弃了 RocketMQ 使用多年的 RemotingCommand 协议，采用了 gRPC 来实现客户端与服务端之间的通信逻辑。
针对于用户侧，我们希望尽可能少的叨扰客户进行升级，维持逻辑轻量，易于维护，可观测性良好，能够可以达到“一次性把事情做对”。
目前，保证了接口完全兼容的，基于 RocketMQ 5.0 的商业化版本 Java SDK 已经在公有云 release 完成，开源版本也即将 release。SDK 将同时支持云上 proxy 架构的云上版本和开源版本的 Broker。下面将展开叙述 RocketMQ 5.0 新架构下的 SDK 做了哪些迭代与演进。
全面异步化
1、异步的初衷
由于涉及诸多的网络 IO，因此 RocketMQ 对消息发送开放了同步和异步两套 API 提供给用户使用。旧有架构从 API 针对于同步和异步维护了两套类似的业务逻辑，非常不利于迭代。考虑到这一点，此次新架构 SDK 希望在底层就可以将它们统一起来。
以消息发送为例，一个完整的消息发送链路包括获取：
- 获取 topic 对应的路由；
- 根据路由选择对应的分区；
- 发送消息到指定的分区，如果发送到该分区失败，则对下一个分区进行发送重试直到达到最大重试次数；如果发送成功，则返回发送结果。
其中从远端获取 topic 对应的路由是一个重 IO 操作，而发送消息本身也是一个重 IO 操作。在以往的发送实现中，即使是异步发送，对于路由的获取也是同步的，路由的获取本身并没有计入用户的发送耗时中，用户本身是可以自主设置消息发送的超时时间的，而由于本身消息的发送是同步的，无法做到超时时间的精准控制，而在使用异步 Future 之后，可以非常方便地通过控制 Future 的超时时间来做到。
2、异步统一所有实现
本质上 RocketMQ 里所有的重 IO 操作都可以通过异步来进行统一。得益于 gRPC 本身提供了基于 Future 的 stub，我们将网络层的 Future 一层层串联到最终的业务层。当用户需要同步 API 时，则进行同步等待；当用户需要异步 API 时，则在最外层的 Future 添加回调进行监听。
实际上基于 Future 设计的思想是贯穿整个客户端实现的。譬如，消息消费也是通过唯一的基于 Future 的实现来完成的：
/** * Deliver message to listener. * * @param messageExtList message list to consume * @param delay message consumption delay time * @param timeUnit delay time unit. * @return future which contains the consume status. */public ListenableFuture consume(List messageExtList, long delay, TimeUnit timeUnit) { // Omit the implement}
针对于顺序消息消费失败这种需要本地 suspend 一段时间重新投递的情况，消费接口增加了延时参数。然而无论是普通消息还是顺序消息，都只会返回含有消费状态的 Future 。上层再针对含有消费状态的 Future 来进行消息的 A
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
