基于消息的微服务 - Api 网关性能

Question

我正在设计微服务架构，我有一个与性能相关的问题。这就是我正在尝试的设计：

• 我有几个微服务，它们执行不同的操作并将这些结果存储在它们自己的数据存储中。
• 微服务通过消息队列接收工作，在该消息队列中它们接收请求以针对给定的特定数据运行其进程。微服务不相互通信。

• 我有一个 API 网关，它实际上包含三个旅程：

  1) 接收处理数据的请求，然后将其转换为几条消息，将这些消息放入队列中，以便微服务在自己的时间进行处理。处理时间可以是几分钟或更长时间（非即时）

  2) 接收进程状态请求，返回整个进程的进度。

  3) 接收对组合数据的请求，该请求是来自服务的所有结果的某种组合。

我的问题在于上面的#3 和这个过程的性能。

每当收到此请求时，api网关必须将消息请求放入队列中以获取来自所有服务的信息，而不是等待所有服务回复其数据的最新状态，然后合并此数据并返回给调用者。

这个过程显然很慢，因为它必须等待每个服务响应。加快速度的方法是什么？

我想解决这个问题的唯一方法是拥有另一个聚合服务/数据存储，其中重复数据由我的 api 网关存储和查询。我真的不喜欢这种方法，因为它会复制数据并且是额外的工作/代码。

从我的微服务中查询最新数据的“正确”和高效方式是什么。

Answer 1

您可以使用这些方法跨微服务查询数据。 Reference
选择性数据复制

通过这种方法，我们将其他微服务所需的数据复制到我们微服务的数据库中。微服务之间唯一的耦合在于数据复制配置。

复合服务层 通过这种方法，您可以引入从较低级别的微服务聚合数据的复合服务。