在微服务架构中，有两种方式可以在微服务之间进行通信：

• 同步-也就是说，每个服务直接调用另一个微服务，这导致服务之间的依赖性
• 异步--你有一些中央集线器（或消息队列），你将所有请求放在微服务之间，相应的服务接受请求，处理它并将结果返回给调用者。这就是RabbitMQ（或任何其他消息队列- MSMQ和Apache Kafka是很好的替代品）的用途。在这种情况下，所有微服务都只知道中心的存在。

microservices.io有一些关于使用微服务的非常好的文章

消息队列提供异步通信协议-您可以选择将消息从一个服务发送到另一个服务，而不必知道另一个服务是否能够立即处理它。消息可以等待，直到负责的服务准备就绪。发布消息的服务不需要知道任何关于将处理该消息的服务的内部工作方式的信息。这种处理消息的方式将生产者与消费者分离。
消息队列将使应用程序中的进程相互分离和独立;这种处理消息的方式可以创建一个易于维护和扩展的系统。
简单地说，两个明显的例子可以用来说明消息队列何时真正闪耀：
1.对于长时间运行的进程和后台作业
1.作为微服务之间的中间人

• • 对于长时间运行的进程和后台作业：**

当请求花费大量时间时，最好合并一个消息队列。
设想一个Web服务每秒处理多个请求，并且在任何情况下都不会丢失一个请求。此外，请求是通过耗时的过程来处理的，但系统不能陷入困境。一些现实生活中的例子可能包括：

• 图像缩放
• 发送大量/许多电子邮件（如电子报）
• 搜索引擎索引
• 文件扫描
• 视频编码
• 传送通知
• PDF处理
• 计算
• • 微服务中间人：**

对于应用程序内部和之间的通信和集成，即作为微服务之间的中间人，消息队列也很有用。考虑一个系统，它需要通知系统的另一部分开始处理一个任务，或者当同时有很多请求进来时，如以下场景所示：

• 订单处理（下订单、更新订单状态、发送订单、付款等）
• 送餐服务（下订单、准备订单、送餐）
• 需要处理多个请求的任何Web服务

Here是一个解释Parkster（一个数字停车服务）如何通过使用RabbitMQ将他们的系统分解为多个微服务的故事。
This guide遵循Web应用程序允许用户将信息上载到Web站点的场景。该网站将处理这些信息，并生成一个PDF，并通过电子邮件将其发送回用户。在本例中，处理信息、生成PDF和发送电子邮件将花费几秒钟，这也是使用消息队列的原因之一。
Here是一个关于CloudAMQP如何以及为什么在微服务之间使用消息队列和RabbitMQ的故事。
Here是一个关于在基于事件的微服务架构中使用RabbitMQ以每月支持1亿用户的故事。
最后是Kontena的link，关于他们为什么选择RabbitMQ作为他们的微服务架构：因为我们需要一个稳定、可管理且高度可用的消息传递解决方案。
请注意，我为CloudAMQP（RabbitMQ的托管提供商）背后的公司工作。

同样的问题可能是为什么REST对于微服务是必要的？微服务概念在月球下并不是什么新鲜事。工作流的长时间分布用于后端工程和异步请求处理，微服务是与SOLID中的S（单一责任）匹配的单独JVM中的相同组件。是什么让它微服务-是它是平衡的。这就是全部！特别是（！），它可以是Spring Cloud/REST基础上的REST服务，由Eureka 注册，具有代理网关和Zuul和Ribbon上的负载平衡。但这并不是微服务的全部！顺便说一下，异步分布式处理是微服务用于的任务之一。很久以前，分离的JVM中的服务（组件）被集成在任何消息中，这种模式被称为ESB。微服务是相同的主题模式。由于Spring Cloud的流行，REST似乎是微服务的唯一方式。不！例如，Vertx https://dzone.com/articles/asynchronous-microservices-with-vertx支持基于消息的异步微服务架构。为什么不使用RabbitMQ作为消息通道？在这种情况下，可以通过构建RabbitMQ集群来提供负载均衡。例如：https://codeburst.io/using-rabbitmq-for-microservices-communication-on-docker-a43840401819。所以，世界更广阔。

Rabbit MQ提供异步通信。当我们需要同时发布大量事件时，很难同时存储在数据库中。事件发布后，它将发送到MQ。从MQ它将被多个消费者使用，您也可以根据配置在MQ中存储数据几天。Rabbit MQ最适合微服务级别的基于事件的方法。例如：订单创建和取消。