# Protobuf vs JSON：为什么 IM 系统选择二进制协议？
在 IM 系统中，消息序列化协议的选择直接影响性能和用户体验，本文对比 Protobuf 与 JSON，并说明为什么选择 Protobuf。

## 一、为什么需要关注序列化协议？
在 IM 系统中，每条消息都需要序列化后通过网络传输。假设系统每秒处理 1 万条消息：
* 如果每条消息序列化耗时 1ms，每秒会消耗 10 秒 CPU 时间
* 如果每条消息体积 1KB，每秒需要传输 10MB 数据

在高并发场景下，序列化协议的选择会显著影响系统性能。

## 二、Protobuf vs JSON：性能对比
### 1.体积对比
**JSON 格式示例：**
```json
{
  "msgId": "msg_1234567890",
  "roomId": "room_abc123",
  "userId": "user_xyz789",
  "msgType": 0,
  "msg": "这是一条测试消息",
  "ext": ""
}
```
**体积：** 约 150 字节（包含字段名、引号、逗号等）

**Protobuf 格式示例：**
```protobuf
message SendMsgCmd {
  string msgId = 1;
  string roomId = 2;
  int32 msgType = 3;
  string msg = 4;
  string ext = 5;
}
```
**体积：** 约 50-80 字节（二进制格式，无字段名）

**对比结果：**
* JSON：150 字节
* Protobuf：50-80 字节
* 体积减少：30-50%

### 2.序列化/反序列化性能对比
**测试代码**
```java
// JSON 序列化
String json = JSONObject.toJSONString(messageDto);
byte[] jsonBytes = json.getBytes(StandardCharsets.UTF_8);

// Protobuf 序列化
byte[] protoBytes = sendMsgCmd.toByteArray();
```

**性能测试结果**（基于 AQChat 项目的实际测试）：
| 操作 | JSON | Protobuf | 性能提升 |
|------|------|------|--------|
| 序列化 | 0.5ms | 0.1ms | 5倍 |
| 反序列化 | 0.6ms | 0.15ms | 4倍 |
| 消息体积 | 150字节 | 60字节 | 60% 减少 |

**实际效果：**
* 响应时间：从 50ms 降到 < 10ms（序列化性能提升重要因素之一）
* 带宽节省：10 万并发用户，每秒节省约 9MB 贷款
* CPU 使用：序列化 CPU 时间减少 80%

## 三、Protubuf 向后兼容性
### 1.字段扩展
场景：需要在消息中新增字段，但不影响旧版本客户端。

**JSON 方案**：
```json
// 旧版本
{"msgId": "123", "msg": "hello"}

// 新版本（新增 userId 字段）
{"msgId": "123", "msg": "hello", "userId": "user_123"}
```
问题：旧版本客户端解析新版本消息时，可能因为未知字段出错。

**Protobuf 方案**：
```protobuf
// 旧版本
message SendMsgCmd {
  string msgId = 1;
  string msg = 2;
}

// 新版本（新增 userId 字段，编号 3）
message SendMsgCmd {
  string msgId = 1;
  string msg = 2;
  string userId = 3;  // 新增字段，编号不能重复
}
```
优势：
* 旧版本客户端可以正常解析（忽略未知字段）
* 新版本客户端可以读取新字段
* 字段编号一旦使用，不能修改（保证兼容性）

### 3.实际案例
在 AQChat 项目中，消息协议经历了多次扩展：
```protobuf
// 最初版本
message SendMsgCmd {
  string msgId = 1;
  string roomId = 2;
  string msg = 3;
}

// 扩展版本（新增 msgType 和 ext 字段）
message SendMsgCmd {
  string msgId = 1;
  string roomId = 2;
  MsgType msgType = 3;  // 新增：消息类型
  string msg = 4;
  string ext = 5;  // 新增：扩展字段
}
```
旧版本客户端仍可以正常解析，只是无法读取新字段，保证了向后兼容。

## 四、消息识别器的设计思路
### 1.问题：如何根据指令编号设计消息类型？
在自定义协议中，消息格式是：`消息长度（4 字节）+ 消息指令（2 字节）+ Protobuf消息体`
解码时，如何根据指令编号（如 10）获取对应的 Protobuf Builder？

