我们正在使用微服务架构，其中顶级服务用于向最终用户公开REST API，后端服务用于查询数据库。
当我们收到 1个用户请求时，我们会向后端服务提出~30k请求。我们使用RxJava进行顶级服务，因此所有30K请求都是并行执行的。 我们使用haproxy在后端服务之间分配负载。 但是，当我们得到3-5个用户请求时，我们将获得网络连接异常，没有路由到主机异常，套接字连接异常。
此类用例的最佳做法是什么？
答案 0 :(得分：15)
嗯，你最终得到了经典的微服务混乱。与您采用的技术完全无关 - 问题在于您应用微服务的概念！
在这种架构中很自然，服务相互调用（最好是异步发生!!）。由于我对您的服务API知之甚少，因此我必须对您后端出现的问题做出一些假设：
我假设用户向一个服务发出请求。此服务现在（显然是同步）查询另一个服务并接收您描述的这些30k记录。由于您可能需要了解有关这些记录的更多信息，因此您现在必须为每个记录向第三个服务/端点发出另一个请求，以汇总您的前端需要的所有信息！
这告诉我你可能错过了bounded contexts整件事！对分析部分来说太多了。现在来解决方案：
您的API应该返回所有信息以及枚举它们的查询！有时，这似乎与微服务模式指定的数据/状态的隔离和权限相矛盾 - 但仅在一个服务中隔离数据/状态是不可行的，因为这会导致您目前遇到的问题 - 所有其他服务每次都能查询该数据，以便能够将正确的数据返回到前端！但是，只要数据/状态的权限明确，就可以复制它！
让我用一个例子来说明：让我们假设你有一个经典的商店系统。文章分组。现在你可能会写两个微服务 - 一个处理文章，一个处理组！你这样做是对的！您可能已经确定组服务将保留与分配给组的文章的关系！现在，如果前端想要显示组中的所有项目 - 会发生什么：组服务接收请求并在前端接收的漂亮JSON数组中返回30'000个文章编号。这就是它向南走的地方：前端现在必须查询文章服务，查看从集团服务收到的每篇文章！ Aaand你搞砸了！
现在有多种方法可以解决这个问题：一种是（如前所述）将文章信息复制到组服务：因此，每次使用组服务将文章分配给组时，都必须阅读该文章的所有信息都构成了文章服务并存储它，以便能够使用 get-me-all-the-articles-in-group-x 查询返回它。这很简单，但请记住，当文章服务中的更改或您将从组服务中提供过时数据时，您需要更新此信息。 Event-Sourcing在这个用例和I suggest you read up on it中可以是一个非常强大的工具！您还可以使用从一个服务（在本例中为文章服务）发送的简单消息到您偏好的消息总线，并使组服务监听并对这些消息做出反应。
另一个非常简单的快速解决问题的解决方案也可能只是在文章服务上提供一个新的REST端点，它接受一系列文章ID并将信息返回给所有这些，这样会更快。这可能很快就能解决你的问题。
在具有微服务的后端中，一个好的经验法则是希望获得一定数量的跨服务调用，这意味着跨越服务边界的调用数量永远不应与请求的数据量直接相关！我们密切监控服务电话是由于通过我们的API提供的给定请求来跟踪哪些服务称为其他服务以及我们的性能瓶颈将在何处产生或引起的。每当我们检测到服务产生许多（没有固定的阈值，但每次我看到＆gt; 4我开始提问！）调用其他服务时，我们会调查为什么以及如何解决这个问题！有一些很棒的度量工具可以帮助您跨服务边界跟踪请求！
让我知道这是否有用，以及您实施的解决方案！