首先我们想一下，两个公司之间如果有互相调用接口的业务需求，如果没有引入中间件技术，是怎么实现的呢？

 

 

 

用户发起请求给系统A，系统A接到请求直接调用系统B，系统B返回结果后，系统A才能返回结果给用户，这种模式就是同步调用。

 

 

 

所谓同步调用就是各个系统之间互相依赖，一个系统发送请求，其他系统也会跟着依次进行处理，只有所有系统处理完成后对于用户来讲才算完成了一次请求。只要其他系统出现故障，就会报错给用户。

 

 

 

那么引入中间件后，是如何做到异步调用的呢？

 

 

 

用户发起请求给系统A，此时系统A发送消息给MQ，然后就返回结果给用户，不去管系统B了。然后系统B根据自己的情况，去MQ中获取消息，获取到消息的时候可能已经过了1分钟甚至1小时，再根据消息的指示执行相应的操作。

 

那么想一想，系统A和系统B互相之间是否有通信？这种调用方式是同步调用吗？

 

系统A发送消息给中间件后，自己的工作已经完成了，不用再去管系统B什么时候完成操作。而系统B拉去消息后，执行自己的操作也不用告诉系统A执行结果，所以整个的通信过程是异步调用的。

 

 

 

说到这里，我们可以做个总结，消息中间件到底是什么呢？

 

其实消息中间件就是一个独立部署的系统。可以实现各个系统之间的异步调用。当然它的作用可不止这些，通过它可以解决大量的技术痛点，我们接下来会进行介绍。

 

 

 

消息中间件，总结起来作用有三个：异步化提升性能、降低耦合度、流量削峰。

 

 

 

异步化提升性能

 

先来说说异步化提升性能，上边我们介绍中间件的时候已经解释了引入中间件后，是如何实现异步化的，但没有解释具体性能是怎么提升的，我们来看一下下边的图。

 

 

 

 

 

 没有引入中间件的时候，用户发起请求到系统A，系统A耗时20ms，接下来系统A调用系统B，系统B耗时200ms，带给用户的体验就是，一个操作全部结束一共耗时220ms。

 

如果引入中间件之后呢？看下边的图。

 

 

 

 

 

 用户发起请求到系统A，系统A耗时20ms，发送消息到MQ耗时5ms，返回结果一共用了25ms，用户体验一个操作只用了25ms，而不用管系统B什么时候去获取消息执行对应操作，这样比较下来，性能自然大大提高

 

 

 

降低耦合度

 

再来聊聊解耦的场景，看下图。

 

 

 

 

 

如果没有引入中间件，那么系统A调用系统B的时候，系统B出现故障，导致调用失败，那么系统A就会接到异常信息，接到异常信息后肯定要再处理一下，返回给用户失败请稍后再试，这时候就得等待系统B的工程师解决问题，一切都解决好后再告知用户可以了，再重新操作一次吧。

 

这样的架构，两个系统耦合再一起，用户体验极差。

 

那么我们引入中间件后是什么样的场景呢，看下面的流程：

 

 

 

 对于系统A，发送消息后直接返回结果，不再管系统B后边怎么操作。而系统B故障恢复后重新到MQ中拉取消息，重新执行未完成的操作，这样一个流程，系统之间没有影响，也就实现了解耦。

 

 

 

流量削峰

 

下面我们再聊聊最后一个场景，流量削峰

 

 

 

 

 

假如我们的系统A是一个集群，不连接数据库，这个集群本身可以抗下1万QPS

 

系统B操作的是数据库，这个数据库只能抗下6000QPS，这就导致无论系统B如何扩容集群，都只能抗下6000QPS，它的瓶颈在于数据库。

 

假如突然系统QPS达到1万，就会直接导致数据库崩溃，那么引入MQ后是怎么解决的呢，见下图：

 

 

 

 

 

 引入MQ后，对于系统A没有什么影响，给MQ发送消息可以直接发送1万QPS。

 

此时对于系统B，可以自己控制获取消息的速度，保持在6000QPS一下，以一个数据库能够承受的速度执行操作。这样就可以保证数据库不会被压垮。

 

当然，这种情况MQ中可能会积压大量消息。但对于MQ来说，是允许消息积压的，等到系统A峰值过去，恢复成1000QPS时，系统B还是在以6000QPS的速度去拉取消息，自然MQ中的消息就慢慢被释放掉了。

 

这就是流量削峰的过程。在电商秒杀、抢票等等具有流量峰值的场景下可以使用这么一套架构。