在微服务之间共享（几乎）相同的数据以进行项目推荐是个坏主意吗？

Question

我对由微服务组成的应用程序的架构有疑问。

我很少有微服务，但是在这个问题中有趣的是：

1. 人力资源-这里存储了所有用户数据，例如用户名，性别，用户体验等。
2. 工作-这里存储着有关每个工作广告的所有数据-工作描述，预期经验等。

因此，我需要创建新的微服务（将其命名为 Recommender ），其唯一目的是-根据上述微服务的文本，从 Human推荐最合适的人工帐户每个职位广告的资源。来自工作。我用来计算相似度的NLP算法需要遍历每个职位广告的每个人力资源项目。

到目前为止，太好了。实现此目的的一种方法是引入Message Queue。在来自 Human Resources 的人力资源的每次创建/更新操作上，以通过此MQ发送带有所有资源数据的新消息。 推荐微服务将处理此新消息，它将处理所需的数据（删除不需要的数据）并将其存储在本地数据库中。当更新/创建工作资源以计算一对一相似度时，将需要相同的内容。

这是我的问题：

1. 是否有更好的方法来实现上述目标？
2. 我知道微服务体系结构设计中的最佳实践告诉我们，数据不应重复，但是可以存储经过处理的有限数据（例如原始数据的副本）吗？

谢谢！

Answer 1

我认为带有三个服务（HR，Jobs，Recommender）的通用体系结构很好，因为它明确定义了职责并分离了系统中的不同功能。

我认为，您不应该将任何数据永久保留在Recommender服务中。想象一下，如果HR数据库的数据库架构发生更改（例如新数据字段），则可能必须更改推荐程序算法，但是您只想更改一个（HR）服务中的数据库，而不想更改两个服务中的数据库。想象一下，如果由于某种原因，Recommender服务由于错误而错过了更新事件，您将不得不以某种方式修复这两个服务之间不一致的数据库状态。

另一方面，如果您需要节省服务之间的通信带宽，则可以考虑将一些数据作为体系结构的折衷方案-但这似乎不太可能，并且会与微服务体系结构背后的想法背道而驰。

Answer 2

您问了两个要点。我遇到过类似的情况，以下是我的建议。 1-是否有更好的方法来实现上述目标？ 答案-您在正确的道路上。只需确保您严格遵循微服务体系结构，然后分别部署“推荐”微服务即可。

2-我知道微服务体系结构设计中的最佳实践告诉我们，不应复制数据，但是可以存储经过处理的有限数据（类似于原始数据的副本）吗？ 答案-微服务带来了很大的灵活性。您可以在“推荐”微服务的专用数据存储中拥有大量已处理的数据，该数据存储将为主应用程序提供正确匹配的候选信息。您可能面临或要计划的问题是，当源数据存储“人力资源”和“工作”中的任何更改时，Recommender微服务的数据一致性会发生什么。即您可能需要重新运行“推荐器”逻辑以重新生成结果。您已经使用MQ提交了作业，但是如果密钥信息发生更改，我建议使用可以从Source表发布的事件，然后作为订阅者的Recommender可以侦听这些事件，获取数据并重新运行逻辑以产生一个事件。新的结果集。