如何在微服务架构中处理重复数据答案

【问题标题】：how to handle duplicated data in a micro service architecture如何在微服务架构中处理重复数据
【发布时间】：2018-08-11 08:51:43
【问题描述】：

我正在一个工作网站上工作，我正在考虑将工作匹配部分分解为一个微服务 - 其他一切都是一个整体。

但是，当考虑微服务应该如何拥有自己的独立数据库时，这意味着让微服务拥有所有作业的单独副本，因为单体应用仍将处理所有作业杂乱无章的功能。

我是否以正确的方式考虑这一点？将相同数据的多个副本分布在不同的微服务中是否正常？

让不同数据库拥有相同数据的想法让我有点害怕，因为这可能会导致数据不同步。

【问题讨论】：

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

您正试图摆脱单体应用，而您采用的方法非常常见，即从可以转换成微服务的单体应用中取出一部分。随着时间的推移，Monolith 开始缩小，并且您拥有更多的 MS。

谈到您的数据重复问题，是的，这是一个挑战，需要复制一些数据，但这会因情况而异，如果不研究应用程序就很难说。

您可以公开 API，以便单体可以在需要时获取/创建数据，我强烈建议不要牺牲或妥协 微服务的数据模型以避免重复，因为 MS 将比你未来的巨石。请记住，您应该避免将任何新代码添加到单体应用中，即使您必须这样做，也请询问 MS 而不是单体应用。

【讨论】：

感谢您的回复。这样我就可以确保我理解了，在确实需要复制数据的情况下 - 例如在初始端点是单体应用的某些数据上进行创建，单体应用程序将执行它自己的数据库更新为以及打电话给MS，它会自己更新数据库，对吧？如果其中一个更新失败，数据完整性是否会成为问题？
看来您正在开始迁移。 API 网关是微服务中使用的另一个概念。你肯定会需要它。首选 API 网关创建记录而不是整体（取决于）。关于数据完整性，答案很简单，它和单体应用一样重要。如果不影响功能，则可以考虑部分故障（阅读相关内容）。