4. 数据序列化与反序列化：JSON vs Protocol Buffers vs Avro

在 Backstage 数据传输优化中，序列化与反序列化是决定吞吐量、延迟与 Schema 兼容性的核心环节。本章从性能基准、Schema 管理策略与工程最佳实践三个维度，对比 JSON、Protocol Buffers（Protobuf）与 Apache Avro 三种主流格式，帮助你在黄金路径中做出正确选型。

4.1 三种序列化格式核心差异

4.2 性能对比基准数据

以下为基于 10 万条实体对象（含字符串、整数、嵌套结构）的实测对比结果（环境：Java 17，单线程，对象大小约 2KB）：

4.3 Schema 管理策略

Schema 管理是序列化选型的核心决策点。三种格式的管理方式差异显著：

• JSON：无强制 Schema，通常依赖文档约定或 JSON Schema 校验。演化时需手动处理字段增删，容易引发生产兼容性问题。
• Protocol Buffers：通过 .proto 文件定义强类型 Schema，使用字段编号（field number）实现向后兼容。新增字段必须使用新编号，废弃字段保留编号占位。
• Avro：采用读写 Schema 分离模式。写入时使用写 Schema，读取时使用读 Schema，Avro 引擎自动执行字段映射与默认值填充。支持完全向后/向前兼容。

4.4 Avro Schema 演化示例

以下展示 Avro 如何通过读写 Schema 分离实现字段新增的向后兼容：

// 写 Schema (v1) - 原始版本
{
  "type": "record",
  "name": "Entity",
  "fields": [
    {"name": "id", "type": "string"},
    {"name": "name", "type": "string"}
  ]
}

// 写 Schema (v2) - 新增字段，设置默认值
{
  "type": "record",
  "name": "Entity",
  "fields": [
    {"name": "id", "type": "string"},
    {"name": "name", "type": "string"},
    {"name": "version", "type": "string", "default": "1.0.0"}
  ]
}

// 读 Schema (v1) - 旧消费者仍可读取 v2 数据
// Avro 自动忽略 version 字段，不报错

4.5 序列化格式选型决策流程

以下 SVG 图展示了在 Backstage 黄金路径中如何根据场景选择序列化格式：

4.6 Backstage 黄金路径最佳实践

1. 统一使用 Avro 作为内部数据管道序列化格式，配合 Schema Registry 管理版本，实现零停机 Schema 演化。
2. 对外 REST API 保留 JSON，但在网关层自动完成 Avro→JSON 转换，避免内部传输性能损失。
3. Protobuf 仅用于 gRPC 服务间通信，不推荐在 Kafka 消息或数据湖场景中使用。
4. 所有 Schema 必须包含默认值，确保向后兼容。新增字段时，默认值必须与旧消费者兼容。
5. 使用 Avro 的 logicalType 定义日期、时间戳、UUID 等语义类型，提升数据可读性。
6. 避免在 Avro 中使用复杂嵌套 union，优先使用 record 类型封装，降低解析复杂度。
7. 序列化/反序列化使用缓冲池，避免频繁分配内存，提升吞吐量。

4.7 Avro Schema 注册与版本管理架构

以下 SVG 图展示了 Backstage 中集成 Schema Registry 的典型架构：