1、入门概述
1、1 什么是消息中间件？
消息中间件事利用高效可靠的消息传递机制进行异步的数据传输，并基于数据通信进行分布式系统的集成。通过提供消息队列模型和消息传递机制，可以在分布式的环境下扩展进程间的通信。
1、2 为什么要在系统中引入消息中间件？
解耦、削峰、异步
链式调用是我们在写程序的时候的一般流程，为了完成应整体的功能，会将其拆分成多个函数(或子模块)，比如模块A调用模块B，模块B调用模块C，模块C调用模块D，但是在大型分布式应用中，系统间的RPC交互频繁，一个功能背后要调用上百个接口并非不可能，这种架构有一下几个劣势：
- 1、这些接口之间的耦合比较严重，每系增一个下游的功能，都要上游的所有相关接口进行改造，举个例子：假如系统A要发送数据给系统B和C，发送给每个系统的数据可能有差异，因此系统A对要发送给每个系统的数据进行了组装，然后逐一发送；当代码上线后，新增了一个需求：把数据也发送给D。此时就需要修改A系统，让他感知到D的存在，同时把数据处理好给D。在这个过程中你会看到，每接入一个下游系统，都要对A系统进行代码改造，开发联调的效率很低。其整体架构如下图：
- 2、面对大流量并发时，容易被冲垮，每个接口模块的吞吐量是有限的，这个上限能力如同一个堤坝，当大流量来临的时候，就会被冲垮。
- 3、存在性能问题，RPC接口调用基本上是同步的，整体的服务性能遵循“木桶原理”，即链路杂种最慢的接口：
根据上述的几个问题，我们在设计系统的时候可以明确达到的目标：
1、要做到系统解耦，当新的模块进来的时候，可以做到代码改动最小
2、设置流量缓冲区，可以让后端系统按照自身的吞吐能力进行消费，不被冲快
3、强依赖梳理，将非关键调用的链路的操作异步化，提升整体系统的吞吐能力，，比如上图中A、B、C、D是让用户发起付款，然后返回付款成功提示的几个关键流程，而B1是通知付款后通知商家发货的模块，那么实质上用户对B1完成的时间容忍度比较大（比如几秒之后），可以将其异步化。
在现在的系统视线中，MQ消息队列是普遍使用的，可以完美的解决这些问题的利器。下图是使用了MQ的简单架构图，可以看到MQ在最前端对流量进行蓄洪，下游的系统A\B\C只与MQ打交道，通过事先定义好的消息格式来解析。
引入MQ后的系统框架，交互方式与最初的链式调用架构非常不同，虽然可以解决上文提到的问题，但是也要充分理解其原理特性来避免其带来的副作用，保证消息的”可靠投递“
1、3 那么消息中间件是如何解决的呢？
面向消息中间件(MOM)能够很好的解决上述问题，是指利用高效可靠的消息传递机制，与平台无关的数据交流，并基于数据通信来进行分布式系统的集成
通过消息传递和消息排队模型在分布式环境下提供的应用解耦,弹性伸缩，冗余存储，流量削峰，异步通信，数据同步等功能。
大致过程是这样的：
发送者把消息发送给服务器，消息服务器将消息放在若干队列（queue）/主题（topic）中，在合适的时候，消息服务器会将消息发送给接受者，这个过程中，发送和接收是异步的，也就是发送无需等待，而且发送者和接受者的生命周期也没有必须的关系；
尤其在发布pub/订阅sub的模式下，也可以完成一对多的通信，即让一个消息有多个接受者。
整体架构
