异步 HTTP 请求与新线程上的 HTTP 请求

Question

我有2个微服务（A和B）。

有一个接受POST请求的endpoint。当用户发出发布请求时，会发生以下情况:

1. 服务A从POST请求正文中获取对象并将其存储在数据库中。
2. 服务A将对象转换为不同的对象。新对象通过泽西HTTP客户端发送到服务B。

步骤 2 发生在我创建的 Java 线程池（Executors.new缓存线程池）上。通过在新线程上执行步骤 2，服务 A 的终结点的响应时间不受影响。

但是，如果服务B需要很长时间来响应，那么当服务A接收到许多POST请求时，它可能会创建太多的线程。为了帮助解决这个问题，我可以使用一个固定的线程池(Exectuors.newFixedThreadPool)。

除了固定线程池，我还应该使用异步非阻塞HTTP客户端吗？比如这里的：https://hc.apache.org/httpcomponents-asyncclient-dev/.我使用的泽西HTTP客户端是阻塞的。

使用异步 HTTP 客户端似乎是正确的。但是，如果我切换到固定线程池，我认为异步HTTP客户端不会提供显着的好处 - 我这样想错了吗？

Answer 1

使用非阻塞HTTP-Client的原因是为了防止过多的CPU被用于线程切换。如果您已经通过限制后台线程的数量解决了这个问题，那么非阻塞IO不会提供任何明显的好处。

您的设置还有另一个问题:它非常容易受到DDOS攻击(有意或无意的)。如果某人非常频繁地调用您的服务，将会在内部产生巨大的工作负载，使服务长时间处于繁忙状态。您肯定需要限制后台任务队列(这是Executor类的一个受支持的特性),如果有太多未完成的任务，则返回503(或等效的)。

Answer 2

不同之处在于，对于同步客户端，步骤A线程将连接到步骤2endpoint并等待响应。使步骤2的实现异步化，直接返回200（或其他）将有助于减少等待时间；但它仍将进行连接并等待响应。

用非阻塞客户端代替，步骤A调用本身将由另一个线程来完成。所以一切都是从第一步开始解开的。此外，系统可以将该线程用于其他事情，直到它从步骤B获得响应并需要恢复工作。

其思想是，源线程将不会空闲太多时间等待响应，而是在这段时间内被重用以完成其他工作。

Answer 3

即使您使用固定线程池，其中的所有线程也会在第2步被阻塞，这意味着它们不会做任何有意义的工作——只需等待您的API返回一个非实用资源管理的响应即可。在这种情况下，您将能够处理有限数量的传入请求，因为线程池中的线程总是很忙，而不是处理新请求。

在非阻塞客户机的情况下，您只阻塞了一个负责发送和等待所有请求/响应的线程(让我们称之为dispatcher thread)。它将在一个“while循环”(您可以称之为事件循环)中运行，并检查是否所有的包都作为响应被接收，以便它们为工作线程的拾取做好准备。

在后一个场景中，您将获得更多可用线程，准备执行一些有意义的工作，因此吞吐量将增加。