在微服务化系统中，存在三个最核心的组件，分别是 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 中，给下游服务一些时间来逐步对消息进行消费。见下图。
当 logic 产生需要广播的消息时，发送给 MQ；extlogic 从 MQ 获取消息后，广播发送给相关用户。消息广播是一个相对耗时的动作，没有及时处理的广播消息，暂时留在 MQ 中，由 extlogic 沉住气，逐步消费处理即可。
（5）架构保护
在服务化的分层架构中，我们经常建立这样的约束机制：上层服务调用下层的服务，下层的服务不能调用上层的服务，同层服务之间也禁止相互调用。这样的架构约束是为了尽量减少服务维护时的影响范围，防止调用扩散产生服务之间的强耦合。
在业务规模逐步扩大，服务数量不断增加时，同时因为业务快速迭代的需要，在架构落地时，这样的约束很容易被打破，此时可以通过引入 MQ 来包含上述的约束机制。见下图。
上层服务通过 RPC 调用下层服务，在现实情况中，下层服务 “不得不” 调用上层服务时，通过 MQ 通讯机制进行调用，以此保护整个架构。
MQ 在系统中应用广泛，除了上述五类应用场景外，还有三类特殊用法，分别是：顺序消息、事务消息和延时消息。
顺序消息应用在业务消息按既定顺序执行的流程中；事务消息应用在消息生产方和消息消费方两个独立进程的业务在同一个事务中运行；延时消息应用在消息消费方按既定时间进行消费的场景中。
三类消息的特殊应用，分别保证了业务的流程顺序、时间顺序和同时执行的事务性；在后面的文章中，我们结合着 MQ 架构来剖析这三类消息的实现原理。
最后，总结文中关键：
