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

dubbo和MQ都是为了解决分布式应用之间的通讯问题，dubbo使用的RPC，侧重于同步调用，客户端会依赖服务端提供的接口而后进行调用。MQ使用的是观察者模式，消息发送者只负责产生并发送消息，消息消费者只负责接收消息并作相应处理，二者并不知道对方的存在，MQ侧重于异步通讯，耦合性较低。

我如今比较疑惑的地方时：何时该用dubbo,何时该用MQ

如下转自阿里技术

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

大部分状况下，“给定场景下应该使用这两个产品中哪一个”这个问题，你们都会容易决定，并且不须要多少讨论。

我为何要拿出来讨论一下：

一些场景会比较模糊，以为均可以使用。这时须要知道产品缺点，而不是看到优点。

一些新人会以为产品功能是能够替换的，要给说明一下。

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

系统结构

功能特色

在架构上，RPC和Message的差别点是，Message有一个中间结点Message Queue，能够把消息存储。

消息的特色

1：Message Queue把请求的压力保存一下，逐渐释放出来，让处理者按照本身的节奏来处理。
2：Message Queue引入一下新的结点，让系统的可靠性会受Message Queue结点的影响。
3：Message Queue是异步单向的消息。发送消息设计成是不须要等待消息处理的完成。
因此对于有同步返回需求，用Message Queue则变得麻烦了。

PRC的特色

1：同步调用，对于要等待返回结果/处理结果的场景，RPC是能够很是天然直觉的使用方式。 
  # RPC也能够是异步调用。
2：因为等待结果，Consumer（Client）会有线程消耗。
若是以异步RPC的方式使用，Consumer（Client）线程消耗能够去掉。但不能作到像消息同样暂存消息/请求，压力会直接传导到服务Provider。

适用场合说明

1：但愿同步获得结果的场合，RPC合适。:
2：但愿使用简单，则RPC；RPC操做基于接口，使用简单，使用方式模拟本地调用。异步的方式编程比较复杂。
3：不但愿发送端（RPC Consumer、Message Sender）受限于处理端（RPC Provider、Message Receiver）的速度时，使用Message Queue。
随着业务增加，有的处理端处理量会成为瓶颈，会进行同步调用到异步消息的改造。
这样的改造实际上有调整业务的使用方式。
好比原来一个操做页面提交后就下一个页面会看处处理结果；改造后异步消息后，下一个页面就会变成“操做已提交，完成后会获得通知”。

不适用场合说明

RPC同步调用使用Message Queue来传输调用信息。
上面分析能够知道，这样的作法，发送端是在等待，同时占用一个中间点的资源。变得复杂了，但没有对等的收益。
对于返回值是void的调用，能够这样作，由于实际上这个调用业务上每每不须要同步获得处理结果的，只要保证会处理便可。（RPC的方式能够保证调用返回即处理完成，使用消息方式后这一点不能保证了。）
返回值是void的调用，使用消息，效果上是把消息的使用方式Wrap成了服务调用（服务调用使用方式成简单，基于业务接口）。

补记，关于解耦讨论

微博上inter12的一些讨论，以为颇有意义补记下来

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

nter12提到了“解耦”，“解决系统之间的解耦”使用消息时你们经常说到的一点，一个重要权衡方面！

我的以为，“解耦”不如“暂存”，是消息相对RPC的关键区别，缘由说明以下：

消息的解耦特征，主要体如今：

消息的发送者，不须要关心接收者的信息。

服务经过注册中心也能够作到，即服务调用者到注册中心查询服务提供者信息，调用者不需知道。

消息的发送者，不用关心能够发个几个关心的消息组件。 

这一点RPC能够经过服务编排作到。