浅谈服务间通信【MQ在分布式系统中的使用场景】

解决的问题

一项技术的产生必然是为了解决问题而生，了解了一项技术解决的问题，就能够很轻松的理解这项技术的设计根本，从而更好地理解与使用这项技术。



消息中间件和RPC从根本上来说都是为了解决分布式系统的服务间通信问题，我们的服务从最初的单体应用发展到SOA架构到现在的微服务架构，必不可少的就是服务间通信，但从最初的设想，服务间通信仅仅就是一次请求响应调用而已，为什么发展出如此多的消息中间件与RPC技术，我们是否真的需要学习这么多的消息中间件技术？



答案是肯定的，接下来我们将分析我们为什么要了解及使用如此多的服务间通信技术，以及他们究竟都解决了哪些问题，在什么场景下他们是必不可少的。

消息中间件 VS RPC

首先来说一下什么是消息中间件和RPC，简单来说，他们最主要的区别是，完成一次服务间通信需要的组件数量，本篇文章我们先来讨论一下消息中间件的优势与使用场景

RPC

消息中间件

从上面两幅图可以清晰地看出消息中间件比RPC要多了一个组件，那就是消息中间件本身，从而我们也能想到，使用消息中间件通信时，相较于使用RPC通信，会有更多的组件运维成本，也会增加一次通信的通信延迟，那么我们为什么要使用消息中间件？一个很重要的原因就是，他为我们增加了消息堆积能力，而这个能力提供给我们了很重要的流量削峰，高可用以及广播等问题的解决方案。

流量削峰

流量削峰是指在发生突发性流量增长时，并不会让下游服务（接收请求的服务）出现超负荷并发从而导致宕机等风险，MQ（消息队列）的解决方案是将流量暂缓存至自己的Queue中，将稳定的持续的将流量发送给消费者。







(在发生流量突增时，下游服务的实时消息处理量，RPC（上），MQ（下）)



上面的图展示的是不同时间段下游服务的请求量曲线，可以看出，通过RPC进行请求的下游服务在短时间内会接收大量超出最高负载的请求，从而可能引发大量的请求超时和CPU 100%导致的服务宕机等情况。而通过MQ进行通信时，若MQ发现接收到的请求超出消费者的最大负载时，则会将请求暂存至消息队列中，并将请求保持在一个持续稳定的量发送给消费者（下游服务），从而保证了系统的稳定。



流量削峰在面对例如秒杀等场景就显得尤为重要，例如淘宝的双十一整点秒杀，12306的整点放票等活动，消息队列均起到的重要作用，我们也就可以很好地理解，为什么12306在推出排队系统后，服务宕机的概率被大大减小了（虽然体验依旧是一团糟...