MQ 想必大家或多或少都用过，接入 MQ 之后的整体架构如下：

可以看到使用 MQ 之后，上下游通信就变成图上的这种方式。

这种跨进程的通信方式，我们还有一种常用的解决方案，使用 Dubbo 等这类 RPC 服务。

理论上使用 RPC 的跨进程通信的场景，使用 MQ 也能解决，当然反过来也能说通。

那为什么不都用 RPC，或者 MQ 来解决那？

这其实都是业务场景决定的，抛开业务场景来谈架构都是耍流氓！没有全能的架构，只要适合的架构。

下面我们来看看哪些场景适合 RPC，而哪些场景适合 MQ。

RPC 场景

使用 RPC 的场景一般都是上游服务需要实时依赖下游服务的返回。

我们以一个登录服务为例，架构图如下：

用户发起的登录请求首先由对外的 WEB 服务接受，然后 WEB 服务服务调用用户服务查询用户信息，然后比对用户密码。

也就是说我们的 WEB 应用需要实时依赖用户服务返回的用户信息，如果没有返回，这次登录将会失败。

假如这个场景我们用 MQ 代替， WEB 应用发送 MQ 消息之后，然后流程就结束了，此时 WEB 应用无法拿到用户信息。

所以说对于这种需要强依赖下游返回的场景，使用 MQ 将会带来以下不足：

MQ 场景

举个例子，在我们第三方支付系统中，每支付成功一笔，都需要计算手续费。

这个场景我们显然可以使用 RPC 完成调用，但是实际上，支付系统是不关心的计费系统的结果，两个系统不存在直接强依赖的关系。

大家可以想象一下，用户实际上已经收到银行卡扣款短信了，但是支付系统因为计费系统失败，导致对外返回是失败的结果。这对于用户来讲，不能接受啊。我都付钱了，你却告诉我支付异常。

所以对于这种场景，直接使用 RPC 调用由以下几点不足：

那一定要用 MQ 解决吗？

其实不一定，对于我们上面举的场景，我们其实可以使用异步 RPC 或者线程池异步调用 RPC 就可以解决。

毕竟增加一个 MQ，系统就变得更加复杂，我们还要单独运维 MQ，这对于小团队来讲，工作量还是很大的。

但是这种方式，还是解决不了，增加一个下游系统，上游系统还要改动的代码囧境。

增加 MQ 解耦

这个场景使用 MQ 解耦，带来几点优点：

举个例子，支付公司每日都需要对账，主要目的是核实自己系统的应收的钱与支付渠道端是否一致，主要流程分为以下几步：

上面的定时任务使用 Spring-Schedule 调度，假设各个定时任务下载时间如下所示：

上图中三个任务，任务二需要依赖任务一完成，而任务三又需要依赖任务二完成。

我们之前使用这种模式，通常会碰到几个问题：

使用 MQ解耦

使用 MQ 解耦之后架构图如下：

这种方式，只要任务一的定时任务准时启动，任务一完成之后发送 MQ 消息，任务二收到之后就会启动任务，结束之后再发送消息给 MQ。任务三流程同任务二

使用这种方式存在优点为：

对于上游需要关注下游返回结果的场景，不适合使用 MQ。

适合使用 MQ 的场景有：

如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：