在阿里的平台技术部参与开发了 Dubbo(远程调用服务)和 Napoli(消息解决方案),又给网站应用支持这 2 个产品很长一段时间,了解了这 2 个产品的实现及应用对这两个产品的用法.
大部分情况下,"给定场景下应该使用这两个产品中哪个" 这个问题,大家都会容易决定,而且不需要多少讨论.
我为什么要拿出来讨论一下:
一些场景会比较模糊,觉得都可以使用.这时需要知道产品缺点,而不是看到优势.
一些新人会觉得产品功能是可以替换的,要给说明一下.
这里简单说一下两者的区别.
系统结构
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 则方向.
PRC 的特点
同步调用,对于要等待返回结果 / 处理结果的场景,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 成了服务调用(服务调用使用方式成简单,基于业务接口).
PS: 也发在个人博客 远程调用服务 (RPC) 和消息 (Message Queue) 对比及其适用 / 不适用场合
来源: http://it.taocms.org/03/50.htm