一、初识 MQ
1.1 同步调用:
我们观察下,下面这个余额支付功能的流程图:

如果我们采用的是基于 OpenFeign 的同步调用,也就是说业务执行流程是这样的:
- 支付服务需要先调用用户服务完成余额扣减。
- 然后支付服务自己要更新支付流水单的状态。
- 然后支付服务调用交易服务,更新业务订单状态为已支付。
三个步骤依次执行。
这其中就存在 3 个问题:
- 拓展性差:
我们目前的业务相对简单,但是随着业务规模扩大,产品的功能也在不断完善。
在大多数电商业务中,用户支付成功后都会以短信或者其它方式通知用户,告知支付成功。假如后期产品经理提出这样新的需求,你怎么办?是不是要在上述业务中再加入通知用户的业务?
某些电商项目中,还会有积分或金币的概念。假如产品经理提出需求,用户支付成功后,给用户以积分奖励或者返还金币,你怎么办?是不是要在上述业务中再加入积分业务、返还金币业务?
最终你的支付业务会越来越臃肿:

也就是说每次有新的需求,现有支付逻辑都要跟着变化,代码经常变动,不符合开闭原则,拓展性不好。
- 性能下降:
由于我们采用了同步调用,调用者需要等待服务提供者执行完返回结果后,才能继续向下执行,也就是说每次远程调用,调用者都是阻塞等待状态。最终整个业务的响应时长就是每次远程调用的执行时长之和:

假如每个微服务的执行时长都是 50ms,则最终整个业务的耗时可能高达 300ms,性能太差了。
- 级联失败:
由于我们是基于 OpenFeign 调用交易服务、通知服务。当交易服务、通知服务出现故障时,整个事务都会回滚,交易失败。
这其实就是同步调用的级联失败问题。
不能因为短信通知、更新订单状态失败而回滚整个事务(这些都不是支付服务的主线任务)。
而要解决这些问题,我们就必须用异步调用的方式来代替同步调用。
1.2 异步调用:
异步调用方式其实就是基于消息通知的方式,一般包含三个角色:
- 消息发送者:投递消息的人,就是原来的调用方。
- 消息 Broker:管理、暂存、转发消息。
- 消息接收者:接收和处理消息的人,就是原来的服务提供方。







