3. Schema演化策略：字段添加、删除与重命名

好，咱们进入Schema演化的核心地带。说白了，数据契约最怕的就是「变」。业务要加字段、要删字段、要改字段名，这些需求天天有。但怎么变才能不把下游搞崩？这就是本章要聊的事。

我个人习惯把Schema演化分成三类操作：加字段、删字段、改字段。每一类都有对应的兼容策略，踩过的坑也各不相同。

3.1 字段添加策略：Optional vs Required

加字段是最常见的变更。业务方说「我要加个用户等级字段」，听起来很简单对吧？但这里有个大坑——新加的字段是Optional还是Required，决定了这次变更是否兼容。

3.1.1 Optional字段添加（推荐）

加Optional字段，说白了就是告诉消费者：「我多了一个字段，但你不读它也没事。」这是最安全的做法。

Avro Schema示例：

{
  "type": "record",
  "name": "UserEvent",
  "fields": [
    {"name": "userId", "type": "string"},
    {"name": "userName", "type": "string"},
    // 新增字段，使用union类型实现Optional
    {"name": "userLevel", "type": ["null", "string"], "default": null}
  ]
}

关键点：

• 使用union类型（如["null", "string"]）表示可选
• 必须提供default值，老数据反序列化时用默认值填充
• 消费者不感知新字段，序列化/反序列化完全兼容

3.1.2 Required字段添加（危险）

加Required字段，意味着所有消费者必须立即提供这个字段的值。你想想看，如果下游有100个服务，你能保证它们同时升级吗？

什么时候可以加Required字段？

• 新Topic/新队列，没有历史数据
• 所有消费者确认已升级，且经过灰度验证
• 走版本号升级（如v1→v2），新旧版本共存期间用兼容桥接

策略	兼容性	风险等级	推荐场景
Optional + 默认值	完全向前兼容	低	所有新增字段的首选
Required + 版本升级	不兼容，需版本协商	高	新Topic或全量升级后
Optional → 后续改Required	分阶段兼容	中	业务字段从可选变为必填

3.2 字段删除策略：Deprecation

删字段比加字段更棘手。为什么？因为老数据里还有这个字段，老消费者还在读它。你直接删了，下游反序列化直接崩。

正确的做法是——不要删，先废弃（Deprecate）。

3.2.1 废弃标记法

在Schema中给字段加一个废弃标记，但保留字段定义。消费者看到废弃标记后，主动迁移。

Protobuf示例：

message OrderEvent {
  string order_id = 1;
  string user_id = 2;
  // 废弃字段：old_status，请使用 new_status
  // 保留字段号3，但不再使用
  reserved 3;
  // 或者保留字段名
  // string old_status = 3 [deprecated = true];
  string new_status = 4;
}

废弃策略的步骤：

1. 标记废弃：在Schema中标注deprecated = true，生产者停止写入新值
2. 保留数据：老数据中的字段值仍然保留，消费者仍可读取
3. 通知消费者：通过文档、监控告警或邮件，告知消费者迁移
4. 等待窗口期：一般给2-4周，让所有消费者完成迁移
5. 最终清理：确认无消费者使用后，用reserved彻底移除

3.2.2 字段号回收（Protobuf特有）

Protobuf用字段号（field number）来标识字段，删除字段后字段号不能复用，否则新旧数据会解析错乱。用reserved关键字把字段号「占住」。

message UserEvent {
  reserved 2, 15, 9 to 11;  // 这些字段号已被废弃，不可复用
  reserved "old_field", "legacy_flag";  // 字段名也被保留
  
  string user_id = 1;
  string user_name = 3;
  // 注意：字段号2已被reserved，不能再用
}

3.3 字段重命名策略

重命名字段，听起来简单，但实际上是Schema演化里最容易被低估的坑。为什么？因为序列化时用的是字段名（Avro/JSON）或字段号（Protobuf），你改了名，老数据就读不出来了。

3.3.1 Avro/JSON Schema的重命名

Avro支持字段别名（aliases），这是最优雅的方案。

{
  "type": "record",
  "name": "UserEvent",
  "fields": [
    {"name": "userName", "type": "string", "aliases": ["name"]}
  ]
}

工作原理：

• 新生产者写userName，老消费者读name时，Avro通过别名自动映射
• 老生产者写name，新消费者读userName时，同样通过别名兼容
• 别名只在Schema注册时生效，运行时无额外开销

3.3.2 Protobuf的重命名

Protobuf依赖字段号，所以重命名字段本身是兼容的——只要不改字段号。但问题是，代码生成后的类名变了，消费者代码要改。

3.3.3 双写过渡法（通用方案）

如果Schema不支持别名（比如纯JSON），或者你需要零风险过渡，用双写法：

1. 新增字段（新名字），设为Optional
2. 生产者同时写入新旧两个字段，值保持一致
3. 通知消费者切换到新字段
4. 监控确认所有消费者已迁移
5. 移除旧字段（走废弃流程）

重命名方式	兼容性	迁移成本	适用格式
Avro别名映射	完全兼容	低（Schema注册即可）	Avro
Protobuf保留字段号	二进制兼容	中（需改代码）	Protobuf
双写过渡	完全兼容	高（双倍写入量）	JSON/所有格式
直接改名+版本升级	不兼容	极高（全量同步）	不推荐

3.4 演化策略选择指南

说了这么多，到底怎么选？我总结了一个简单的决策树：

• 加字段：一律用Optional + 默认值。等3个月后确认无人报错，再考虑改Required
• 删字段：先废弃，再保留，最后清理。每个阶段至少留一个监控周期
• 改字段名：优先用别名（Avro）或保留字段号（Protobuf）。不行就双写
• 改字段类型：这是最危险的，尽量别做。非做不可就加新字段，废弃旧字段