服务化架构 IM 系统之应用 MQ

在微服务化系统中，存在三个最核心的组件，分别是 RPC、注册中心和MQ。

在前面的两篇文章（见《服务化架构 IM 系统之应用 RPC》和《服务化架构 IM 系统之应用注册中心》）中，我们站在应用的视角分析了普适性的 RPC 和注册中心应该提供的服务能力。今天我们继续站在应用的角度，分析微服务第三组件： MQ。

RPC 和 MQ 是微服务化系统中服务之间两种典型的通讯模型，见下图。

MQ 通讯模型是通过消息实现服务之间的数据传输，MQ 的核心原理可以抽象为下图。

服务发送的消息先传输到 MQ，MQ 是保存消息的容器
MQ 具备持久化能力，保证了消息的可靠性
MQ 分别与消息的生产方和消费方通讯，从根本上对两者进行了解耦

而在 RPC 通讯模型中，数据传输的可靠性以及服务之间的耦合性则不如 MQ 通讯方式，如此来看，MQ 能否完全替代 RPC 呢？答案肯定是不行的。分别基于 RPC 通讯模型和 MQ 通讯模型的 IM 分层架构见下图。

本质上讲，完全通过 MQ 通讯的系统是一个中心化的系统，而通过 RPC 通讯的系统则是一个去中心化的系统；MQ 完全替代 RPC 后，若 MQ 崩溃，则整个系统将陷入瘫痪，风险更大。

一般来说，当系统对实时性要求较高，或者服务消费方对服务提供方的处理结果非常关注时，我们会使用 RPC 通讯模型。而 MQ 通讯模型常见应用场景主要有以下五类。

（1）一多应用

一多应用指消息生产方是一个服务，而消息消费方是多个服务；消息生产方只管将消息发送到 MQ 即可，哪个服务对消息感兴趣，来 MQ 订阅消费即可，消息生产方无需关注。见下图。

在电商平台中，IM 系统中产生的每一条聊天消息，都会发送到 MQ；订单服务、交易服务和广告服务分别从 MQ 中获取消息，来进行服务内部的逻辑处理。

（2）轻重分离

轻重分离指将轻量级的业务与重量级的业务通过 MQ 分离开来，将核心的业务与非核心的业务通过 MQ 分离开来。见下图。

在分层架构的 IM 系统中，由 logic 处理实时性较强的轻量级的核心业务（如消息收发），而由 extlogic 处理实时性较弱的重量级的非业务业务（如离线用户召回）；logic 与 extlogic 之间通过 MQ 通讯，实现轻重业务的分离。这一块应用场景在之前的文章中有过详细分析，见《分层架构 IM 系统之架构演进》。

（3）结果忽略

结果忽略指消息生产方不关注消息消费方的处理结果，也就是消息消费方对消息的处理结果不会影响消息生产方的处理流程；这个也是 MQ 最常用的业务场景。反之，如果消息生产方对消费消费方的处理结果很关注的话，就应该用 RPC 了。见下图。

用户A 向用户B 发消息，用户B处于离线状态，此时 logic 会向 MQ 发消息；pusher 服务从 MQ 获取消息后，向用户B 推送一条手机的 push ，以此提醒用户B，有用户A 向你发送了 IM 消息；pusher 服务是否能成功将手机的 push 消息推送给用户B，logic 并不关注，也不会影响 logic 的处理流程。

（4）流量缓冲

流量缓冲指消息消费速度低于消息的生产速度，而没有及时消费的消息暂时缓冲在 MQ 中，给下游服务一些时间来逐步对消息进行消费。见下图。