RPC, Message Queue, MQ

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

RPC 和 MQ 的区别

系统结构

RPC系统结构: Consumer 调用的 Provider 提供的服务。

+———-+—–+———-+ | Consumer | <=> | Provider | +—-+—–+—–+———-+

Message Queue 系统结构: Sender 发送消息给 Queue; Receiver 从 Queue 拿到消息来处理。

+——–+—–+——-+—–+———-+ | Sender | <=> | Queue | <=> | Receiver | +——–+—–+——-+—–+———-+

功能特点

在架构上, 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可以通过服务编排做到。