远程调用服务(RPC)和消息(Message Queue)对比

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

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

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

　　一些场景会比较模糊，觉得都可以使用。这时需要知道产品缺点，而不是看到优势。

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

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

　　系统结构

　　功能特点

　　在架构上，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。

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

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

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

原文转自：http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message