Hello,大家好,最近两周一直在加班,9106 的节奏的,真的是累成狗了。不过最近项目进入提测,就稍微闲了一点。
上周的时候,看了一场架构师之路沈剑老师的一场直播,最近又重温了一下,根据自己的认知总结了一下,分享给大家。
MQ 想必大家或多或少都用过,接入 MQ 之后的整体架构如下:
可以看到使用 MQ 之后,上下游通信就变成图上的这种方式。
这种跨进程的通信方式,我们还有一种常用的解决方案,使用 Dubbo 等这类 RPC 服务。
理论上使用 RPC 的跨进程通信的场景,使用 MQ 也能解决,当然反过来也能说通。
那为什么不都用 RPC,或者 MQ 来解决那?
这其实都是业务场景决定的,抛开业务场景来谈架构都是耍流氓!没有全能的架构,只要适合的架构。
下面我们来看看那些场景适合 RPC,而那些场景适合 MQ。
使用 RPC 的场景一般都是上有服务需要实时依赖下游服务的返回。
我们以一个登录服务为例,架构图如下:
用户发起的登录请求首先由对外的 WEB 服务接受,然后 WEB 服务服务调用用户服务查询用户信息,然后比对用户密码。
也就是说我们的 WEB 应用需要实时依赖用户服务返回的用户信息,如果没有返回,这次登录将会失败。
假如这个场景我们用 MQ 代替, WEB 应用发送 MQ 消息之后,然后流程就结束了,此时 WEB 应用无法拿到用户信息。
所以说对于这种需要强依赖下游返回的场景,使用 MQ 将会带来以下不足:
举个例子,在我们第三方支付系统中,每支付成功一笔,都需要计算手续费。
这个场景我们显然可以使用 RPC 完成调用,但是实际上,支付系统是不关心的计费系统的结果,两个系统不存在直接强依赖的关系。
大家可以想象一下,用户实际上已经收到银行卡扣款短信了,但是支付系统因为计费系统失败,导致对外返回是失败的结果。这对于用户来讲,不能接受啊。我都付钱了,你却告诉我支付异常。
所以对于这种场景,直接使用 RPC 调用由以下几点不足:
那一定要用 MQ 解决吗?
其实不一定,对于我们上面举的场景,我们其实可以使用异步 RPC 或者线程池异步调用 RPC 就可以解决。
毕竟增加一个 MQ, 系统就变得更加复杂,我们还要单独运维 MQ,这对于小团队来讲,工作量还是很大的。
但是这种方式,还是解决不了,增加一个下游系统,上游系统还要改动的代码囧境。
增加 MQ 解耦
这个场景使用 MQ 解耦,带来几点优点:
举个例子,支付公司每日都需要对账,主要目的是核实自己系统的应收的钱与支付渠道端是否一致,主要流程分为以下几步:
上面的定时任务使用 Spring-Schedule 调度,假设各个定时任务下载时间如下所示:
上图中三个任务,任务二需要依赖任务一完成,而任务三有需要依赖任务二完成。
我们之前使用这种模式,通常会碰到几个问题:
使用 MQ解耦
使用 MQ 解耦之后架构图如下:
这种方式,只要任务一的定时任务准时启动,任务一完成之后发送 MQ 消息,任务二收到之后就会启动任务,结束之后再发送消息给 MQ。任务三流程同任务二
使用这种方式存在优点为:
对于上游需要关注下游返回结果的场景,不适合使用 MQ。
适合使用 MQ 的场景有:
本文首发于: https://studyidea.cn/articles/2020/07/26/1595751010913.html
欢迎关注我的公众号:小黑十一点半,获得日常干货推送。如果您对我的专题内容感兴趣,也可以关注我的博客:studyidea.cn