RPC vs MQ

看了两篇写对比的文章，摘抄在下面。用我自己的观点看，RPC比较像体感游戏，你在挥舞小刀，切掉了屏幕上的水果；MQ比较类似博客，写了文章后，其它人来看。

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

功能特点

在架构上，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。

随着业务增长，有的处理端处理量会成为瓶颈，会进行同步调用到异步消息的改造。

这样的改造实际上有调整业务的使用方式。

比如原来一个操作页面提交后就下一个页面会看到处理结果；改造后异步消息后，下一个页面就会变成“操作已提交，完成后会得到通知”。

文章二： http://www.vmfor.com/p/100151381218.html

适用场景

RPC比较适合

- 客户端调用哪个服务器比较明确
- 调用需要立即得到返回结果
- 架构简单

在一个由多个微服务构成的大系统中，某些关键服务间的调用应当在较短的时间内返回，而且各个微服务的专业化程度较高，同一个请求的关注者只有一个。这个时候就应该用RPC。

比如在一个ERP系统中，有一个管理仓储的微服务，以及一个负责订单的微服务。新建订单时需要查知当前的存货是否充足，如果不充足就通知用户；提交订单时预订指定数量的货物，如果此时货物不错，也要终止订单的提交，并通知用户。显然在这种场景下是不允许较大的延迟，否则会影响用户体验。所以应该使用RPC，及时返回仓储情况。

MQ比较适合

- 消息的发送者和消费者需要解耦的情况
    - 发送者并不明确谁是消费者
    - 发送者并不关心谁来消费消息
    - 各个消费者可以从不同的角度入手处理消息
    - 消费者的处理结果也不返回给发送者
- 消息的发送和处理是异步的
- 消息的关注者不止一个

在一个由多个微服务构成的大系统中，会有一些非关键服务，用来执行一些不需要立刻得到结果的计算。而且它们的计算结果并不会返回给消息的发送者。这个时候就应该使用MQ。

比如在一个ERP系统中有一些日志服务、业务监控服务等。这些服务会发布一些系统事件，针对这些事件可能有多个应用关注。对于日志服务，当系统出现某些异常情况时需要浏览日志，查找问题的根源；也可以在分析系统运行的瓶颈时提供关键数据。对于业务监控系统，例如货物入仓出仓的消息，可以被报表系统关注，生成报表；也可以被配货系统关注，及时补足所需库存。