Schema 演化 7 规则 = 通信合约的演化纪律

解决什么问题：事件 schema 改变导致消费者崩溃—— Schema 演化提供"安全改变"的纪律，让 producer 和 consumer 独立演化。

业务问题

真实场景

场景 1：电商订单事件 schema 改变

# v1 schema
{
    "orderId": "123",
    "amount": 99.99,
    "status": "CONFIRMED"
}

# v2 schema（开发者加了字段）
{
    "orderId": "123",
    "amount": 99.99,
    "status": "CONFIRMED",
    "currency": "CNY",  # 新字段
    "discount": 10       # 新字段
}

# 问题：
# - 旧消费者读 v2 → 看到 currency/discount 但不识别
# - 新消费者读 v1 → 没有 currency → 用默认？还是报错？
# - 字段重命名 → 全部消费方都崩

Bellemare Ch 3 原话：

"Any implementation of event-based communication between a producer and consumer that lacks an explicit predefined schema will inevitably end up relying on an implicit schema. Implicit data contracts are brittle."

失败模式

失败模式	后果
直接删字段	旧消费者失败
修改字段类型	反序列化错误
改字段语义	业务逻辑错误
隐式 schema	难以协调

控制论视角

Ch 20："通信系统的设计有明确的极限" + Ch 4 §4.6："不变量必须被维护"

Schema 演化 = 通信合约的演化
  - 不变量 = schema 的兼容性约束
  - 通信极限 = 演化必须保持的最小兼容集
  - Shannon 信息论：消息 = 信源编码 → 信道 → 信宿解码

对位：

• Schema = 信源编码（发送方的"语言"）
• Compatibility = 信道容量（可承载的变化范围）
• Consumer = 信宿解码（必须能解码新版本）

核心概念

兼容性 3 类型

类型	含义	场景
Forward	新 schema 写的数据能被旧 schema 读	Producer 先升级
Backward	旧 schema 写的数据能被新 schema 读	Consumer 先升级
Full	双向兼容（首选）	任意升级顺序

Schema 演化 7 规则

安全操作（兼容）：
  1. 加新字段（带默认值）       ✓ Forward + Backward
  2. 删可选字段（保留一段时间）✓ Forward（消费者忽略）
  3. 加新枚举值（消费者需升级）✓ Forward
  
危险操作（破坏兼容）：
  4. 删必填字段               ✗ 破坏 Backward
  5. 改字段类型                ✗ 破坏 Both
  6. 改字段语义                ✗ 破坏 Both
  7. 重命名字段                ✗ 破坏 Both

Schema Registry 模式

组成：
  - Schema 集中存储（版本管理）
  - 兼容性检查（升级前自动验证）
  - 代码生成（从 schema 生成类）
  - 元数据（注释/触发逻辑）

工具：Confluent Schema Registry、AWS Glue Registry、Apicurio

演化流程

步骤 1：提交新 schema 到 Registry
步骤 2：Registry 检查兼容性（fail-fast）
步骤 3：如果兼容 → 通过
步骤 4：如果不兼容 → 拒绝 + 提示修改
步骤 5：Producer 使用新 schema
步骤 6：Consumer 独立升级（任意顺序）

工程实践

决策 1：选什么 Schema 语言

决策树：
  数据量大 + 高性能？
    - 是 → Avro 或 Protobuf（二进制）
  需要人类可读？
    - 是 → JSON Schema
  跨语言？
    - 是 → Protobuf 或 Avro
  云服务？
    - 是 → 云原生 Schema Registry

决策 2：兼容性策略

默认：Full Compatibility（首选）
放宽：
  - 只有 Producer 可控、Consumer 都升级 → Backward
  - 测试环境 → 可放宽
  
严格：
  - 多团队 + 重要数据 → Full

实战模板（Avro 示例）

{
  "type": "record",
  "name": "OrderCreated",
  "namespace": "com.example.orders",
  "doc": "Triggered when a new order is created. Status starts as NEW.",
  "fields": [
    {"name": "orderId", "type": "string", "doc": "Unique order ID"},
    {"name": "customerId", "type": "string", "doc": "Customer ID"},
    {"name": "amount", "type": "double", "default": 0.0},
    {"name": "currency", "type": "string", "default": "USD"},
    {"name": "createdAt", "type": "long", "doc": "Unix timestamp"}
  ]
}

反模式 vs 正模式

反模式	正模式
隐式 schema	显式 schema + Registry
直接删字段	标记 deprecated → 移除
改字段类型	新建字段 + 数据迁移
紧耦合升级	独立升级（Full 兼容）

性能指标

指标	衡量	健康值
Schema 版本数	当前 schema 版本	< 5 个活跃
兼容性检查通过率	升级通过率	> 99%
破坏性变更次数	半年内	0（用演化代替）
消费者兼容性	各消费者独立升级次数	高

边界判断

何时用 Schema Registry（★ 推荐）

• 多 producer / 多 consumer
• 多团队协作
• 长期运行（> 6 个月）

何时不用（小项目）

• 单一 producer + 单一 consumer
• 短期项目
• 团队完全控制

何时升级

当前	升级到	触发条件
无 schema	JSON Schema	多消费者
JSON Schema	Avro/Protobuf	性能要求
单 Registry	多 Registry	多区域/多云

关键洞察

1. Schema 演化 = 通信合约纪律——没有纪律 = 必然破坏消费者。
2. Full Compatibility 是首选——可以放松，但收紧几乎不可能。
3. Schema Registry = 强制检查点——把"破坏性变更"从"事后发现"变成"事前阻止"。
4. 触发逻辑比数据定义更危险——改"为什么产生事件"破坏原义，比改字段更可怕。
5. 与 cybernetics 同构——Ch 20 信息论的"通信极限"在事件驱动 = Schema 兼容性极限。