ByteByteGo Newsletter

Schema Evolution: Changing the Contract Without Breaking What Runs

8.5内容质量
Schema Evolution: Changing the Contract Without Breaking What Runs

TL;DR · AI 摘要

模式演变需通过兼容性策略和迁移方法，确保变更不破坏现有系统。

核心要点

  • 向后兼容允许旧系统处理新数据，而向前兼容允许新系统处理旧数据
  • 扩展迁移通过添加字段避免破坏现有代码，收缩迁移需谨慎处理字段删除
  • 模式注册表可追踪多个版本，但需配合明确的弃用时间表

结构提纲

按章节快速跳转。

  1. §引言

    模式变更看似简单，但生产环境可能因版本重叠导致服务失败。

  2. ·版本重叠

    多个版本同时运行时，数据读取版本差异会导致兼容性问题。

  3. ·兼容性策略

    向后兼容和向前兼容是解决版本冲突的核心机制。

  4. ›迁移方法

    扩展迁移添加字段无风险，收缩迁移删除字段需严格验证。

  5. ·注册表使用

    模式注册表可记录所有版本，但需配合弃用策略管理。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 模式演变策略
    • 版本重叠问题
      • 多版本共存风险
    • 兼容性机制
      • 向后兼容
      • 向前兼容
    • 迁移方法
      • 扩展迁移
      • 收缩迁移

金句 / Highlights

值得收藏与分享的关键句。

#Schema Evolution#API设计#数据库迁移#兼容性策略
打开原文

模式演进：在不破坏现有系统的情况下修改契约

ByteByteGo

2026年8月20日

模式变更通常是软件系统中最难处理的变更类型之一。然而，在代码审查中，它可能看起来相当简单。例如，它可能只是将某个字段重命名，或为特定事件添加一个新字段，或在响应负载中移除一个未被使用的字段。

情况变得更加复杂的是，迁移在预发布阶段顺利进行，但一旦变更部署到生产环境，其他不相关的服务和组件却开始失败。经过调查发现，迁移本身并没有问题。但变更生效时，有两个版本的应用程序仍在使用同一个数据库，而只有一个版本引用了修改后的模式。

这种情形在与模式相关的变更中非常常见。它也不局限于部署窗口。例如，多年前写入的行可能由后来被替换的应用程序代码生成。队列中的消息是在当前版本消费者编写之前发布的。十八个月前的移动应用版本仍安装在真实设备上，并继续调用API。在每种情况下，使用特定模式版本写入的数据都会用不同的版本进行读取，从而引发各种问题。

在本文中，我们将探讨模式演进及其应对策略。以下是本文内容：

  • 为什么同一时间总是存在多个模式版本
  • 向后兼容和向前兼容
  • 哪些变更会导致消费者故障，哪些不会，以及决定这些的条件
  • 扩展和收缩迁移
  • 模式注册表及其使用方式
  • 数据库、API和事件流中相同问题的差异
  • 版本策略和弃用时间线

版本重叠