3. 序列化基础概念：序列化与反序列化的定义、作用、在BFF中的位置、常见序列化格式对比

3.1 序列化与反序列化的定义

序列化（Serialization） 是将内存中的对象、数据结构或状态信息，转换为可存储或可传输的字节序列（如 JSON 字符串、二进制流）的过程。反序列化（Deserialization） 则是其逆过程，将字节序列还原为内存中的对象。

3.2 序列化的作用

• 网络传输：将复杂对象扁平化为字节流，便于在 HTTP、gRPC、消息队列等协议中传输。
• 持久化存储：将对象状态保存到文件、数据库或缓存（如 Redis）中。
• 跨语言/跨平台通信：不同语言（Java、Go、Python）通过统一序列化格式交换数据。
• 深拷贝：通过序列化/反序列化实现对象的完整复制。

3.3 序列化在 BFF 中的位置

在 BFF（Backend For Frontend）聚合服务中，序列化发生在两个关键边界：

1. 上游边界：BFF 从下游微服务获取数据时，需要反序列化微服务返回的响应（如 Protobuf 二进制流）。
2. 下游边界：BFF 将聚合后的数据序列化后，通过 HTTP Response 返回给前端客户端（通常为 JSON）。

3.4 常见序列化格式对比

下表从多个维度对比四种主流序列化格式：

3.5 序列化格式选择决策树

在 BFF 架构中，选择序列化格式可参考以下决策逻辑：

• 如果数据需要被浏览器直接消费 → 选择 JSON（前端原生支持，无需额外解析库）。
• 如果 BFF 与微服务之间需要高性能通信 → 选择 Protobuf（体积小、速度快、兼容性好）。
• 如果团队已有 Thrift 基础设施 → 选择 Thrift（与现有 RPC 框架集成度高）。
• 如果对接遗留系统或需要严格文档化 → 选择 XML（但 BFF 场景中已较少使用）。

3.6 序列化性能关键指标

在 BFF 场景中，评估序列化格式时需关注以下指标：

3.7 代码示例：JSON vs Protobuf 序列化对比

以下示例展示相同数据结构在 JSON 和 Protobuf 下的序列化结果差异：

// 原始数据对象（用户信息）
{
  "userId": 1001,
  "userName": "Alice",
  "email": "alice@example.com",
  "age": 28,
  "tags": ["vip", "premium"]
}

// JSON 序列化结果（文本，共 112 字节）
{"userId":1001,"userName":"Alice","email":"alice@example.com","age":28,"tags":["vip","premium"]}

// Protobuf 序列化结果（二进制，共 38 字节）
// 使用字段编号代替字段名，体积减少约 66%
// 0x08 0xE9 0x07 0x12 0x05 0x41 0x6C 0x69 0x63 0x65 ...