architecture - 出于项目推荐目的在微服务之间共享(几乎)相同的数据是否是个坏主意

Question

我有一个关于由微服务组成的应用程序架构的问题。

我的微服务很少，但在这个问题的上下文中有趣的是:

人力资源 - 这里存储了所有用户数据，如用户名、性别、用户体验等。

工作机会 - 这里存储了每个招聘广告的所有数据 - 职位描述、预期经验等。

因此，我需要创建新的微服务(我们将其命名为 Recommender )，其唯一目的是 - 基于上述微服务的文本，从 推荐最适合的人类账户人力资源 到每个招聘广告。来自 工作机会 .我用来计算相似度的 NLP 算法需要遍历每个 人力资源 每件物品 工作机会广告。

到现在为止还挺好。实现此目的的一种方法是引入消息队列。从 开始对人力资源的每个创建/更新操作人力资源 通过此 MQ 推送包含所有资源数据的新消息。 推荐人微服务将处理这条新消息，它将处理需要的数据(删除不需要的数据)并将其存储在本地数据库中。当 时也需要同样的东西工作机会更新/创建资源以计算一对一的相似性。

以下是我的问题:

有没有更好的方法来实现上述目标？

我知道微服务架构设计中的最佳实践告诉我们数据不应该被复制，但是可以存储处理过的和有限的数据，比如原始数据的副本吗？

谢谢!

Answer 1

我认为具有三个服务(HR、Jobs、Recommender)的通用架构很好，因为它清楚地定义了职责并将系统中的不同功能分开。

在我看来，您不应该在 Recommender 服务中持久保留任何数据。想象一下，如果 HR 数据库的数据库架构发生变化(例如，新数据字段)，您可能需要更改推荐算法，但您只想在一个(HR)服务中更改数据库，而不是在两个服务中更改。想象一下，如果由于某种原因 Recommender 服务由于错误而错过了更新事件，您将不得不以某种方式修复两个服务之间不一致的数据库状态。

另一方面，如果您需要节省服务之间的通信带宽，您可以考虑保留一些数据作为架构权衡 - 但这似乎不太可能，并且与微服务架构背后的想法背道而驰。