微服务架构:跨服务数据共享 [英] Microservices Architecture: Cross Service data sharing

问题描述

为在线商店项目考虑以下微服务:
用户服务保留有关商店用户的帐户数据(包括名字，姓氏，电子邮件地址等)

Consider the following micro services for an online store project:
Users Service keeps account data about the store's users (including first name, last name, email address, etc')

购买服务跟踪有关用户购买的详细信息.

Purchase Service keeps track of details about user's purchases.

每个服务都提供一个用于查看和管理其相关实体的UI. 采购服务索引页面列出了采购.每个购买项目应具有以下字段:
id，购买用户的全名，购买的商品标题和价格.
此外，作为索引页面的一部分，我想有一个搜索框，让商店经理可以通过购买用户名来搜索商品.

Each service provides a UI for viewing and managing it's relevant entities. The Purchase Service index page lists purchases. Each purchase item should have the following fields:
id, full name of purchasing user, purchased item title and price.
Furthermore, as part of the index page, I'd like to have a search box to let the store manager search purchases by purchasing user name.

我不清楚如何获取购买服务不持有的数据，例如:用户的全名. 当尝试通过购买用户名进行更复杂的事情(如搜索购买)时，问题变得更加严重.

It is not clear to me how to get back data which the Purchase Service does not hold - for example: a user's full name. The problem gets worse when trying to do more complicated things like search purchases by purchasing user name.

我认为，通过在创建用户时广播某种事件(并仅在Purchase Service端仅保存相关的用户属性)，可以在两个服务之间同步用户，从而显然可以解决此问题.在我看来，这远非理想.当您拥有数百万个用户时，您将如何处理?您会在每个消耗用户数据的服务中创建数百万条记录吗?

I figured that I can obviously solve this by syncing users between the two services by broadcasting some sort of event on user creation (and saving only the relevant user properties on the Purchase Service end). That's far from ideal in my perspective. How do you deal with this when you have millions of users? would you create millions of records in each service which consumes users data?

另一个明显的选择是在用户服务端公开一个API，该API根据给定的ID带回用户详细信息.这意味着购买服务中的每个页面加载，我都必须打电话给用户服务，以获取正确的用户名.不理想，但我可以忍受.

Another obvious option is exposing an API at the Users Service end which brings back user details based on given ids. That means that every page load in the Purchase Service, I'll have to make a call to the Users Service in order to get the right user names. Not ideal, but I can live with it.

如何基于用户名实施购买搜索?好吧，我总是可以在用户服务端公开另一个API端点，该端点接收查询词，对用户服务中的用户名执行文本搜索，然后返回符合条件的所有用户详细信息.在采购服务处，将相关ID映射回正确的名称，并在页面中显示它们.这种方法也不理想.

What about implementing a purchase search based on user name? Well I can always expose another API endpoint at the Users Service end which receives the query term, perform a text search over user names in the Users Service, and then return all user details which match the criteria. At the Purchase Service, map the relevant ids back to the right names and show them in the page. This approach is not ideal either.

我错过了什么吗?是否有另一种方法可以实现上述目的?也许我所面对的这个问题有点像代码味道?很想听听其他解决方案.

Am I missing something? Is there another approach for implementing the above? Maybe the fact that I'm facing this issue is sort of a code smell? would love to hear other solutions.

推荐答案

在进入微服务时，这似乎是一个非常普遍且核心的问题.我希望对此有一个好的答案:-)

This seems to be a very common and central question when moving into microservices. I wish there was a good answer for that :-)

关于这里已经提到的建议模式，我将使用术语数据非规范化而不是多语言持久性，因为它不一定需要使用不同的持久性技术.关键是每个服务都处理自己的数据.是的，您有数据重复，并且通常需要某种事件总线来跨服务共享数据.

About the suggested pattern already mentioned here, I would use the term Data Denormalization rather than Polyglot Persistence, as it doesn't necessarily needs to be in different persistence technologies. The point is that each service handles its own data. And yes, you have data duplication and you usually need some kind of event bus to share data across services.

还有另一种选择，它是第一种选择-将搜索本身作为单独的服务.

There's another option, which is a sort of a take on the first - making the search itself as a separate service.

因此，在您的示例中，您具有用于管理用户的User服务.采购服务管理采购.每个用户处理自己的数据，只处理其需要的数据(例如，Purchases服务实际上并不需要用户名，而仅需要ID).并且您还有第三项服务-搜索服务-使用其他服务产生的数据，并根据合并后的数据创建搜索视图".

So in your example, you have the User service for managing users. The Purchases services manages purchases. Each handles its own data and only the data it needs (so, for instance, the Purchases service doesn't really need the user name, only the ID). And you have a third service - the Search Service - that consumes data produced by other services, and creates a search "view" from the combined data.

这篇关于微服务架构:跨服务数据共享的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！