如何提供具有不同数据库模式的API的多个版本? [英] How to offer multiple versions of an API with different database schemas?

问题描述

在凯文·戈德史密斯(Kevin Goldsmith)2015年的演讲中， Spotify上的微服务(从15:25-17:43 )，他提到，当他们创建API的新版本时，他们只是创建新的服务器，并且只要仍然有客户端在调用旧服务器(在这种情况下为带有Spotify嵌入其中).

In Kevin Goldsmith's 2015 talk about microservices at Spotify (from 15:25 - 17:43), he mentions that when they create a new version of an API they just create a new server, and keep the old server running with the old version for as long as there are still clients calling it (in this case, a smart lamp with Spotify embedded on it).

当他们确定在那个时间范围内数据库架构会发生变化时，我对他们如何能够维护和提供可能会持续多年的旧版本感到困惑?

I am confused about how they would be able to maintain and offer older versions for potentially years, when surely there would be database schema changes during that timeframe?

我可以看到一些可能的解决方案，但是似乎都不是很合理:

I can see a few possible solutions, but none of them seem very reasonable:

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

解决方案1听起来会引起太多的代码气味，到处都有旧代码(在我看来，凯文(Kevin)似乎暗示他们肯定不会这样做).

Solution 1 sounds like it would induce way too much code smell, with legacy code everywhere (which Kevin, in my opinion, seems to suggest they certainly do not do).

解决方案2听起来像一场噩梦，将数据拉出用于其他服务或报告.如果有关所需实体的信息不在您请求的版本的数据库中，该怎么办?

Solution 2 sounds like a nightmare to pull data out of for other services, or for reporting. What if the information about an entity that you want is in another version's database than the one you request?

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

Solution 3 sounds like more of a nightmare as you would have to write code to migrate a request for your version, to the versions above and below yours. This would mean that you can't just leave the existing (the one currently in production) version as-is when creating a new version, as you would need to add migrations to move the request both forward and backward so that all versions received the correct parameters for the request.

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

Hopefully I am just missing something simple here, and there is a magic solution to make this problem easier, but I really cannot see how they could accomplish this?

谢谢！

推荐答案

我不知道Spotify如何在内部执行此操作.

I have no idea how spotify does this internally.

尽管只是从他谈论的方式猜测，但我不确定这些微服务是否存储了任何数据.我觉得它们本质上是位于其他内容之上的表示层(也许是内部服务层).

Just at a guess though from the way he was talking about it, I'm not sure these microservices were storing any data at all. I got the feeling that they were essentially a presentation layer on top of something else (perhaps an internal service layer).

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

If a microservice can have multiple versions active, and it is also the owner of some data then one of two things are probably happening:

• 架构一致性应用于服务级别，如果对架构进行了更改，则必须在所有历史版本中对其进行更新.在独立部署多个版本的情况下，这将促使在架构更改时部署所有版本(他不是这样说的，但这是我一直进行版本控制的方式)
• 每个版本都拥有数据的独立副本.为此，您实际上需要在系统中具有发布/订阅模型，并由于某种消息而执行所有修改. (在我看来，除非流失率非常低，否则这似乎效率很低，但也许在这样的规模上可能是有道理的，如何用数据填充新版本也存在问题)

我认为运行一个模式并且永远不更改它不会长期有效.事物在变化，变化是必然的.微服务/SOA(IMO)的最大好处之一是，由于域很小且受到限制，因此更改更加容易.您可以执行一些操作，例如在代码量很少的情况下，合理安全，快速地完全更改存储机制(甚至可能更改为一种新型的存储).

I dont think running a schema and never changing it would really work long term. Things change and changes are nessacary. One of the biggest benifits of microservies/SOA (IMO) is that change is easier as the domains are small and containted. You can do things like completely change the storage mechanism (perhaps even to a new type of storage) reasonably safely and quickly as the volume of code is low.

我的文章微服务版本控制；如何在不中断内容的情况下进行重大更改

这篇关于如何提供具有不同数据库模式的API的多个版本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！