架构师面试（二十四）：RPC 与 MQ

问题

在互联网微服务系统中，服务和服务之间有两种最基本的通讯方式，即：RPC 和 MQ。

RPC 通讯方式，会因为网络抖动 或 服务提供方问题导致消息丢失，相对来说可靠性不高；而且服务消费方和服务提供方因为直接通讯而导致高耦合性。 

MQ 是一种可保存消息的容器，可靠性较高；而且因为生产者和消费者不直接通讯，避免了两者之间的相互影响。

这样看来，在微服务系统中，MQ 通讯方式似乎优于 RPC 通讯方式，那么 MQ 是否可以取代 RPC呢？可以试着从架构角度阐述一下理由！

解析

在微服务系统中 MQ 是不可以取代 RPC 的！

RPC 是一种嵌入到服务中运行的组件，MQ 是可以独立运行的消息中间件。我们对微服务系统进行抽象，比如可以划分出 网关层、业务逻辑层 和 数据访问层，每一层有大量的服务节点。

如果没有 RPC，微服务系统中所有的服务节点全部通过 MQ 进行消息通讯，设想一下这样的架构存在什么问题呢？MQ 就变成了整个微服务系统中一个中心化的组件，当这个组件出现任何问题时，整个微服务系统就会面临瘫痪的风险。而如果一条 RPC 连接出现问题，影响的仅仅是当前连接的服务提供方节点和服务消费方节点。

这是从架构角度描述 RPC 不能被 MQ 替代的原因。另外， 在通讯实时性要求较高的场景，以及需要双向通讯的场景（即 服务消费方需要实时获取到服务提供方的执行结果）中，宜采用 RPC 通讯方案，而非 MQ 方案。

MQ比较适用于哪些应用场景呢？我们在课上详细总结过 MQ 的五大应用场景，共20字箴言（忘记的同学随时观看视频回放哈）：

（1）轻重分离；

（2）一多应用；

（3）结果忽略；

（4）流量缓冲；

（5）架构保护。