问题描述
我们使用的是微服务架构，其中顶级服务用于将REST API公开给最终用户，后端服务则完成查询数据库的工作.
We are using Micro services architecture where top services are used for exposing REST API's to end user and backend services does the work of querying database.
当我们收到 1个用户请求时，我们向后端服务发出了约3万个请求.我们将RxJava用于顶级服务，因此所有30K请求都可以并行执行.我们正在使用haproxy在后端服务之间分配负载.但是，当我们收到3-5个用户请求时，我们将收到网络连接异常，主机路由无异常，套接字连接异常.
When we get 1 user request we make ~30k requests to backend service. We are using RxJava for top service so all 30K requests gets executed in parallel.We are using haproxy to distribute the load between backend services.However when we get 3-5 user requests we are getting network connection Exceptions, No Route to Host Exception, Socket connection Exception.
这种用例的最佳实践是什么?
What are the best practices for this kind of use case?
推荐答案
您最终遇到了经典的微服务混乱.您使用什么技术完全无关紧要-问题在于您应用微服务概念的方式！
Well you ended up with the classical microservice mayhem. It's completely irrelevant what technologies you employ - the problem lays within the way you applied the concept of microservices!
在这种体系结构中，服务彼此调用是很自然的(最好是异步发生！).由于我对您的服务API知之甚少，因此我不得不对后端出了什么问题做出一些假设:
It is natural in this architecture, that services call each other (preferably that should happen asynchronously!!). Since I know only little about your service APIs I'll have to make some assumptions about what went wrong in your backend:
我假设用户向一项服务提出了请求.现在，该服务将(显然是同步地)查询另一个服务，并接收您描述的这30k条记录.由于您可能需要了解更多有关这些记录的信息，因此您现在必须针对每个记录向第三服务/端点发出另一个请求，以汇总您的前端所需的所有信息！
I assume that a user makes a request to one service. This service will now (obviously synchronously) query another service and receive these 30k records you described. Since you probably have to know more about these records you now have to make another request per record to a third service/endpoint to aggregate all the information your frontend requires!
这向我表明，您可能对受限上下文的理解不正确！分析部分就这么多.现在到解决方案:
This shows me that you probably got the whole thing with bounded contexts wrong! So much for the analytical part. Now to the solution:
您的API应该返回所有信息以及枚举它们的查询！有时，这似乎与微服务模式所指定的对数据/状态的隔离和授权相矛盾-但是仅在一个服务中隔离数据/状态是不可行的，仅因为这会导致您当前遇到的问题-所有其他服务必须每次都查询该数据，以便能够将正确的数据返回给前端！但是，只要对数据/状态的权限明确，就可以复制它！
Your API should return all the information along with the query that enumerates them! Sometimes that could seem like a contradiction to the kind of isolation and authority over data/state that the microservices pattern specifies - but it is not feasible to isolate data/state in one service only because that leads to the problem you currently have - all other services HAVE to query that data every time to be able to return correct data to the frontend! However it is possible to duplicate it as long as the authority over the data/state is clear!
让我用一个例子来说明:假设您有一个经典的商店系统.文章被分组.现在您可能会编写两种微服务-一种用于处理文章的服务，一种用于处理组的服务！您这样做是对的！您可能已经决定组服务将保留与分配给组的商品的关系！现在，如果前端要显示组中的所有项目-发生了什么:组服务接收请求，并在前端接收的漂亮JSON数组中返回30'000商品编号.这就是一切的地方:前端现在必须查询从group-service收到的每篇文章的article-service ！！！ Aaand搞砸了！
Let me illustrate that with an example: Let's assume you have a classical shop system. Articles are grouped. Now you would probably write two microservices - one that handles articles and one that handles groups! And you would be right to do so! You might have already decided that the group-service will hold the relation to the articles assigned to a group! Now if the frontend wants to show all items in a group - what happens: The group service receives the request and returns 30'000 Article numbers in a beautiful JSON array that the frontend receives. This is where it all goes south: The frontend now has to query the article-service for every article it received from the group-service!!! Aaand your're screwed!
现在有多种方法可以解决此问题:一种是(如前所述)将文章信息复制到组服务:因此，每次使用组服务将文章分配给组时，都必须阅读该文章的所有信息形成文章服务并进行存储，以便能够通过 get-me-all-the-articles-in-group-x 查询返回.这相当简单，但请记住，当文章服务中的信息更改时，您将需要更新此信息，否则您将要从组服务中提供陈旧的数据.在这种用例中，事件来源可能是一个非常强大的工具，我建议您仔细阅读！您还可以使用从一项服务(在本例中为文章服务)发送到您喜欢的消息总线的简单消息，并使组服务侦听并响应这些消息.
Now there are multiple ways to solve this problem: One is (as previously mentioned) to duplicate article information to the group-service: So every time an article is assigned to a group using the group-service, it has to read all the information for that article form the article-service and store it to be able to return it with the get-me-all-the-articles-in-group-x query. This is fairly simple but keep in mind that you will need to update this information when it changes in the article-service or you'll be serving stale data from the group-service. Event-Sourcing can be a very powerful tool in this use case and I suggest you read up on it! You can also use simple messages sent from one service (in this case the article-service) to a message bus of your preference and make the group-service listen and react to these messages.
另一个解决问题的非常简单快捷的解决方案也可能是在articles服务上提供一个新的REST端点，该端点使用一组article-id并将信息返回给所有这些ID，这样会更快得多. .这可能会很快解决您的问题.
Another very simple quick-and-dirty solution to your problem could also be just to provide a new REST endpoint on the articles services that takes an array of article-ids and returns the information to all of them which would be much quicker. This could probably solve your problem very quickly.
微服务后端的一个很好的经验法则是希望获得恒定数量的这些跨服务调用，这意味着跨服务边界的调用数量绝不应与请求的数据量直接相关！我们会密切监控由于API发出的给定请求而进行的服务调用，以跟踪哪些服务调用了其他服务以及在哪里出现或引起了性能瓶颈.每当我们检测到某项服务产生了很多(没有固定的阈值，但是每次我看到> 4时，我都会开始提问！)对其他服务的呼叫，我们都会调查为什么以及如何可以解决此问题！有一些很棒的指标工具可以帮助您跨服务边界跟踪请求！
A good rule of thumb in a backend with microservices is to aspire for a constant number of these cross-service calls which means your number of calls that go across service boundaries should never be directly related to the amount of data that was requested! We closely monitory what service calls are made because of a given request that comes through our API to keep track of what services calls what other services and where our performance bottlenecks will arise or have been caused. Whenever we detect that a service makes many (there is no fixed threshold but everytime I see >4 I start asking questions!) calls to other services we investigate why and how this could be fixed! There are some great metrics tools out there that can help you with tracing requests across service boundaries!
让我知道这是否有帮助，以及您实施的任何解决方案！
Let me know if this was helpful or not, and whatever solution you implemented!
这篇关于如何在微服务架构中处理网络呼叫的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！