微服务–以最小的内存/时间损失从其他微服务中检索特定用户的相关数据的最佳实践 [英] Microservices – best practices to retrieve the related data to specific user from the other micro services with the minimal memory/time loss

问题描述

我正在尝试使用 Lumen/Laravel Passport 创建微服务架构.

I am trying to create a microservice architecture using Lumen / Laravel Passport.

我有多个dockerized服务，它们都在不同的VM中作为单独的Lumen应用程序容器运行:

I have a multiple dockerized services, which all run as an separate Lumen app container in different VMs:

• API网关服务 (与Laravel Passport集成以进行身份​​验证并请求验证以进行进一步处理)
• 聊天服务(用于消息收发/聊天室的服务)
• 新闻服务
• …(以及许多其他服务)

• API Gateway service (integrated with Laravel Passport for authentication & request validation to further proceeding)
• Chat Service (service for messaging/chat rooms)
• News Service
• … (and many other services)

所有这些服务都有自己的独立Redis/MySQL数据库等.

All of this services has it’s own separated Redis/MySQL databases e.t.c.

例如，在整体应用程序中，数据库中存在一个User表，表之间存在关系，依此类推.我已经使用JOIN和其他查询根据当前用户ID的逻辑选择来检索数据.

In monolithic application, for example, there was a User table in the database, there was the relations between the tables and so else. I have used JOINs and other queries to retrieve data according to the logical selection for the current user id.

但是例如，现在我在移动/Web应用程序中有一个常规页面，我必须从一个当前可见页面的不同服务中获取多个信息.

But now I have a general page in the Mobile/Web app for example and I must to get the multiple information from different services for one current visible page.

要接收此数据，我需要在不同的服务中发送多个请求

And to receive this data I am sending multiple requests in the different services

问题:

使用微服务体系结构存储用户信息的最佳/正确做法是什么，以最小的内存/时间损失从其他微服务中检索与此用户相关数据的正确方法是什么? 以及将用户信息(例如ID，电话等)存储在何处以避免数据复制?

What is the best/correct practice to store user information using microservices architecture and what is the correct way to retrieve the related data to this user from the other micro services with the minimal memory/time loss? And where to store users information like id, phones e.t.c to avoid the data dublication?

很抱歉可能会出现重复.试图了解..

Sorry for possible dublicate. Trying to understand..

推荐答案

假设您有以下服务:MS1，MS2，MS3，MS4.该Web应用程序/移动应用程序会单击MS1以获得信息.现在，MS1需要返回一个包含由MS2，MS3和MS4管理的数据的响应.

Let's say you have services: MS1, MS2, MS3, MS4. The web app / mobile app hits MS1 for information. Now MS1 needs to return a response containing data that are managed by MS2, MS3 and MS4.

糟糕的解决方案-MS1调用MS2，MS3和MS4来检索信息，对其进行汇总并返回最终的汇总数据

Poor Solution - MS1 calls MS2, MS3 and MS4 to retrieve information, aggregates them and returns the final aggregated data

1. 在DB通过各自的服务更新时，使用基于日志的更改数据捕获(CDC)从MS2，MS3和MS4数据库生成事件

1. Use log-based change data capture (CDC) to generate events from databases of MS2, MS3 and MS4 as and when the DBs are updated by their respective services

将事件发布到流媒体平台(例如Kafka)的一个或多个主题

Post the events to one or more topics of a streaming platform (e.g. Kafka)

使用流处理，处理事件并为MS1的缓存和DB中的每个用户创建聚合数据

Using stream processing, process the events and create the aggregated data for each user in cache and DB of MS1

处理从MS1的缓存和/或DB向MS1发出的请求

Serve the requests to MS1 from the cache and / or DB of MS1

请注意，使用这种方法，缓存或数据库将具有预先聚合的数据，这些数据将通过事件和流处理保持最新状态.更新可能会略有滞后，从而导致服务过时的数据.但是在正常情况下，延迟不应超过几秒钟.

Note, with this approach, the cache or DB will have pre-aggregated data which will be kept up-to-date by the event and stream processing. The updates may lag a little resulting in serving stale data. But the delay shouldn't be more than a few seconds in normal circumstances.

如果所有用户数据都可以存储在缓存中，则可以将整个数据集保留在缓存中.否则，您可以使用TTL将数据的子集保留在缓存中.可以驱逐最近最少使用的数据，以便为新条目腾出空间.除非缓存中尚不可用，否则该服务将从数据库中检索数据.

If all the user data can be stored in cache, you can keep the entire data set in cache. Otherwise, you can keep a subset of data in cache with a TTL. The least recently used data can be evicted to make space for new entries. The service will retrieve data from the DB unless itbis not already available in cache.

优势:

1. 由于响应是预先计算的，延迟将不会改善用户体验
2. 消除了与其他微服务的紧密耦合.因此，即使MS2，MS3或MS4暂时关闭，您的用户仍然可以看到数据，尽管有些陈旧，但是在大多数情况下，这比延迟响应或错误消息更好.

这篇关于微服务–以最小的内存/时间损失从其他微服务中检索特定用户的相关数据的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！