这是一个很好的问题。要回答这个问题，您必须想象服务器一次只运行一个线程。通过RestTemplate向微服务发出请求是一个阻塞请求。用户单击网页上的一个按钮，这将触发microservice 1中的spring-boot方法。在该方法中，您向microservice 2发出请求，microservice 1执行阻塞等待响应。
该线程正忙于等待microservice 2完成请求。线程并不昂贵，但在非常繁忙的服务器上，它们可能是一个限制因素。
RabbitMQ允许microservice 1将消息排队到microservice 2，然后释放线程。您的接收消息将由系统触发（spring-boot / RabbitMQ），当microservice 2处理消息并提供响应时，线程池中的该线程可以同时处理其他用户的请求，当RabbitMQ响应到来时，线程池使用未使用的线程来处理请求的剩余部分。
实际上，您是在让运行microservice 1的服务器在更多的时间里有更多的线程可用，只有当服务器负载过重时，这才会成为问题。

好问题，我们一个一个来讨论

同步行为：

• 客户端发送HTTP或任何请求并等待HTTP响应。
  异步行为：

客户端发送请求，有另一个线程在套接字上等待响应。一旦响应到达，原始发送者被通知（通常，使用类似回调的结构）。

现在我们可以讨论阻塞与非阻塞调用

当您使用spring rest时，每个调用将启动新线程，等待响应并阻塞您网络，而非阻塞调用所有通过单线程和回推调用将返回响应，而不会阻塞网络
现在来谈谈你的问题
由于rabbitmq的异步特性，使用rabbitmq可以提高微服务的性能。

不，性能取决于你的TPS命中率，rabbitmq不会提高性能。

消息传递为您提供了两种不同类型的消息传递模型

• 同步消息传递
• 异步消息传送

使用消息传递，您将获得松散耦合和容错。

• 如果您的应用程序需要阻塞调用，如需要响应，否则无法移动，请使用Rest
• 如果您可以在没有得到响应的情况下工作，请使用非阻塞
• 如果你想设计你的应用程序松散的夫妇去与消息。

简而言之，最重要的是架构风格，您希望如何构建应用程序，性能取决于可伸缩性。
您可以将您的应用与休息和消息传递相结合，并将无阻塞与消息传递相结合。
在您的场景中，微服务1可以是rest阻塞调用，使用rest模板或web客户端和/或消息队列调用其他api，一旦获得响应，就会将rest json调用返回到您的web应用程序。

一般来说，对于微服务--尤其是面向用户的微服务，它们必须基本上是同步的，让ServiceA必须调用ServiceB是一种反模式（其又可以call ServiceC等）返回响应。该条件表明这些服务是紧密耦合的，这使得它们很脆弱。例如：如果ServiceB出现故障或过载，ServiceA也会因为自身没有故障而脱机。因此，可能会发生以下一种或多种情况：

• 在封装整个域的facade后面部署相关服务-让客户端与facade同步交互，并让facade在后台处理与多个服务的对话。
• 使用MQTT或AMQP发布在ServiceB中添加/更改的数据，并让ServiceA订阅以获取所需的内容，这样它就可以满足用户请求，而无需显式调用其他服务
• 考虑将ServiceA和ServiceB合并为一个服务，该服务可以处理请求，而不必进行外部调用

您还可以将HTTP请求从客户端发送到服务，将应用程序状态设置为waiting或类似值，并让使用应用程序从总线订阅eventSuccess或eventFail集成消息。（同样，我不喜欢）轮流进行，无论哪个服务“完成”了作业，都会发布一个集成事件，让正在收听的任何人都知道。s的初始请求，让服务在完成时直接回调应用（或使用SignalR、gRPC或...）
我们使用RabbitMQ的方式是实时集成服务，以便每个服务始终拥有自己响应所需的信息。（通常只有事件数据的一个或两个字段），但它在几秒钟内就能知道当B已经改变并且它具有响应请求所需的所有信息时（通常更少）。它只知道它所关心的（并且符合约定的）事件不时到达，并且它需要注意它们。

您也可以使用事件并使整个流程异步。在这种情况下，microservice1创建一个代表用户请求的事件，然后立即向用户返回一个请求的创建响应。然后，您可以在请求处理完成后通知用户。
我推荐Ben Stopford写的书 * 设计事件驱动系统 *。

我也问过克里斯·理查森（www.microservices.io）类似的问题，结果是：

选项1

您可以使用类似于websockets的东西，这样microservice 1就可以在完成后发送响应。
选项2
microservice 1立即响应（OK -请求被接受）。客户端反复从服务器拉取，直到状态改变。重要的是microservice 1存储了一些关于请求的状态（即初始状态“已接受，”这样客户端可以显示微调器），当你最终收到响应时（即更新状态为“完成”），这些状态会被修改。