消息中间件使用场景

一、消息中间件简介

    Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. 维基百科给出的消息中间件的定义是支持在分布式系统中发送和接受消息的硬件或软件基础设施。消息中间件就是用来解决分布式系统之间消息传递的问题。

二、消息中间件的典型使用场景

1、系统解耦

     首先假设有一个核心系统A，其能产生核心数据供下游服务（系统B和系统C）使用。此时最易想到的办法就是A直接把数据发送给B和C，流程如下。

图1

    那么问题来了，此时假设又有D、E、F、G等多个系统也需要使用核心数据，此时流程图如下。

图2

    我们可以想象一下，假设有上百个系统都需要系统A的核心数据，此时负责系统A的工程师将是崩溃的，一旦有系统加入，A系统就需要修改代码，将数据发送到新加入的系统。反之，如果有系统不再需要A发送数据，那么A系统又得修改代码不再向其发送数据。这样的架构设计耦合度太高了，我们就可以引入消息中间件来实现系统之间的解耦。即核心系统A生产核心数据，然后将核心数据发送到消息中间件，下游消费系统根据自身需求从中间件里获取消息进行消费，当不再需要数据时就不取消息进即可，这样系统之间耦合度就大大降低了。具体流程图如下。

图3

2、异步调用

    假设有一个系统调用链路为A调用B耗时20ms，B调用C耗时20ms，而C调用D需要2s，这样下来整个调用需要耗时2040ms。但实际上A调用B，B调用C只需要40ms，而D系统的引入直接导致系统性能下降约50倍。此时我们应该考虑将D系统的调用抽离出来，做一个异步调用。

图4

    生活中有一个很形象的例子。我们点一杯奶茶，下单、付款、通知商家制作都很快，然而到匹配外卖小哥配送这个过程很慢。作为用户来说，匹配外卖小哥这个过程延迟一些时间是可以接受的，只要我能快速下单成功，并且在一定时间范围内安排快递小哥送货即可。

    按照上面的思路，系统A到系统B再到系统C就直接结束了，然后系统C再将消息发送到消息中间件中，系统D从消息中间件里取消息进行消费，这样子我们系统的性能就提高了接近50倍。过程如下图所示。

图5

3、削峰填谷

    假设有一个系统，正常时间也就每秒几百个请求，部署在一个8核16G的机器上，运行起来轻松加愉快。然而突然由于搞一个活动，高峰期请求数达到了几千，出现了瞬时流量高峰，此时最易想到的是加机器，部署个10台机器，也能扛住此时的高并发。

图6

    那么问题来了，瞬时流量每天也就那么几十分钟，过后就是正常的每秒几百请求，我们如果部署10台机器，那么平均下来没台机器的请求数也就每秒几十次，这样是不是有点太浪费资源了呢？大部分时候，每秒几百请求，一台机器就能够扛住了，但是为了抗那每天瞬时的高峰，硬是部署了10台机器，每天就那几十分钟有用，别的时候都是浪费资源的。

图7

    但是如果仅仅部署一台机器，瞬间高峰就会击垮系统，因为单台机器是不能扛住每秒几千次请求的。这时我们就可以考虑引入消息中间件，进行流量削峰。我们可以部署一层消息队列在机器前面，平时正常的每秒几百次请求，机器就正常的消费消息即可，一旦流量高峰到达时，大量消息会堆积在消息队列里面，机器只需要按照自己的最大负荷从消息队列里面消费，等流量高峰过了，慢慢地队列里面的消息也消费完毕了。此时达到了一个削峰填谷的作用。具体如图所示。

图8

---

                         本文仅仅作为作者的学习笔记，仅供参考，如有雷同，纯属巧合。

---