好吧，您最终遇到了经典的微服务混乱。这与您采用什么技术完全无关——问题在于您应用微服务概念的方式！
在这种架构中，服务相互调用是很自然的（最好是异步发生！！）。由于我对您的服务 API 知之甚少，因此我不得不对您的后端出了什么问题做出一些假设：
我假设用户向一项服务发出请求。该服务现在将（显然是同步的）查询另一个服务并接收您描述的这 30k 条记录。由于您可能需要了解更多关于这些记录的信息，因此您现在必须针对每条记录向第三个服务/端点发出另一个请求，以汇总您的前端所需的所有信息！
这表明你可能把bounded contexts 弄错了！分析部分就这么多。现在来解决：
您的 API 应该返回所有信息以及枚举它们的查询！有时这似乎与微服务模式指定的对数据/状态的隔离和权限的类型相矛盾 - 但仅在一个服务中隔离数据/状态是不可行的，因为这会导致您当前遇到的问题 - 所有其他服务必须每次都查询该数据才能将正确的数据返回到前端！但是，只要对数据/状态的权限明确，就可以复制它！
让我用一个例子来说明这一点：假设你有一个经典的商店系统。文章被分组。现在你可能会编写两个微服务——一个处理文章，一个处理组！你这样做是对的！您可能已经决定 group-service 将保存与分配给组的文章的关系！现在，如果前端想要显示组中的所有项目 - 会发生什么：组服务接收请求并在前端接收到的漂亮 JSON 数组中返回 30'000 个文章编号。这就是一切都向南的地方：前端现在必须查询文章服务以获取它从组服务收到的每篇文章！！！ Aaand 你完蛋了！
现在有多种方法可以解决这个问题：一种是（如前所述）将文章信息复制到 group-service：所以每次使用 group-service 将文章分配到一个组时，它都必须读取该文章的所有信息形成文章服务并存储它以便能够使用 get-me-all-the-articles-in-group-x 查询返回它。这相当简单，但请记住，当它在文章服务中发生更改时，您需要更新此信息，否则您将提供来自组服务的陈旧数据。在这个用例和I suggest you read up on it 中，事件溯源可能是一个非常强大的工具！您还可以使用从一个服务（在本例中为文章服务）发送到您偏好的消息总线的简单消息，并让组服务侦听这些消息并做出反应。
另一个针对您的问题的非常简单的快速而简单的解决方案也可能只是在文章服务上提供一个新的 REST 端点，该端点采用文章 ID 数组并将信息返回给所有这些端点，这样会更快.这可能会很快解决您的问题。
在使用微服务的后端中，一个好的经验法则是希望这些跨服务调用的数量保持不变，这意味着跨越服务边界的调用数量永远不应与请求的数据量直接相关！我们密切监视由于通过我们的 API 发出的给定请求而进行了哪些服务调用，以跟踪哪些服务调用了哪些其他服务以及我们的性能瓶颈将在哪里出现或已经引起。每当我们检测到一个服务产生了很多（没有固定的阈值，但每次我看到 >4 我都会开始提问！）调用其他服务时，我们会调查为什么以及如何解决这个问题！有一些很棒的指标工具可以帮助您跨服务边界跟踪请求！
让我知道这是否有用，以及您实施的任何解决方案！