出于项目推荐目的在微服务之间共享(几乎)相同的数据是否是个坏主意 [英] Is it bad idea to share (almost) identical data among microservices for item recomendation purposes

问题描述

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

I have a question about the architecture of application composed of microservices.

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

I have few microservices, but those that are interesting in the context of this question are:

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

1. Human Resources - here are stored all the user data such as username, sex, user's experience etc.
2. Jobs - here are stored all the data about each job advertisement - job description, expected experience etc.

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

So, I need to create new microservice (let's name it Recommender) which sole purpose will be - based on the texts of the microservices mentioned above to recommend best fitted human account from Human Resources to each job ad. from Jobs. The NLP algorithm which I use to calculate the similarities need to walk each Human Resources item for every Jobs ad.

到目前为止，一切都很好.实现此目的的一种方法是引入消息队列.人力资源在每次人力资源的创建/更新操作时，通过这个MQ推送包含所有资源数据的新消息.Recommender 微服务将处理这条新消息，它将处理需要的数据(删除不需要的数据)并将其存储在本地数据库中.当更新/创建工作资源以计算一对一的相似性时，将需要同样的事情.

So far, so good. One way to achieve this is to introduce Message Queue. On each create/update operation of human resource from Human Resources to push new message with all the resource data through this MQ. The Recommender microservice will handle this new message, it will process the needed data (remove the not needed data) and it will store it in local DB. Same thing will be needed when Jobs resource is updated/created in order to calculate one-to-one similarities.

这是我的问题:

1. 是否有更好的方法来实现上述目标?
2. 我知道微服务架构设计中的最佳实践告诉我们数据不应该被复制，但是可以存储处理过的和有限的数据，比如原始数据的副本吗?

谢谢！

推荐答案

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

I think that the general architecture with the three services (HR, Jobs, Recommender) is fine as it clearly defines the responsibilities and separates the different functions in the system.

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

In my opinion, you should not keep any data persistently in the Recommender service. Imagine if the database schema for the HR database changes (e.g. new data field), you will perhaps have to change the recommender algorithm, but you want to change the database in only one (the HR) service, and not in both services. Imagine if for some reason the Recommender service missed an update event due to an error, you would somehow have to repair the inconsistent database state between the two services.

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

On the other hand, if you had a requirement to save on communication bandwidth between your services, you could think of keeping some data as an architectural tradeoff - but this seems improbable and would be kind of against the idea behind a microservices architecture.

这篇关于出于项目推荐目的在微服务之间共享(几乎)相同的数据是否是个坏主意的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！