Schema 演进：在不破坏运行的前提下变更契约
本文探讨 Schema 演进的挑战与策略，涵盖版本重叠、前后兼容性、扩展与收缩迁移、Schema 注册表及版本化策略。
中文处理结果
Schema 变更通常是软件系统中最困难的变更类型之一。然而，在评审中它可能看起来相当小而简单。例如，可能只是重命名一个列、为某个特定事件添加一个新字段，或者响应负载中删除一个未使用的字段。
更复杂的是，在暂存阶段迁移顺利且干净，但一旦变更部署到生产环境，无关的服务和组件就开始失败。经调查发现，迁移本身没有问题。但它在两个版本的应用仍针对同一数据库运行时生效，而只有其中一个版本引用了修改后的 Schema。
这种情况在 Schema 相关变更中很常见。它也不仅限于部署窗口。例如，多年前写入的行可能由后来被替换的应用程序代码产生。队列中的消息是在当前版本消费者编写之前发布的。十八个月前的移动应用版本仍安装在真实设备上，并且仍在调用 API。在每种情况下，在特定 Schema 版本下写入的数据在另一个版本下被读取，导致多种问题。
在本文中，我们将探讨 Schema 演进及其策略。以下是我们将涵盖的内容：
- 为什么同一时间总是有多个 Schema 版本在起作用
- 向后和向前兼容性
- 哪些变更会破坏消费者，哪些不会，以及决定这一点的限定条件
- 扩展与收缩迁移
- Schema 注册表及其使用
- 同一问题在数据库、API 和事件流中有何不同
- 版本化策略和弃用时间线
版本重叠
阅读更多
原始正文摘录
Schema Evolution: Changing the Contract Without Breaking What Runs
A schema change is usually one of the most difficult types of change for a software system. However, it might look quite small and simple in review. For example, it might be something as simple as a column being renamed, or a new field being added to a particular event, or a response payload dropping a field that was not being used.
To make matters more complicated, the migration goes smoothly and cleanly during the staging phase, but unrelated services and components start failing as soon as the change is deployed to production. On investigation, it is found that nothing was wrong with the migration itself. But it took effect while two versions of the application were still running against the same database, and only one of those versions referenced the modified schema.
This situation is common with schema-related changes. It is also not limited to the deployment window. For example, rows written years ago can get produced by application code that has since been replaced. The messages sitting in a queue were published before the current version of the consumer was written. Mobile app versions from eighteen months back are still installed on real devices and still calling the API. In each case, data written under a particular schema version is read under a different version, resulting in multiple issues.
In this article, we will look at schema evolution and strategies for the same. Here’s what we will cover:
- Why more than one schema version is always in play at the same time
- Backward and forward compatibility
- Which changes break consumers, which do not, and the qualifiers that decide it
- Expand and contract migrations
- Schema registries and their use
- How the same problem differs across databases, APIs, and event streams
- Versioning strategies and deprecation timelines
Version Overlap
Read more