### 2.解决方案：反射机制自动映射
**核心思路**：
* 通过反射扫描 Protobuf 协议中的所有消息类型
* 通过类名匹配消息指令枚举
* 自动建立双向映射关系

**代码实现**：
```java
@Component
public class MessageRecognizer implements InitializingBean {
    
    // 指令编号 -> 消息实例的映射（用于解码）
    private final Map<Integer, GeneratedMessageV3> msgCommandAndMsgBodyMap = new HashMap<>();
    
    // 消息类型 -> 指令编号的映射（用于编码）
    private final Map<Class<?>, Integer> msgClazzAndMsgCommandMap = new HashMap<>();
    
    public void init() {
        // 1. 获取 Protobuf 协议文件中的所有内部类
        Class<?>[] innerClazzArray = AQChatMsgProtocol.class.getDeclaredClasses();
        
        for (Class<?> innerClazz : innerClazzArray) {
            // 2. 过滤出消息类型（继承自 GeneratedMessageV3）
            if (!GeneratedMessageV3.class.isAssignableFrom(innerClazz)) {
                continue;
            }
            
            // 3. 获取类名并转换为小写（去掉下划线）
            String clazzName = innerClazz.getSimpleName().toLowerCase();
            // 例如：UserLoginCmd -> userlogincmd
            
            // 4. 遍历消息指令枚举，匹配类名
            for (AQChatMsgProtocol.MsgCommand msgCommand : AQChatMsgProtocol.MsgCommand.values()) {
                String strMsgCode = msgCommand.name().replaceAll("_", "").toLowerCase();
                // 例如：USER_LOGIN_CMD -> userlogincmd
                
                // 5. 类名匹配指令名
                if (strMsgCode.equals(clazzName)) {
                    try {
                        // 6. 通过反射调用 getDefaultInstance() 获取默认实例
                        Object returnObj = innerClazz.getDeclaredMethod("getDefaultInstance")
                            .invoke(innerClazz);
                        
                        // 7. 建立双向映射
                        msgCommandAndMsgBodyMap.put(msgCommand.getNumber(), (GeneratedMessageV3) returnObj);
                        msgClazzAndMsgCommandMap.put(innerClazz, msgCommand.getNumber());
                        
                        LOGGER.info("消息识别器初始化: {} => {}", innerClazz.getName(), msgCommand.getNumber());
                    } catch (Exception ex) {
                        LOGGER.error(ex.getMessage(), ex);
                    }
                }
            }
        }
    }
    
    // 解码时：根据指令编号获取 Builder
    public Message.Builder getMsgBuilderByMsgCommand(int msgCommand) {
        GeneratedMessageV3 msg = msgCommandAndMsgBodyMap.get(msgCommand);
        if (msg == null) {
            return null;
        }
        return msg.newBuilderForType();
    }
    
    // 编码时：根据消息类型获取指令编号
    public int getMsgCommandByMsgClazz(Class<?> msgClazz) {
        Integer command = msgClazzAndMsgCommandMap.get(msgClazz);
        return command == null ? -1 : command;
    }
}
```

### 3.命名规则
为了保证自动映射，需要遵循命名规则：
**消息类型命名**：
* 请求消息：`XxxCmd`（如 `UserLoginCmd`）
* 响应消息：`XxxAck`（如 `UserLoginAck`）
* 通知消息：`XxxNotify`（如 `JoinRoomNotify`）

**消息指令枚举**：
* 请求指令：`XXX_CMD`（如 `USER_LOGIN_CMD`）
* 响应指令：`XXX_ACK`（如 `USER_LOGIN_ACK`）
* 通知指令：`XXX_NOTIFY`（如 `JOIN_ROOM_NOTIFY`）

**匹配规则**：
* 去掉下划线和大小写，进行匹配
* UserLoginCmd ↔ `USER_LOGIN_CMD`
* JoinRoomNotify ↔ `JOIN_ROOM_NOTIFY`

### 4.优势
1.自动映射：新增消息类型时，只需要在 `.protobuf` 文件中定义，无需手动维护映射关系
2.类型安全：编译时检查，避免运行时错误
3.易于维护：映射关系自动生成，减少人工错误

