微服务 - 新旧版本之间的数据库兼容性答案

【问题标题】：Microservices - Database compatibility in between old and new versions微服务 - 新旧版本之间的数据库兼容性
【发布时间】：2017-12-13 22:20:47
【问题描述】：

我正在尝试深入研究微服务架构，开始为我的公司编写一些小逻辑。

我知道微服务关注的问题之一是数据库处理（每个微服务都必须有其独立的 db schmema）。因此，我正在寻找有关从旧微服务版本迁移到新微服务版本的建议或经验。

假设我有一个 REST API 端点 ms/v1/whatEver，它今天在 prod 上运行。一周后，我们决定上线下一个版本。因此，我们创建了一个ms/v2/whatEver，它在该服务所涉及的实体中包含一些新的列和数据类型。因此，为了不强制所有客户端立即迁移，我们希望保持这两个版本正常运行，直到用户逐步迁移到 v2。

如果我们同时启动并运行两个版本，我会想到几个场景（这实际上是我的主要疑问和这篇文章的原因）：

他们是否应该在同一个数据库实例中读/写，因此v1 实现必须适应v2 的新架构结构？
他们是否应该在单独的数据库实例中读/写。所以无论如何，两个数据库都必须同步，直到我们决定关闭v1 以保证我们不会错过任何数据（最终一致性）？所以我的问题是如何实现这一点（整个框架、队列消息传递或其他东西......）
或者，代码将每个v1 请求（在其中）转发到v2，后者将成为已迁移的新架构（唯一数据库实例）的所有者？

我一直在阅读像Migrating to Microservices Databases - Red Hat 这样的几本书，但它们是用概念术语编写的，但没有具体的技术或最好的事情来做这件事。所以我的帖子。

非常感谢您的意见。谢谢

【问题讨论】：

AFAIK 微服务背后的概念之一是每个服务都有自己的持久性，因此您所询问的内容永远不会发生。微服务应该不使用经典的表示、业务逻辑和持久性方案来划分。过分来说，数据库 MS 将只是数据库上的 REST API。
我更新了每个 MS 的数据库所有权。我总是在谈论相同的微服务，它将被迁移到它的新版本。所以我关心的是如何进行这种转换并保持数据库最新，直到每个用户都进入最后一个版本并关闭前一个版本。
每个微服务都有一个数据库根本不是必须的。这取决于您的需求，您可以拥有一个共享数据库或一个数据库服务。我宁愿拥有一个具有自动缩放功能的信号 AWS RDS，也不愿自己处理多个实例。但同样，这取决于每种情况。在这种情况下，我认为 3 种不同的选择是可行的。我会选择将旧端点转换为新端点的包装器，这样您就不必维护 2 个不同的端点。所以新列是可选的或者应该有一个默认值，都在同一个数据库中。

标签： database rest architecture microservices

【解决方案1】：

这是服务（不仅仅是微服务）中更复杂的主题之一。我有两种不同的方法。

1) 在新服务中加入向后兼容层（从而允许 v2 继续为 v1 客户端调用提供服务）

2) 保持数据库向后兼容，为新列设置智能默认值，仅在删除所有相关版本后删除列。

随着时间的推移，最终#1 一直是最容易维护的，只是因为我们很少让每个人都脱离 v1 服务，从而导致数据库架构混乱。一种实现，其中 api 转换以链的形式发生，每个版本都转换到下一个最高版本，直到最终达到当前版本。

如果可能的话，我会避免数据库级同步。很少有人放弃给定的版本，一旦你周围有六个这样的人，你会非常难过。

【讨论】：

非常感谢罗布。经过数小时阅读大量博客和一些书籍创意后，我会根据您的观点制作一个混合体，只是为了保持旧版本和新版本的活力并试一试。