RPC和 MQ如何选择？

阿粉最近看了一场架构师之路沈剑老师的一场直播，最近又重温了一下，根据自己的认知总结了一下，分享给大家。

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

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

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

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

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

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

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

RPC 场景

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

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

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

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

假如这个场景我们用 MQ 代替