Apache Fury 与 Protobuf 对象序列化性能对比分析

Apache Fury 作为一款高性能的序列化框架，在实际应用中常被拿来与 Protobuf 进行性能对比。本文针对 Java 环境下 Protobuf 生成对象的序列化场景，深入分析 Fury 与原生 Protobuf 的性能差异及其技术原因。

问题背景

在搜索推荐系统的模型推理场景中，开发者需要将 Java POJO 转换为 Protobuf 对象后进行序列化传输。测试发现：

1. 直接序列化 POJO 时，Fury 产生的数据体积明显大于 Protobuf
2. 序列化 Protobuf 生成对象时，Fury(23ms)略慢于原生 Protobuf(20ms)

技术分析

Protobuf 对象的特殊性

Protobuf 生成的 Java 类具有以下特点：

1. 包含大量内部状态字段（如 memoizedHashCode、bitField0_等）
2. 实现了 writeReplace 方法（JDK 序列化机制）
3. 使用 WeakHashMap 等特殊数据结构
4. 存在循环引用关系

这些特性使得 Protobuf 对象：

• 专为 Protobuf 自身序列化优化
• 不适用于通用序列化框架
• 包含大量冗余字段（仅对 Protobuf 有意义）

Fury 的兼容性处理

当 Fury 序列化 Protobuf 对象时：

1. 默认会调用 writeReplace 方法保持兼容性
2. 实际执行的是 Protobuf 自身的序列化逻辑
3. 额外增加了 Fury 的封装开销

性能优化建议

对于必须使用 Protobuf 对象的场景：

1. 配置优化：

Fury fury = Fury.builder()
    .withLanguage(Language.JAVA)
    .withRefTracking(false)  // 禁用引用追踪
    .build();

2. 类型注册：

fury.register(GrpcService.ModelInferRequest.class);
fury.register(GrpcService.InferTensorContents.class);

3. 绕过 writeReplace：

fury.getClassResolver().setSerializerFactory((f, c) -> {
    if (Message.class.isAssignableFrom(c)) {
        return Serializers.newSerializer(f, c, 
            f.getClassResolver().getObjectSerializerClass(c, x -> {}));
    }
    return null;
});

深入解决方案

方案一：定制 Protobuf 序列化器

可参考 Twitter Chill 项目的实现思路，为 Fury 开发专用的 ProtobufSerializer：

1. 内部直接调用 Protobuf 的 toByteArray/parseFrom 方法
2. 保持 Protobuf 的二进制兼容性
3. 避免 Fury 的额外开销

方案二：POJO 结构优化

针对 POJO 序列化体积大的问题：

1. 检查是否误用 JDK 序列化方法
2. 优化集合类型的使用方式
3. 使用 @FuryIgnore 注解排除非必要字段

最佳实践建议

1. 新系统设计：

• 直接使用 POJO + Fury，避免 Protobuf 转换开销
• 保持对象结构的简洁性

2. 遗留系统迁移：

• 评估定制 Protobuf 序列化器的成本
• 逐步将 Protobuf 对象替换为标准 POJO

3. 性能关键场景：

• 保持使用原生 Protobuf 序列化
• 考虑混合使用 Fury 和 Protobuf

总结

Protobuf 生成的 Java 对象因其特殊的内部结构，不适合直接使用通用序列化框架处理。对于性能敏感场景，建议：

1. 要么完全使用 Protobuf 生态
2. 要么完全使用 Fury + POJO 方案
3. 混合方案需要谨慎评估序列化边界

Fury 团队正在开发 Python 端的优化方案，未来可能提供跨语言的完整解决方案。对于现有系统，开发者需要根据具体场景选择最适合的序列化策略。