## 如何从 JSON 迁移到 Protobuf
### 1.迁移步骤
第一步：定义 Protobuf 协议文件
```protobuf
// AQChatMsgProtocol.proto
syntax="proto3";

package chat_msg;
option java_package = "com.howcode.aqchat.message";

enum MsgCommand{
  USER_LOGIN_CMD = 0;
  USER_LOGIN_ACK = 1;
  SEND_MSG_CMD = 10;
  SEND_MSG_ACK = 11;
  // ... 更多指令
}

message UserLoginCmd{
  string userName = 1;
  string userAvatar = 2;
}

message SendMsgCmd{
  string msgId = 1;
  string roomId = 2;
  int32 msgType = 3;
  string msg = 4;
  string ext = 5;
}
```
第二步：编译生成 Java 类
```
# 使用 protoc 编译器
protoc --java_out=src/main/java AQChatMsgProtocol.proto
```
第三步：实现编解码器
```java
// 编码器
public class MessageEncoder extends MessageToMessageEncoder<GeneratedMessageV3> {
    @Override
    protected void encode(ChannelHandlerContext ctx, GeneratedMessageV3 msg, List<Object> list) {
        // 1. 获取消息指令编号
        int msgCommand = recognizer.getMsgCommandByMsgClazz(msg.getClass());
        
        // 2. 序列化为字节数组
        byte[] msgBody = msg.toByteArray();
        
        // 3. 写入协议头部
        ByteBuf byteBuf = ctx.alloc().buffer();
        byteBuf.writeInt(msgBody.length);  // 消息长度
        byteBuf.writeShort((short) msgCommand);  // 消息指令
        byteBuf.writeBytes(msgBody);  // 消息体
        
        list.add(new BinaryWebSocketFrame(byteBuf));
    }
}

// 解码器
public class MessageDecoder extends MessageToMessageDecoder<BinaryWebSocketFrame> {
    @Override
    protected void decode(ChannelHandlerContext ctx, BinaryWebSocketFrame msg, List<Object> list) {
        ByteBuf byteBuf = msg.content();
        
        // 1. 读取消息长度和指令
        int msgLength = byteBuf.readInt();
        short command = byteBuf.readShort();
        
        // 2. 根据指令获取对应的 Builder
        Message.Builder builder = recognizer.getMsgBuilderByMsgCommand(command);
        
        // 3. 读取消息体并反序列化
        byte[] msgBody = new byte[msgLength];
        byteBuf.readBytes(msgBody);
        builder.mergeFrom(msgBody);
        
        list.add(builder.build());
    }
}
```
第四步：修改业务代码
```java
// 原来的 JSON 方式
String json = JSONObject.toJSONString(messageDto);
ctx.writeAndFlush(json);

// 改为 Protobuf 方式
AQChatMsgProtocol.SendMsgCmd cmd = AQChatMsgProtocol.SendMsgCmd.newBuilder()
    .setMsgId(messageDto.getMessageId())
    .setRoomId(messageDto.getRoomId())
    .setMsgType(messageDto.getMessageType())
    .setMsg(messageDto.getMessageContent())
    .build();
ctx.writeAndFlush(cmd);
```

### 2.迁移注意事项
**1.字段类型映射**
| **JSON 类型** | **Protobuf 类型** | **说明** |
|---------------|------------------|----------|
| string | string | 字符串 |
| number | int32/int64 | 整数 |
| boolean | bool | 布尔值 |
| array | repeated | 数组 |
| object | message | 对象 |

**2.默认值处理**
Protobuf 的默认值：
* string：空字符串 `""`
* int32/int64：`0`
* bool：`false`
* repeated：空列表

JSON 中可能没有这些默认字段，需要特殊处理

### 3.版本兼容
迁移时建议：
* 先支持双协议（JSON 和 Protobuf）
* 逐步迁移客户端到 Protobuf
* 最后完全切换到 Protobuf

## 六、Protobuf 的其他优势
### 1.类型安全
**JSON 的问题**：
```json
{
  "msgType": "0",  // 字符串类型，容易出错
  "roomId": 12345  // 数字类型，应该是字符串
}
```
**Protobuf 的优势**
```protobuf
message SendMsgCmd {
  int32 msgType = 3;  // 编译时检查类型
  string roomId = 2;  // 类型明确
}
```
编译时检查类型，避免运行时错误

