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

Question

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

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

API网关服务
(与 Laravel Passport 集成以进行身份​​验证和请求验证以进一步处理)

聊天服务(消息/聊天室服务)

新闻服务

...(以及许多其他服务)

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

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

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

为了接收这些数据，我在不同的服务中发送了多个请求

问题:

使用微服务架构存储用户信息的最佳/正确做法是什么，以及以最小的内存/时间损失从其他微服务中检索该用户的相关数据的正确方法是什么？
以及在哪里存储用户信息(如 ID、电话等)以避免数据重复？

抱歉可能重复。试图理解..

Answer 1

假设您有服务:MS1、MS2、MS3、MS4。网络应用程序/移动应用程序点击 MS1 获取信息。现在 MS1 需要返回一个包含由 MS2、MS3 和 MS4 管理的数据的响应。

糟糕的解决方案 - MS1 调用 MS2、MS3 和 MS4 来检索信息、聚合它们并返回最终聚合的数据

推荐方案

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

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

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

从 MS1 的缓存和/或 DB 向 MS1 提供请求

请注意，使用这种方法，缓存或数据库将具有预先聚合的数据，这些数据将通过事件和流处理保持最新。更新可能会稍微滞后，导致提供陈旧的数据。但在正常情况下，延迟应该不会超过几秒钟。

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

好处:

由于响应是预先计算的，因此延迟将减少改善用户体验

消除了与其他微服务的紧密耦合。因此，即使 MS2、MS3 或 MS4 暂时关闭，您的用户仍然可以看到数据，尽管有点陈旧，但在大多数情况下，这比延迟响应或错误消息要好。