RPC和MQ对比及其适用/不适用场合

在阿里的平台技术部参与开发了Dubbo（远程调用服务）和Napoli（消息解决方案），又给网站应用支持这2个产品很长一段时间，了解了这2个产品的实现及应用对这两个产品的用法。

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

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

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

系统结构
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则变得麻烦了。

PRC的特点
同步调用，对于要等待返回结果/处理结果的场景，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一些讨论，觉得很有意义补记下来。

inter12：这两者可以拿来比较，但是个人感觉并不是同一个层面的问题。RPC是分布式服务之间调用的一种解决方案，是我们在做架构设计决策时同分布式对象，REST等层面的东西比较，决策的一个方案！ 消息系统更多是我们为了解决系统之间的解耦，以及性能问题等方面所考虑的方案！ 说的有些乱，望鼎哥指点下。
oldratlee：回复@inter12:你说到很多关键点了，“分布式对象”“解耦”“性能”，这些都可以用来看两者的差异。 如果从两个机器间数据的传递（调用、消息都是数据）角度看，两者效果相同，区别只是使用方式、技术指标：同步异步（比如 是否等反馈 ）、数据是否暂存、强弱类型（比如 有独立的业务方法，数据类型）等等
inter12提到了“解耦”，“解决系统之间的解耦”使用消息时大家常常说到的一点，一个重要权衡方面！

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

消息的解耦特征，主要体现在：

消息的发送者，不需要关心接收者的信息。
服务通过注册中心也可以做到，即服务调用者到注册中心查询服务提供者信息，调用者不需知道。
消息的发送者，不用关心可以发个几个关心的消息组件。
这一点RPC可以通过服务编排做到。
转自：http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message/