### 2.代码生成
Protobuf 自动生成 Java 类，包含：
* Builder 模式：链式调用，代码简洁
* 序列化/反序列化方法：`toByteArray`、`mergeFrom`
* 字段访问器：`getMsgId()`、`setMsgId()`

### 3.跨语言支持
Protobuf 支持多种语言：
* Java、C++、Python、JavaScript 等
* 同一份 `.proto` 文件可以生成不同语言的代码
* 便于多语言系统集成

## 七、Protobuf 的局限性
### 1.可读性差
* JSON：人类可读，便于调试
* Protobuf：二进制格式，不可读
**解决方法**：开发时使用 JSON，生产环境使用 Protobuf。

### 2.需要编译
* JSON：无需编译，直接使用
* Protobuf：需要编译 `.proto` 文件生成代码
**解决方法**：使用 Maven/Gradle 插件自动编译。

### 3.学习成本
* JSON：简单直接
* Protobuf：需要学习 `.proto` 语法
解决方案：`.proto` 语法简单，学习成本低。

## 八、实际应用效果
在 AQChat 项目中，使用 Protobuf 后的效果：
### 1. 性能提升
* 响应时间：从 50ms 降到 < 10ms（序列化性能提升是重要因素）
* 带宽节省：消息体积减少 30-50%，节省带宽
* CPU 使用：序列化 CPU 时间减少 80%

### 2. 代码质量
* 类型安全：编译时检查，减少运行时错误
* 代码生成：自动生成代码，减少手写代码
* 易于维护：协议定义集中，便于管理

### 3. 扩展性
* 向后兼容：支持字段扩展，不影响旧版本
* 跨语言：支持多语言，便于系统集成

## 九、总结
Protobuf 相比 JSON 的优势：

1.性能：体积小 30-50%，序列化速度快 3-5 倍

2.类型安全：编译时检查，避免运行时错误

3.向后兼容：支持字段扩展，不影响旧版本

4.代码生成：自动生成代码，减少手写代码

在 IM 系统这种高并发、低延迟的场景下，Protobuf 是更好的选择。虽然 JSON 更易读、更简单，但在性能要求高的场景下，Protobuf 的优势更明显。

**选择建议**：
* 高并发、低延迟场景：选择 Protobuf
* 简单场景、可读性要求高：选择 JSON
* 需要跨语言集成：选择 Protobuf

在 AQChat 项目中，使用 Protobuf 后，系统性能显著提升，证明了二进制协议在高并发场景下的优势。

在 IM 系统中，消息序列化协议的选择直接影响性能和用户体验，本文对比 Protobuf 与 JSON，并说明为什么选择 Protobuf。

Protobuf vs JSON：为什么 IM 系统选择二进制协议？

后端

编程语言

网络与通信

IM系统为何选择Protobuf而非JSON？二进制协议体积缩小30-50%，序列化速度提升3-5倍，显著降低带宽消耗和CPU使用率。Protobuf具备类型安全、向后兼容等优势，特别适合高并发场景，使IM系统响应时间从50ms降至10ms以下，大幅提升用户体验。

性能测试

编译器

Python

JSON

Java

腾讯云 IM，全球通信，1折起


5位重磅专家聚焦 AI 时代开发者核心成长需求，带你深入解锁全栈进化、人机协作关键路径！点击报名到场：<a href="https://cloud.tencent.com/developer/salon/salon-2403/signup" target="_blank">https://cloud.tencent.com/developer/salon/salon-2403/signup</a><br/> 
 <img src="https://qcloudimg.tencent-cloud.cn/raw/487c82639d2338df3ef66dfb1450601a.png"/>

腾讯技术创作特训营「年度论坛」正在报名中！

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Protobuf vs JSON：为什么 IM 系统选择二进制协议？-腾讯云开发者社区-腾讯云

Protobuf vs JSON：为什么 IM 系统选择二进制协议？

Protobuf vs JSON：为什么 IM 系统选择二进制协议？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