远程调用服务(RPC)和消息队列(Message Queue)对比及其适用/不适用场合分析

最近考虑把公司系统重构升级,将原有的垂直MVC架构迁移为分布式系统,因此着重了解了下远程调用服务(RPC)和消息队列(MQ)。RPC和MQ都是用于分布式系统的两个关键技术,并且里面都有服务提供者和消费者的概念,可在一定程度上对系统进行解耦。但对于彼此应用场景的区分还不是特别清楚,直到看了一篇阿里内部人士写的文章,简单明了的介绍了两者的区别和应用场景,现在贴出来和大家分享一下。

原文链接:http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message


在阿里的平台技术部参与开发了Dubbo(远程调用服务)和Napoli(消息解决方案),又给网站应用支持这2个产品2年,了解了这2个产品的实现及应用对这两个产品的用法。

大部分情况下,“给定场景下应该使用这两个产品中哪个”这个问题,大家都会容易决定,而且不需要多少讨论。

我为什么要拿出来讨论一下:

  • 一些场景会比较模糊,觉得都可以使用。这时需要知道产品缺点,而不是看到优势。
  • 一些新人会觉得产品功能是可以替换的,要给说明一下。

这里简单说一下两者的区别。

系统结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
RPC系统结构:
 
+----------+     +----------+
| Consumer | <=> | Provider |
+----------+     +----------+
Consumer调用的Provider提供的服务。
 
 
Message Queue系统结构:
 
+--------+     +-------+     +----------+
| Sender | <=> | Queue | <=> | Receiver |
+--------+     +-------+     +----------+
Sender发送消息给Queue;Receiver从Queue拿到消息来处理。

功能特点

在架构上,RPC和Message的差异点是,Message有一个中间结点Message Queue,可以把消息存储。

消息的特点

  • Message Queue把请求的压力保存一下,逐渐释放出来,让处理者按照自己的节奏来处理。
  • Message Queue引入一下新的结点,让系统的可靠性会受Message Queue结点的影响。
  • Message Queue是异步单向的消息。发送消息设计成是不需要等待消息处理的完成。

所以对于有同步返回需求,用Message Queue则变得麻烦了。

RPC的特点

  • 同步调用,对于要等待返回结果/处理结果的场景,RPC是可以非常自然直觉的使用方式。
    # RPC也可以是异步调用。
  • 由于等待结果,Consumer(Client)会有线程消耗。

如果以异步RPC的方式使用,Consumer(Client)线程消耗可以去掉。但不能做到像消息一样暂存消息/请求,压力会直接传导到服务Provider。

适用场合说明

  • 希望同步得到结果的场合,RPC合适。
  • 希望使用简单,则RPC;RPC操作基于接口,使用简单,使用方式模拟本地调用。异步的方式编程比较复杂。
  • 不希望发送端(RPC Consumer、Message Sender)受限于处理端(RPC Provider、Message Receiver)的速度时,使用Message Queue。

随着业务增长,有的处理端处理量会成为瓶颈,会进行同步调用到异步消息的改造。

这样的改造实际上有调整业务的使用方式。

比如原来一个操作页面提交后就下一个页面会看到处理结果;改造后异步消息后,下一个页面就会变成“操作已提交,完成后会得到通知”。

不适用场合说明

RPC同步调用使用Message Queue来传输调用信息。 上面分析可以知道,这样的做法,发送端是在等待,同时占用一个中间点的资源。变得复杂了,但没有对等的收益。

对于返回值是void的调用,可以这样做,因为实际上这个调用业务上往往不需要同步得到处理结果的,只要保证会处理即可。(RPC的方式可以保证调用返回即处理完成,使用消息方式后这一点不能保证了。)

返回值是void的调用,使用消息,效果上是把消息的使用方式Wrap成了服务调用(服务调用使用方式成简单,基于业务接口)。

补记,关于解耦讨论

微博上的一些讨论,觉得很有意义补记下来。

inter12:这两者可以拿来比较,但是个人感觉并不是同一个层面的问题。RPC是分布式服务之间调用的一种解决方案,是我们在做架构设计决策时同分布式对象,REST等层面的东西比较,决策的一个方案! 消息系统更多是我们为了解决系统之间的解耦,以及性能问题等方面所考虑的方案! 说的有些乱,望鼎哥指点下。

oldratlee:回复@inter12:你说到很多关键点了,“分布式对象”“解耦”“性能”,这些都可以用来看两者的差异。 如果从两个机器间数据的传递(调用、消息都是数据)角度看,两者效果相同,区别只是使用方式、技术指标:同步异步(比如 是否等反馈 )、数据是否暂存、强弱类型(比如 有独立的业务方法,数据类型)等等

inter12提到了“解耦”,“解决系统之间的解耦”使用消息时大家常常说到的一点,一个重要权衡方面!

个人觉得,“解耦”不如“暂存”,是消息相对RPC的关键区别,原因说明如下:

消息的解耦特征,主要体现在:

  1. 消息的发送者,不需要关心接收者的信息。 服务通过注册中心也可以做到,即服务调用者到注册中心查询服务提供者信息,调用者不需知道。
  2. 消息的发送者,不用关心可以发个几个关心的消息组件。
    这一点RPC可以通过服务编排做到。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值