对于基于微服务的产品，我们希望提供向后兼容性。 这意味着我们将同时运行同一服务的多个版本。
问题：：创建新版本时，数据库TABLES中有更改，添加的列很少，更改的列也很少。在这种情况下，如果服务的数据库相同，则会影响较旧的服务。处理此问题的最佳方法是什么？ 我们可以拥有带有版本的数据库表吗？
一种已知的方法是为每个服务使用不同的数据库，我们希望避免这种情况。
答案 0 :(得分：1)
您永远不要处于这种情况。如果添加了列，则可以具有一个DTO，该DTO不会将这些新添加的列发送到较旧的版本。如果必须删除而不要删除，请停止使用它以用于新的api，如果需要更改，请创建一个新列，并丢弃并让新的api与新的api对话。
已经说过，应该抵制此类更改，并且如果需要，您需要确保可以保持数据完整性的方法。如果您停止使用现有的专栏并添加新的专栏，那么当您查看整个内容时将如何读取数据。 当新的api调用历史数据时会发生什么，当您在其上运行报表工具时会发生什么。
除了需要如何提供api以及服务将如何管理更改之外，还有很多问题需要回答。
创建一个新表可以解决，但是它的好坏取决于您的用例，所做的更改，服务中数据的意义是什么，其历史意义是什么，即是否需要较旧的数据，或者您可以将其转储等
我觉得这更多是业务决策，而不是技术决策。
就向后兼容性而言，我尝试在控制器级别提供它。我尽量在代码中只包含一种核心业务逻辑，并通过提供默认值或进行所需的转换将较旧的api映射到较新的api。 我永远不想坚持逻辑。需要一些努力，但我能够找到自己的方法。您的情况可能与我的情况不同，但仍要避免避免为旧API和新API保留两个表或两个数据库，并尝试将更改集中到将旧API集中管理的地方。
答案 1 :(得分：0)
首先，这是一个非常好的问题，设计很棘手。
您应该参考this answer以获得公正而广泛的想法。
我们可以拥有具有版本的数据库表吗？
我认为，您可以拥有所需的任何东西，但是不建议这样做，因为它给系统带来了某种复杂性。这也是以上答案中得出的结论。
处理此问题的最佳方法是什么？
我做这种事情的方式并在很少使用该API的系统中看到的内容基本上被视为表示层，并且避免了对先前版本的API进行不兼容的DB更改。
即可以说，新版本中有一个API更改，不需要更改数据库-没问题，一切都很好-继续前进。
然后可以说有一个新的API版本，要求对数据库进行更改，这将破坏现有的系统/旧版本-不好，请尝试以某种方式对您的解决方案进行重做以实现相同的功能破坏现有版本。如果这不可能（显然一切皆有可能！），则它是主要产品合并和升级的情况，需要推迟到废弃旧版本为止。
基于这个原因，在第一次尝试中，我们需要将数据库表和JPA实体设计为尽可能完整和广泛，并保持DTO和Entities分开，因此主要需要在DTO端而不是实体上进行更改侧。
很明显，这些是主观意见，将视情况而定，并可以进行辩论。