MQ vs RPC 的应用场景对比


消息队列和远程调用的应用场景对比

Author : RocWay

架构模型

image

RPC的特点是:

客户端同步调用服务器上的方法、过程
客户端的请求只能由一个服务器处理,虽然请求可以分发到不同的服务器,但一次只能由一个服务器处理
架构简单、明晰

image

MQ的特点是:

消息的发送者和消费者解耦,即消息的产生和处理是异步的
一条消息的消费者可以有多个
消息可以保存在MQ系统中,消费者可以重新消费
架构比RPC稍显复杂

适用场景

RPC比较适合

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

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

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

MQ比较适合

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

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

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