在阿里的平台技术部参与开发了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则变得麻烦了。

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一些讨论，觉得很有意义补记下来。

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

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

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

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

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

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

from:http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message

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

远程过程调用失败_Java开发大型互联网RPC远程调用服务实现之问题处理方案
引言 RPC(Remote Procedure Call Protocol)--远程过程调用协议,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议.RPC协议假定某些传输协议 ...
RemObjects（一）客户端远程调用服务端接口过程
RemObjects SDK 是高度封装的产物,对OOP发挥极致. 本文将以RemObjects SDK最简单的DEMO--FirstSample为例, 介绍客户端是如何完成远程调用服务端接口的全过程 ...
远程调用-Sun RPC
远程调用-Sun RPC 一.概述二.函数clnt_create 三.RPC例子四.多线程化五.服务器捆绑六.inetd和RPC服务器七.认证八.超时和重传九.TCP连接管理十.事务I ...
架构设计：远程调用服务架构设计及zookeeper技术详解（上篇）
一.序言 Hadoop是一个技术生态圈,zookeeper是hadoop生态圈里一个非常重要的技术,当我研究学习hadoop的相关技术时候,有两块知识曾经让我十分的困惑,一个是hbase,一个就是zo ...
EJB3.0学习笔记---理解远程调用服务端和本地调用服务端的区别
项目目的:理解远程调用服务端和本地调用服务端的区别 1.异常: javax.ejb.EJBException: Local and Remote Interfaces cannot hav ...
架构设计：一种远程调用服务的设计构思（zookeeper的一种应用实践）
在深入学习zookeeper我想先给大家介绍一个和zookeeper相关的应用实例,我把这个实例命名为远程调用服务.通过对这种应用实例的描述,我们会对zookeeper应用场景会有深入的了解. 远程调 ...
windows远程桌面远程服务器繁忙,连接时用户收到“远程桌面服务当前繁忙”消息...
连接时用户收到"远程桌面服务当前繁忙"消息 07/24/2019 本文内容若要确定此问题的相应对策,请查看以下问题: "远程桌面服务"服务是否无响应(例如,远 ...
架构设计：远程调用服务架构设计及zookeeper技术详解（下篇）
一.下篇开头的废话终于开写下篇了,这也是我写远程调用框架的第三篇文章,前两篇都被博客园作为[编辑推荐]的文章,很兴奋哦,嘿嘿~~~~,本人是个很臭美的人,一定得要截图为证: 今天是2014年的第一天 ...
10-10-009-简介-常用Message Queue对比
1.常用Message Queue对比 2. RabbitMQ RabbitMQ是使用Erlang编写的一个开源的消息队列,本身支持很多的协议:AMQP,XMPP, SMTP, STOMP,也正因如此 ...

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