RPC接口与消息MQ对比

RPC接口(Remote Procedure Call,远程过程调用)

MQ消息(Message Queue)

两种方式都可以用于数据的传递，这方面两者达到效果相同，区别在于使用方式、技术指标：同步异步、数据暂存等.

系统结构

RPC系统结构

Client直接调用的server提供的服务。

Message Queue系统结构

producer发送消息给Queue；consumer从MQ拿到消息来处理。一般无需关注返回,或者以消息或其他形式返回

在架构上，RPC和Message的差异点是，MQ有中间结点可以把消息存储,起到缓冲作用。

功能特点

消息的特点

• MQ把请求的压力保存，逐渐释放出来，让处理者按照自身能力来处理。

• MQ引入新的结点,增加系统复杂度，系统的可靠性会受Message Queue结点的影响。

• MQ是异步单向。发送消息不需要等待消息处理完成。

所以对于有同步返回需求，不便用MQ。

RPC的特点

• 同步调用，对于需等待返回结果/处理结果的场景，RPC是非常方便,自然的使用方式。(RPC也可以是异步调用,不讨论)

• 由于等待结果，Client会有线程消耗。

如果以异步RPC的方式使用，Client线程消耗可以省去。但不能做到像消息一样暂存消息/请求，压力会直接打到服务端。

适用场合

• 希望同步得到结果的场合，选RPC。

• 希望使用简单，选RPC.RPC操作基于接口，使用简单。异步的方式编程比较复杂。

• 客户端不希望受制于服务端的处理速度时，选Message Queue。

随着业务增长，服务端处理会成为瓶颈，会进行同步调用到异步消息的改造。这样的改造实际上也调整业务的使用方式。

不适用场合

• RPC接口特别耗时时

• RPC同步调用,但使用Message Queue来传输调用信息。 这种做法发送端是在等待，同时占用中间点的资源。系统变得复杂且没有对等的收益。

• 对于返回值是void的调用，可以用消息，因为这个调用业务不需要同步得到处理结果，只要保证会处理即可。（RPC的方式可以保证调用返回即处理完成，使用消息后无法保证。）

消息的解耦

• 消息的发送者，不需要关心接收者。RPC服务通过注册中心也可以做到，即服务调用者到注册中心查询服务提供者信息，调用者事前不需知道。

• 消息的发送者，不用关心发给几个消息组件。这一点RPC可以通过服务编排做到。