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

系统结构

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是能够很是天然直觉的使用方式。
• 因为等待结果，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成了服务调用（服务调用使用方式成简单，基于业务接口）。

连接

RPC和MQ各自适合的应用场景

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