RPC 用着好好的?为什么还需要使用 MQ?

Posted Java极客技术

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了RPC 用着好好的?为什么还需要使用 MQ?相关的知识,希望对你有一定的参考价值。

每天早上七点三十,准时推送干货

Photo by Vincent van Zalinge on Unsplash

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

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

RPC 用着好好的?为什么还需要使用 MQ?

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

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

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

那为什么不都用 RPC,或者 MQ 来解决那?

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

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

RPC 场景

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

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

RPC 用着好好的?为什么还需要使用 MQ?

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

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

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

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

  • 上游无法直接得到下游结果
  • 增加一个 MQ 组件,系统更复杂

MQ 场景

上游不关心下游结果的场景

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

RPC 用着好好的?为什么还需要使用 MQ?

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

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

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

  • 系统整体调用延时增加
  • 下游服务异常,影响上游服务。两者物理以及逻辑依赖严重
  • 若后面再增加一个下游系统,需要知道支付成功的结果,上游系统需要改动代码。这种情况对于上游情况来讲,就会很烦。明明与上游系统没有什么关系,却需要修改代码。

那一定要用 MQ 解决吗?

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

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

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

增加 MQ 解耦

这个场景使用 MQ 解耦,带来几点优点:

  • 任务一:上游系统执行时间变短
  • 任务二:上下游逻辑解耦,物理解耦
  • 任务三:最重要一点,增加一个下游服务,其只要订阅即可,上游服务无需要改动代码

数据驱动的定时任务场景

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

  • 定时任务下载渠道对账文件,下载方式可能为 Http 接口下载,也有可能 SFTP 下载
  • 定时任务解析对账文件,然后将对账数据入库
  • 定时任务将自己本端支付数据与对账数据核对

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

RPC 用着好好的?为什么还需要使用 MQ?

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

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

  • 通常 06:00 就能下载到对账文件,但是有时候渠道端对账文件延迟,就会导致任务一执行失败,这样就会后续两个定时任务也会执行失败
  • 假设任务二数据过多,执行时间过长,任务三执行时还没结束,这就导致任务三无法拿到全量数据,导致对账异常
  • 整体任务执行时间过长
  • 任务一若调整时间,可能导致任务二,任务三都需要调整时间

使用 MQ解耦

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

RPC 用着好好的?为什么还需要使用 MQ?

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

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

  • 下游任务只要收到消息就能立刻执行,不需要额外等待,整体任务执行时间变短
  • 上游任务时间变动,无需修改下游任务时间。我们这个例子,只需要任务一的实际即可

总结

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

适合使用 MQ 的场景有:

  • 上游不关心下游结果的场景
  • 数据驱动的定时任务依赖

最后说两句(求关注)

所以看完文章,哥哥姐姐们给阿粉来个在看吧,让阿粉拥有更加大的动力,写出更好的文章,拒绝白嫖,来点正反馈呗~。

如果想在第一时间收到阿粉的文章,不被公号的信息流影响,那么可以给Java极客技术设为一个星标。

最后感谢各位的阅读,才疏学浅,难免存在纰漏,如果你发现错误的地方,由于本号没有留言功能,还请你在后台留言指出,我对其加以修改。

最后谢谢大家支持~

最最后,重要的事再说一篇~

快来关注我呀~
快来关注我呀~
快来关注我呀~

< END >

如果大家喜欢我们的文章,欢迎大家转发,点击在看让更多的人看到。也欢迎大家热爱技术和学习的朋友加入的我们的知识星球当中,我们共同成长,进步。



往期 精彩回顾






以上是关于RPC 用着好好的?为什么还需要使用 MQ?的主要内容,如果未能解决你的问题,请参考以下文章

requestAnimationFrame之缓动的应用

分布式服务(RPC)+分布式消息队列(MQ)面试题精选

好好珍惜一个人,好好守护一份爱

mq从零开始实现 mq-05-实现优雅停机

URL Rpc mq

MQ 解耦?骗你的