微服务——以最小的内存/时间损失从其他微服务中检索特定用户的相关数据的最佳实践 [英] 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 集成以进行身份验证和请求验证以进一步处理)
- 聊天服务(消息/聊天室服务)
- 新闻服务
- ...(以及许多其他服务)
所有这些服务都有自己独立的 Redis/MySQL 数据库等
All of this services has it’s own separated Redis/MySQL databases e.t.c.
例如，在单体应用中，数据库中有一个用户表，表之间存在关系等等.我已经使用 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.网络应用程序/移动应用程序点击 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
使用基于日志的变更数据捕获 (CDC) 从 MS2、MS3 和 MS4 的数据库中生成事件，当数据库由其各自的服务更新时
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 的缓存和数据库中为每个用户创建聚合数据
Using stream processing, process the events and create the aggregated data for each user in cache and DB of MS1
从 MS1 的缓存和/或数据库向 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.
优点:
- 由于响应是预先计算的，因此延迟会减少改善用户体验
- 消除了与其他微服务的紧密耦合.因此，即使 MS2、MS3 或 MS4 暂时关闭，您的用户仍然可以看到数据，尽管有点陈旧，但在大多数情况下，这比延迟响应或错误消息要好.
这篇关于微服务——以最小的内存/时间损失从其他微服务中检索特定用户的相关数据的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
