RocketMq Remoting协议 与 gRPC协议

RocketMQ 项目自诞生之初演进到当前5.x版本，根据底层通信协议的差异主要支持两个系列的客户端SDK，分别是Remoting协议和gRPC协议。

Remoting 协议作为早期组件间默认通信协议，内置的客户端SDK一直和主仓库同步演进和迭代。Remoting 协议 SDK 一直以绑定仓库的方式伴随服务端代码版本迭代，主要支持Java为主的语言。

gRPC 协议自 5.0 版本全新推出，旨在以云原生主流技术演进更加轻量、标准、易扩展的客户端服务端通信协议。gRPC 协议 SDK 是以独立仓库 RocketMQ Clients 方式演进，支持Java/C++/.NET/Go/Rust等语言。客户端和服务端之间相对解耦，遵循 RocketMQ API 协议接口约定。

对比项	Remoting 协议 SDK	gRPC 协议 SDK
多语言支持	Java为主，其他语言为第三方仓库实现	Java/C/C++/.NET/Go/Rust
接口范围	Producer PushConsumer PullConsumer LitePullConsumer Admin	Producer PushConsumer（仅Java） SimpleConsumer PullConsumer（进行中）
兼容版本	兼容4.x、5.x版本服务端	仅支持5.x 版本服务端
演进方向	Remoting协议主要作为服务端内部组件通信演进	gRPC协议作为轻量化多语言客户端首选，后续逐步推广补齐所有能力

1. gRPC 协议 SDK 优势与不足

优势：

接口简洁性更好，易理解，不易错误使用。

接口确定性设计更完善，参数、异常类型明确。

接口不可变性设计，避免透传、漏传参数和信息导致的业务异常。

多语言支持更完善，由于gRPC协议的多语言优势，可以更低成本演进出行为一致的多语言sdk。 详细的设计思考和演进方向，参考RIP-37: New and Unified APIs 和 RIP-39: Support gRPC protocol。

不足：

未做老版本兼容，老版本升级成本>>新开发项目（数据迁移，BUG修复）；

SDK封装不够完善（没找到 对应的 xx-boot-starter）。

2. 源码地址

2.1 Remoting

https://github.com/apache/rocketmq

2.2 gRPC

https://github.com/apache/rocketmq-clients

3.maven依赖

3.1 Remoting boot-stater

<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>2.2.3</version>
</dependency>

3.2 Remoting client

<!-- https://mvnrepository.com/artifact/org.apache.rocketmq/rocketmq-client -->
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>5.1.4</version>
</dependency>

3.3 gRPC client

<!-- https://mvnrepository.com/artifact/org.apache.rocketmq/rocketmq-client-apis -->
<dependency>
	<groupId>org.apache.rocketmq</groupId>
	<artifactId>rocketmq-client-java</artifactId>
	<version>5.0.5</version>
</dependency>

4.开发选择（个人意见）

4.1 目前使用5.0-版本

4.1.1 工作压力大且项目稳定

建议使用使用继续使用Remoting 协议 SDK，平滑兼容性升级。

4.1.2 工作压力小或项目不稳定

建议使用 gRPC 协议 SDK，收益可能大于支出（gRPC 协议 SDK 简洁易于理解）。

4.2 目前使用5.0+版本

建议使用 gRPC 协议 SDK，5.0后的 RocketMq 更加规范，部分新特性Remoting 协议 SDK 暂未支持。

官方文档-概览