在 Kevin Goldsmith 2015 年的演讲中Spotify 的微服务 https://youtu.be/7LGPeBgNFuU?t=925（从 15:25 - 17:43），他提到，当他们创建新版本的 API 时，他们只是创建一个新服务器，并保持旧服务器与旧版本一起运行，只要仍有客户端调用它（在本例中，是嵌入了 Spotify 的智能灯）。
我很困惑他们如何能够在可能的几年内维护和提供旧版本，而在这段时间内肯定会有数据库架构更改？
我可以看到一些可能的解决方案，但没有一个看起来很合理：
- 在所有版本中使用相同的数据库，仅添加新表和新的可为空字段。切勿删除字段、重命名字段、将字段设置为不可空、删除表或重命名表。
- 每个版本使用不同的数据库，将每个版本的数据分开。
- 每个版本使用不同的数据库，将每个版本的数据分开，但编写一种方法将请求从一个版本迁移并传递到另一个版本，以便每个版本接收带有该版本的有效参数的请求。
解决方案 1 听起来会产生太多的代码味道，到处都是遗留代码（在我看来，Kevin 似乎表明他们肯定不会这样做）。
解决方案 2 听起来像是一场噩梦，无法从其他服务或报告中提取数据。如果您想要的实体信息位于另一个版本的数据库中，而不是您请求的数据库中，该怎么办？
解决方案 3 听起来更像是一场噩梦，因为您必须编写代码来将您的版本的请求迁移到您的版本之上和之下。这意味着您在创建新版本时不能仅保留现有（当前正在生产的版本）版本，因为您需要添加迁移以向前和向后移动请求，以便所有版本都收到请求的正确参数。
希望我只是在这里错过了一些简单的东西，并且有一个神奇的解决方案可以使这个问题变得更容易，但我真的不明白他们如何实现这一点？
Thanks!
我不知道 Spotify 内部是如何做到这一点的。
从他谈论的方式来看，我不确定这些微服务是否存储了任何数据。我感觉它们本质上是其他东西（可能是内部服务层）之上的表示层。
如果一个微服务可以有多个活动版本，并且它也是某些数据的所有者，那么可能会发生以下两种情况之一：
- 架构一致性应用于服务级别，如果对架构进行更改，则必须在所有历史版本中进行更新。在独立部署多个版本的情况下，这将需要在架构更改时部署所有版本（他并没有像这样说，但这就是我一直进行版本控制的方式）
- 每个版本都拥有数据的独立副本。为此，您确实需要在系统中拥有一个发布/订阅模型，并根据某种消息执行所有修改。 （对我来说，这似乎效率很低，除非其流失率非常低，但也许在这种规模上它可能是有意义的，还存在如何用数据启动新版本的问题）
我认为运行一个模式并且从不改变它不会真正长期有效。事情在变化，变化是必要的。微服务/SOA (IMO) 的最大好处之一是，由于域较小且包含在内，因此更改更容易。由于代码量很低，您可以相当安全、快速地完成诸如完全更改存储机制（甚至可能更改为新型存储）之类的事情。
我的文章中有关微服务版本控制的更多想法，微服务版本控制；如何在不破坏内容的情况下进行重大更改 http://blog.staticvoid.co.nz/2017/microservice_versioning;_how_to_make_breaking_changes_without_breaking_stuff/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
