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

Question

在Kevin Goldsmith 2015年关于Spotify微服务(15:25-17:43)的讨论中,他提到当他们创建一个新版本的API时,他们只需创建一个新服务器,并保持旧服务器运行旧版本只要还有客户呼叫它(在这种情况下,嵌入了Spotify的智能灯).

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

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

解决方案1听起来会引起太多的代码味道,遗留代码无处不在(在我看来,凯文似乎暗示他们当然不这样做).

对于其他服务或报告,解决方案2听起来像是一场噩梦.如果您想要的实体信息在您要求的实体的另一个版本的数据库中,该怎么办？

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

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

谢谢!

Answer 1

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

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

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

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

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