消息队列解决的问题：
各服务同步通信时：
服务即是("创建订单","扣减库存")这些步骤。
比如下图中的电商订单系统为例，如果各服务之间使用同步通信，不仅耗时较久并且过程中受到网络波动的影响较大，不能保证高成功率。
分析：
(1) 用户进入点击下订单操作，然后会请求到后台服务器，后台服务器会进行一系列的操作，如："创建订单"，"扣减库存"等，每一个步骤
其实都可以看作为一个微服务模块
(2) 耗时久：每一个微服务模块微服务都是同步执行的，进行完上一个微服务模块才会接着下一个。这样一层层的处理完毕之后，并且全
部成功后，才会返回"下单成功" 给用户。这样耗时是十分久的
(3) 网络波动影响较大并且不能保证高成功率 ：对于网络通信来说。网络始终是不可靠的，每一个步骤对应的每一个微服务模块都可能受
到网络动荡影响而失败。只要有一个步骤执行失败，那么整个下单过程就失败，就不能保证高成功率
(4) 总结：对于用户来说：下一个单，耗时久，成功率不能保证，本来就是极差的用户体验。
如下图所示：各服务同步通信实现下单操作：
因此，我们要使用异步的通信方式对架构进行改造。
各服务异步通信时：
服务即是("创建订单","扣减库存")这些步骤。
(1)上游执行完下订单消息的发送给消息队列的业务后立即获得到下单成功的结果。用户体验好，成功率高 有保证 ！
分析：用户进入并且下订单，此时不会直接把请求打到后台服务器而是发送一条Message给消息队列，此Message消息包含商品id，
商品数量，创建订单的时间等一系列商品的有关信息。当发送给消息队列的业务执行完毕后，用户会立即获得到"下单成功"的结果。其实
此时用户的下单的业务流程并没有执行完，甚至还没有执行，这就是消息队列的好处。
(2)使用异步的通信方式对微服务模块间的调用进行解耦。下游多个服务订阅到消息后各自消费。通过消息队列，屏蔽底层的通信协议，使
得解耦和并行消费消息队列中的Message得以实现。并且提高了下单的成功率 ！
分析：下游的每一个下单的步骤都会对应一个微服务模块，每一个模块都会订阅消息队列中的Message消息，消息队列会把Message
按一定的规则发送给订阅者，这样各个步骤(如："创建订单"，"扣减库存"等等)对应的微服务模块会互不干扰 解耦性的消费消息并且执行
下单的逻辑。即使说有一个步骤执行失败，那么也不会使得整个流程停滞不前，而是解耦性的执行 互不干扰 ！
(3) 可以快速的提升系统的吞吐量。
分析：如果具有了消息队列，那么我们的后台服务器系统就无需实时的进行执行下单的流程操作。实时是什么意思？实时就是当一个
用户执行下单操作之后，后台服务器就必须此刻立即执行该请求的下单操作流程。由于具有了消息队列，可以把发送过来的消息先存放到
消息队列中，后台可以一条一条的，有规律性的处理这些请求的消息，所以自然系统的吞吐量就提升了 ！
如下图所示：各服务异步通信+消息队列实现下单操作：
