首先让我们来先看一个例子：
这是一个简单的用户下单购买商品的业务模型，输入端是用户，相关物料有订单和货物，相关的内部服务有业务（订单）、财务（支付）、仓储（备货）和物流（运输）。
从图中我们可以看到，用户首先向业务部门下了一个订单，业务部门根据用户提供的内容生成了一份订单给客户，并要求客户根据订单金额支付费用。此时用户会拿着订单向财务部门付款，财务部门收款后告诉业务部门，此订单的货款已经收到，业务部门通知仓储部门备货，仓储部门备货完成后通知业务部门货物已经准备完毕，再由业务部门通知物流部门去仓库取货并送给用户，最后用户签收，流程结束。
在这个流程中我们可以发现，总共十个步骤中，除了创建订单、付款和签收外，其他的用户实际上并不关心。在生活中，我们实际上是付完款就回家等着收货了。如果我们把上述四个部门看作四个微服务，并同步调用，则运算模型如下：
从图中我们可以看出，用户发起一个请求（支付货款）后，将按照顺序一步一步的执行所有的步骤，直到用户取到货物才能结束，如果这段时间比较长，则需要用户一直等待结果，直到用户等的不耐烦离开（响应超时）。先不论用户体验如何，这种模型的处理效率实在是过于低下，如果货物运送需要若干天，则业务流程就要堵塞若干天，新的业务就进不来。
如果我们设计一种新的处理模型，在用户支付完成后，把这些用户不关心的环节放到后台处理，就可以极大的提升处理效率，增加吞吐量。
如上图所示，当用户发起一个请求后（支付货款），先处理与支付相关的业务逻辑，然后立刻将处理结果（支付成功，等待收货）反馈给用户，这时用户的前台流程就告一段落了。在此之后，我们通过一种方式通知其它相关的微服务（订单、仓储、物流），告知他们要进行哪些工作。这些业务一般不需要即时反馈，因此前台人员并不需要等待他们反馈结果，可以直接接受下一个任务。
在这种模型下，我们在微服务之外引入了事件通知服务（如 AWS SNS），当微服务向通知服务发布事件时，只会向通知服务中持久化一条数据，然后微服务就执行完毕并向调用者即时反馈结果了。此后，再由事件通知服务在合适的时候远程调用其他微服务的回调函数，完成业务流程。
事件通知异步调用可以在一定程度上提升微服务的性能和吞吐量，并且各大云服务提供商都有提供类似的服务，如亚马逊云的SNS服务，腾讯云的CMQ服务，阿里云的Message Service等，都可以轻松的集成到项目当中。
但是，异步调用也存在一些不足：
1. 如果发布时发生异常，消息可能会丢失，导致业务流程永久性暂停。如：付款后未能通知业务部门，导致仓储没有备货、物流没有运输，最终用户拿不到货物。
2. 如果微服务回调函数发生异常，可能导致最终数据不一致。如：仓储备货过程出错，但是业务和物流部门都以为已经备好货了，业务部门告知用户已经开始运输，物流部门却没有取到货，最终用户依然拿不到货。然而业务部门发布的事件已经调用过物流部门的回调函数，虽然没有成功，但是发布的消息却已经被消费掉了，业务部门也没有办法重新发送事件通知给仓储，所以这件事只能线下处理（运维人员手动修改数据）。
要保证数据一致性和服务可靠性，就不得不提到消息队列和分布式事务。
“消息队列”是在消息的传输过程中保存消息的容器，我将会在下一篇中探讨消息队列的相关内容。谢谢！
转载自:https://www.cnblogs.com/TO-WW/p/7309544.html
