为什么一定要用消息中间件

目前市面上常见的几种中间件有 ActiveMQ、RabbitMQ、Kafka等。
ActiveMQ： 可用于 异步调用 、系统解耦等 功能很强大，但是对于高并发、高负载、高吞吐量的复杂场景在国内落地较少；
RabbitMQ： 可以支撑高并发、高吞吐、性能很高，同时有非常完善的后台管理界面，支持集群化、高可用部署、消息高可靠支持；
Kafka: 超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计，在大数据领域中配合实时计算技术（Spark、Storm、Flink）使用较多；

一、为什么要用消息中间件
使用场景 及 解决的问题

1、系统解耦
假如一个系统A会产生一个核心数据，系统B和系统C都需要这个数据。那简单，系统B和系统C的接口发送数据就他们就好了。
过程如下：

但是要来了个系统D、系统E、系统F、系统G、等，几十个系统都需要这份核心数据，如下图所示：

大家可别以为这是开玩笑，一个大规模系统，往往会拆分为几十个甚至上百个子系统，每个子系统又对应N多个服务，这些系统与系统之间有着错综复杂的关系网络。
如果某个系统产出一份核心数据，可能下游无数的其他系统都需要这份数据来实现各种业务逻辑。
此时如果你要是采取上面那种模式来设计系统架构，那么绝对你负责系统A的同学要被烦死了。

先是来一个人找他要求发送数据给一个新的系统H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。
一会那个系统B是个陈旧老系统要下线了，告诉系统A的同学：别给我发送数据了，接着系统A再次修改代码不再给这个系统B。

然后如果要是某个下游系统突然宕机了呢？
系统A的调用代码里是不是会抛异常？那系统A的同学会收到报警说异常了，结果他还要去care是下游哪个系统宕机了。
所以在实际的系统架构设计中，如果全部采取这种系统耦合的方式，在某些场景下绝对是不合适的，系统耦合度太严重。
并且互相耦合起来并不是核心链路的调用，而是一些非核心的场景（比如上述的数据消费）导致了系统耦合，这样会严重的影响上下游系统的开发和维护效率。

因此在上述系统架构中，就可以采用MQ中间件来实现系统解耦。
系统A就把自己的一份核心数据发到MQ里，下游哪个系统感兴趣自己去消费即可，不需要了就取消数据的消费，如下图所示：

2、异步调用
有一个系统调用链路，系统A调用系统B，一般耗时20ms；系统B调用系统C,一般耗时200ms；系统C调用系统D一般耗时2s，如下图所示：

走完该链路需要耗时： 20ms + 200ms + 2000ms（2s） = 2220ms，也就两秒多的时间，但是系统C调用系统D这一步就耗用了绝大部分时间，链路性能降低了10倍。
其实许多业务场景是可以允许异步调用的。
考虑把系统C调用系统D的环节抽离出去 做成异步化，不要放在链路中依次调用。这样实现思路改为 系统A->系统B->系统C,直接耗费220ms后直接 成功了。
而后系统C发送个消息到MQ中间件里，由系统D消费之后慢慢的异步来执行这个耗时2s的业务处理。这种方式直接将核心链路的执行性能提升了10倍。
整个过程如下：

3、流量削峰
假设有一个系统，平时正常的时候每秒可能就几百个请求，系统处理都是OK的，每秒的请求是可以轻松抗住的。如果在高峰期一下子来了每秒几千个请求，瞬时出现了流量高峰，我们不可能部署10台机器去抗住的，因为高峰期不是常有的，比较浪费资源。

但是如果仅仅部署一台机器，那会导致瞬时高峰，一下压垮服务器。此时可以用 MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求都可以轻松接收消息。
一旦达到高峰，可以积压在MQ里，让那一台机器慢慢处理和消费。等高峰期过了，在消费一段时间，MQ里积压的数据就消费完毕了。

这是典型的MQ法，用有限的机器资源承载高并发请求，如果业务场景允许异步削峰，高峰期积压一些请求在MQ里，然后高峰期过了，后台系统在一定时间内消费完毕不在积压的话，那就很合适这种方案了。