Microservices 如何在微服务体系结构中处理重复数据

我在一个求职网站上工作，在那里我想把求职匹配部分变成一个微型服务——其他一切都是一个整体

但是当考虑到微服务应该如何拥有自己的独立数据库时，这意味着微服务拥有所有作业的独立副本，因为monolith仍然可以处理所有作业crud功能

我的想法正确吗？相同数据的多个副本分布在不同的微服务上是否正常

---

拥有相同数据的不同数据库的想法让我有点害怕，因为这会造成事情不同步的可能性。

您正试图摆脱monolith，您正在采取的方法非常普遍，从monolith中取出一部分可以转换为微服务。随着时间的推移，巨石开始收缩，你有更多的MSs

关于数据重复性的问题，是的，这是一个挑战，一些数据需要复制，但这因情况而异，如果不考虑应用，很难说

---

您可以公开API，以便monolith可以在需要时获取/创建数据，我强烈建议不要牺牲或破坏微服务的数据模型以避免重复，因为MS在未来将比您的monolith更重要。请记住，您应该避免向monolith添加任何新代码，即使必须这样做，也可以向MS而不是monolith请求数据。

您可以尝试的另一件事是，不必在微服务之间调用REST API，您可以使用带有事件总线的缓存机制。每个微服务将CRUD更改发布到事件总线，感兴趣的微服务使用这些事件并相应地更新本地缓存

---

REST调用的问题是，在某些情况下，当依赖服务关闭时，我们无法查询主微服务，这可能会成为瓶颈

为什么microservice不能公开API来执行crud操作，哪个monolith可以调用？感谢您的响应。为了确保我理解，在需要复制数据的情况下-例如，在一些数据上创建一个初始端点是monolith的示例中，monolith将进行自己的db更新以及调用MS进行自己的db更新，对吗？如果其中一个更新失败，数据完整性是否会成为一个问题？似乎您正在开始迁移。API网关是微服务中使用的另一个概念。你肯定需要它继续前进。首选API网关来创建记录，而不是monolith。关于数据完整性，答案很简单，它和在monolith中一样重要。如果未对功能产生影响，则可以考虑阅读到的部分故障。