如何使用不同的数据库模式提供多个版本的API？

Question

在Kevin Goldsmith的2015年谈论microservices at Spotify（从15:25 - 17:43），他提到当他们创建一个新版本的API时，他们只是创建一个新的服务器，并保持旧服务器运行旧版本，只要仍然有客户端调用它（在这种情况下，嵌入Spotify的智能灯）。

我很困惑他们如何能够维护和提供可能年份的旧版本，当时在这段时间内肯定会有数据库架构更改？

我可以看到一些可能的解决方案，但它们似乎都不合理：

1. 在所有版本中使用相同的数据库，只需添加新表和新的可空字段。切勿删除字段，也不要重命名字段，也不要将字段设置为不可为空，也不要删除表，也不要重命名表。
2. 每个版本使用不同的数据库，将每个版本的数据分开。
3. 每个版本使用不同的数据库，保持每个版本的数据分开，但写一种方法来迁移并将请求从一个版本传递到另一个版本，以便每个版本都接收带有该版本的有效参数的请求

解决方案1听起来会引起太多的代码味道，遗留代码无处不在（在我看来，凯文似乎暗示他们肯定不会这样做。）

解决方案2听起来像是一个噩梦，可以将数据从其他服务或报告中提取出来。如果您想要的实体信息在您要求的实体的另一个版本的数据库中，该怎么办？

解决方案3听起来更像是一场噩梦，因为您必须编写代码来将您的版本请求迁移到您上面和下面的版本。这意味着您无法在创建新版本时保留现有（当前正在生产的版本）版本，因为您需要添加迁移以向前和向后移动请求以便所有版本收到了请求的正确参数。

希望我在这里错过了一些简单的东西，并且有一个神奇的解决方案可以让这个问题变得更容易，但我真的看不出他们如何能够实现这个目标？

谢谢！

Answer 1

我不知道Spotify在内部是如何做到的。

虽然从他谈论它的方式来猜测，但我不确定这些微服务是否存储任何数据。我觉得它们本质上是一个表示层而不是其他东西（可能是内部服务层）。

如果微服务可以有多个版本处于活动状态，并且它也是某些数据的所有者，那么可能会发生以下两种情况之一：

• 架构一致性在服务级别应用，如果对架构进行了更改，则必须在所有历史版本中更新架构。在独立部署多个版本的情况下，这将无法在模式更改中部署所有版本（他没有像这样说话，但这就是我一直在进行版本控制的方式）
• 每个版本都拥有一份独立的数据副本。要做到这一点，你真的需要在系统中有一个pub / sub模型，并根据某种消息执行所有修改。 （对我而言，这似乎效率很低，除非它的流失率非常低，但也许在这种规模下可能有意义，如何用数据填充新版本也存在问题）

我不认为运行架构并且永远不会改变它会真正长期运作。事情发生变化，变化是必然的。微生物/ SOA（IMO）最大的好处之一是变化更容易，因为域很小并且包含在内。当代码量很低时，您可以合理安全地快速完成更改存储机制（甚至可能更新的存储类型）。

在我的文章Microservice versioning; How to make breaking changes without breaking stuff

中有关微服务版本控制的更多想法