我正在尝试深入微服务架构，开始为我的公司编写一些小块逻辑。
我知道微服务问题之一是关于数据库处理（每个微服务必须有它分离的db schmema）。所以我正在寻找有关从旧的微服务版本迁移到新的微服务版本的建议或经验。
假设我有一个REST API端点ms/v1/whatEver，它今天在prod上运行。一周后，我们决定使用下一个版本。因此，我们创建了一个ms/v2/whatEver，它在此服务中包含的实体中包含一些新的列和数据类型。因此，为了不强制所有客户端立即迁移，我们希望保持这两个版本的正常运行，直到用户逐步移动到v2。
如果我们同时启动和运行版本（这实际上是我的主要疑问和此帖子的原因），我会想到几个场景：
如果他们在同一个数据库实例中读/写，那么必须调整v1实现以匹配v2的新架构结构吗？
他们应该在单独的数据库实例中读/写。因此，在我们决定关闭v1以确保我们不会遗漏任何数据（最终一致性）的那一天，两个数据库必须同步。所以我的问题是如何实现这一点（整个框架，队列消息或其他东西......）
或者，将每个v1请求（在其内部）转发到v2的代码，该use Symfony\Component\HttpFoundation\JsonResponse;
将成为已迁移的新架构（唯一数据库实例）的所有者？
我一直在阅读像Migrating to Microservices Databases - Red Hat这样的几本书，但它们是用概念术语编写的，但没有具体的技术或最好的事情。这样我的帖子。
我非常感谢你的意见。 感谢
答案 0 :(得分：4)
这是服务中更复杂的主题之一（不仅仅是微服务）。我已经完成了两种不同的方式。
1）在新服务中加入向后兼容层（从而允许v2继续为v1客户端调用提供服务）
2）保持数据库向后兼容，为新列添加智能默认值，只删除所有相关版本后删除列。
最终＃1是最容易维护的，因为我们很少让每个人都离开v1服务，导致凌乱的数据库架构。 api转换作为链发生的实现，每个版本转换为下一个版本，直到最终到达当前版本。
如果可能的话，我会避免数据库级同步。很少有人能够获得一个特定的版本，一旦你找到了这些版本中的六个，你就会非常难过。