微服务架构:跨服务数据共享 [英] 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.

每个服务都提供一个用户界面，用于查看和管理其相关实体.采购服务索引页面列出了采购.每个采购项目应具有以下字段:
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.

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

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，它根据给定的 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 服务.采购服务管理采购.每个处理它自己的数据并且只处理它需要的数据(例如，Purchase 服务并不真正需要用户名，只需要 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屋！