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

本文转载自微信公众号「Java极客技术」,作者鸭血粉丝。转载本文请联系Java极客技术公众号。   

创新互联建站专注于企业网络营销推广、网站重做改版、韶关网站定制设计、自适应品牌网站建设、H5网站设计成都商城网站开发、集团公司官网建设、成都外贸网站制作、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为韶关等各大城市提供网站开发制作服务。

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

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

 

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

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

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

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

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

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

RPC 场景

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

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

 

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

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

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

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

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

MQ 场景

上游不关心下游结果的场景举个例子,在我们第三方支付系统中,每支付成功一笔,都需要计算手续费。

 

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

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

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

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

那一定要用 MQ 解决吗?

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

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

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

增加 MQ 解耦

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

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

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

定时任务下载渠道对账文件,下载方式可能为 Http 接口下载,也有可能 SFTP 下载

定时任务解析对账文件,然后将对账数据入库

定时任务将自己本端支付数据与对账数据核对

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

 

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

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

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

使用 MQ解耦

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

 

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

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

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

总结

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

适合使用 MQ 的场景有:

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

数据驱动的定时任务依赖

本文标题:RPC用着好好的?为什么还需要使用MQ?
当前链接:http://www.mswzjz.com/qtweb/news36/162036.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联