day06-MQ基础

用户7020

131360

454587

152

898

🏖️

号外号外！现在点击​黑马试学，添加黑马老师即可领取多套试学课程。还可以预约1V1职业规划咨询帮你找准定位、不再盲目。赶快行动起来吧！​

对应B站视频：

微服务一旦拆分，必然涉及到服务之间的相互调用，目前我们服务之间调用采用的都是基于OpenFeign的调用。这种调用中，调用者发起请求后需要等待服务提供者执行业务返回结果后，才能继续执行后面的业务。也就是说调用者在调用过程中处于阻塞状态，因此我们称这种调用方式为同步调用，也可以叫同步通讯。但在很多场景下，我们可能需要采用异步通讯的方式，为什么呢？​

我们先来看看什么是同步通讯和异步通讯。如图：

common.docs_name - LarkCCM_Docs_Menu_Image

解读：

•
同步通讯：就如同打视频电话，双方的交互都是实时的。因此同一时刻你只能跟一个人打视频电话。​

•
异步通讯：就如同发微信聊天，双方的交互不是实时的，你不需要立刻给对方回应。因此你可以多线操作，同时跟多人聊天。​

两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。发微信可以同时与多个人收发微信，但是往往响应会有延迟。​

所以，如果我们的业务需要实时得到服务提供方的响应，则应该选择同步通讯（同步调用）。而如果我们追求更高的效率，并且不需要实时响应，则应该选择异步通讯（异步调用）。​
 ​

同步调用的方式我们已经学过了，之前的OpenFeign调用就是。但是：​

•
异步调用又该如何实现？​

•
哪些业务适合用异步调用来实现呢？​

通过今天的学习你就能明白这些问题了。

1.初识MQ

1.1.同步调用

之前说过，我们现在基于OpenFeign的调用都属于是同步调用，那么这种方式存在哪些问题呢？​

举个例子，我们以昨天留给大家作为作业的余额支付功能为例来分析，首先看下整个流程：​

画板

目前我们采用的是基于OpenFeign的同步调用，也就是说业务执行流程是这样的：​

•
支付服务需要先调用用户服务完成余额扣减​

•
然后支付服务自己要更新支付流水单的状态​

•
然后支付服务调用交易服务，更新业务订单状态为已支付​

三个步骤依次执行。

这其中就存在3个问题：

第一，拓展性差

我们目前的业务相对简单，但是随着业务规模扩大，产品的功能也在不断完善。​

在大多数电商业务中，用户支付成功后都会以短信或者其它方式通知用户，告知支付成功。假如后期产品经理提出这样新的需求，你怎么办？是不是要在上述业务中再加入通知用户的业务？​

某些电商项目中，还会有积分或金币的概念。假如产品经理提出需求，用户支付成功后，给用户以积分奖励或者返还金币，你怎么办？是不是要在上述业务中再加入积分业务、返还金币业务？​

day06-MQ基础​

day06-MQ基础