微服务–以最小的内存/时间损失从其他微服务中检索特定用户的相关数据的最佳实践

Question

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

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

• API网关服务 （与Laravel Passport集成以进行身份​​验证和请求验证，以进行进一步处理）
• 聊天服务（消息传递/聊天室服务）
• 新闻服务
• …（以及许多其他服务）

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

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

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

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

问题：

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

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

Answer 1

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

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

推荐的解决方案

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

2. 将事件发布到流媒体平台（例如Kafka）的一个或多个主题

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

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

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

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

优势：

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

Answer 2

您可能需要研究客户端应用程序内部的缓存层。您不想破坏您的封装，但是将这些信息缓存在尽可能靠近使用的地方将对优化微服务的聊天性产生巨大的影响。不过，请确保您最终创建的是缓存，而不是分布式存储。缓存仍将需要重新验证以及到期时间轴。