阿粉最近看了一场架构师之路沈剑老师的一场直播,最近又重温了一下,根据自己的认知总结了一下,分享给大家。
MQ 想必大家或多或少都用过,接入 MQ 之后的整体架构如下:
可以看到使用 MQ 之后,上下游通信就变成图上的这种方式。
这种跨进程的通信方式,我们还有一种常用的解决方案,使用 Dubbo 等这类 RPC 服务。
理论上使用 RPC 的跨进程通信的场景,使用 MQ 也能解决,当然反过来也能说通。
那为什么不都用 RPC,或者 MQ 来解决那?
这其实都是业务场景决定的,抛开业务场景来谈架构都是耍流氓!没有全能的架构,只要适合的架构。
下面我们来看看那些场景适合 RPC,而那些场景适合 MQ。
RPC 场景
使用 RPC 的场景一般都是上游服务需要实时依赖下游服务的返回。
我们以一个登录服务为例,架构图如下:
用户发起的登录请求首先由对外的 WEB 服务接受,然后 WEB 服务服务调用用户服务查询用户信息,然后比对用户密码。
也就是说我们的 WEB 应用需要实时依赖用户服务返回的用户信息,如果没有返回,这次登录将会失败。
假如这个场景我们用 MQ 代替