database - 如何提供具有不同数据库架构的 API 的多个版本？

Question

在 Kevin Goldsmith 2015 年的演讲中 microservices at Spotify (从 15:25 - 17:43)，他提到当他们创建一个新版本的 API 时，他们只是创建一个新服务器，并保持旧服务器与旧版本一起运行，只要还有客户调用它(在本例中，是嵌入了 Spotify 的智能灯)。

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

我可以看到一些可能的解决方案，但没有一个看起来很合理:

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

解决方案 1 听起来会导致太多代码异味，遗留代码无处不在(在我看来，Kevin 似乎暗示他们肯定不会这样做)。

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

解决方案 3 听起来更像是一场噩梦，因为您必须编写代码来将对您的版本的请求迁移到高于和低于您的版本。这意味着您在创建新版本时不能只保留现有(当前正在生产的)版本，因为您需要添加迁移以向前和向后移动请求，以便所有版本都收到请求的正确参数。

希望我只是在这里遗漏了一些简单的东西，并且有一个神奇的解决方案可以使这个问题变得更容易，但我真的看不出他们是如何做到这一点的？

谢谢!

Answer 1

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

虽然从他谈论它的方式来看只是猜测，但我不确定这些微服务是否存储了任何数据。我感觉它们本质上是在其他东西之上的表示层(可能是内部服务层)。

如果微服务可以有多个事件版本，并且它也是某些数据的所有者，那么可能会发生以下两种情况之一:

• 模式一致性应用于服务级别，如果对模式进行了更改，则必须在所有历史版本中进行更新。在独立部署多个版本的情况下，这将需要在模式更改时部署所有版本(他没有像这样说话，但我一直都是这样进行版本控制的)
• 每个版本都拥有一份独立的数据副本。为此，您确实需要在系统中有一个发布/订阅模型，并根据某种消息执行所有修改。 (对我来说，这似乎非常低效，除非它的流失率非常低，但也许在这种规模下它可能有意义，如何用数据启动新版本也存在问题)

我不认为运行一个模式并且从不改变它真的能长期有效。事情在变化，变化是必然的。微服务/SOA (IMO) 的最大好处之一是更改更容易，因为域很小且包含在内。由于代码量很低，您可以合理、安全、快速地完全改变存储机制(甚至可能是一种新的存储类型)。

在我的文章 Microservice versioning; How to make breaking changes without breaking stuff 中有更多关于微服务版本控制的想法