大部分情况下,“给定场景下应该使用这两个产品中哪个”这个问题,大家都会容易决定,而且不需要多少讨论。
我为什么要拿出来讨论一下:
这里简单说一下两者的区别。
RPC系统结构:
+----------+ +----------+
| Consumer | <=> | Provider |
+----------+ +----------+
Consumer调用的Provider提供的服务。
Message Queue系统结构:
+--------+ +-------+ +----------+
| Sender | <=> | Queue | <=> | Receiver |
+--------+ +-------+ +----------+
Sender发送消息给Queue;Receiver从Queue拿到消息来处理。
在架构上,RPC和Message的差异点是,Message有一个中间结点Message Queue,可以把消息存储。
所以对于有同步返回需求,用Message Queue则变得麻烦了。
如果以异步RPC的方式使用,Consumer(Client)线程消耗可以去掉。但不能做到像消息一样暂存消息/请求,压力会直接传导到服务Provider。
随着业务增长,有的处理端处理量会成为瓶颈,会进行同步调用到异步消息的改造。
这样的改造实际上有调整业务的使用方式。
比如原来一个操作页面提交后就下一个页面会看到处理结果;改造后异步消息后,下一个页面就会变成“操作已提交,完成后会得到通知”。
RPC同步调用使用Message Queue来传输调用信息。 上面分析可以知道,这样的做法,发送端是在等待,同时占用一个中间点的资源。变得复杂了,但没有对等的收益。
对于返回值是void的调用,可以这样做,因为实际上这个调用业务上往往不需要同步得到处理结果的,只要保证会处理即可。(RPC的方式可以保证调用返回即处理完成,使用消息方式后这一点不能保证了。)
返回值是void的调用,使用消息,效果上是把消息的使用方式Wrap成了服务调用(服务调用使用方式成简单,基于业务接口)。
转载:http://oldratlee.com/post/2013-02-01/synchronous-rpc-vs-asynchronous-message