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