集成模式中的消息模式
企业应用系统就是对数据的处理，而对于一个拥有多个子系统的企业应用系统而言，它的基础支撑无疑就是对消息的处理。与对象不同，消息本质上是一种数据结构，它包含消费者与服务双方都能识别的数据，这些数据需要在不同的进程（机器）之间进行传递，并可能会被多个完全不同的客户端消费。
在众多分布式技术中，消息传递相较文件传递与远程过程调用（RPC）而言，似乎更胜一筹，因为它具有更好的平台无关性，并能够很好地支持并发与异步调用。对于Web Service与RESTful而言，则可以看做是消息传递技术的一种衍生或封装。
消息通道（Message Channel）模式
消息通道作为在客户端（消费者，Consumer）与服务（生产者，Producer）之间引入的间接层，可以有效地解除二者之间的耦合。只要实现规定双方需要通信的消息格式，以及处理消息的机制与时机，就可以做到消费者对生产者的“无知”。事实上，该模式可以支持多个生产者与消费者。例如，我们可以让多个生产者向消息通道发送消息，因为消费者对生产者的无知性，它不必考虑究竟是哪个生产者发来的消息。
虽然消息通道解除了生产者与消费者之间的耦合，使得我们可以任意地对生产者与消费者进行扩展，但它又同时引入了各自对消息通道的依赖，因为它们必须知道通道资源的位置。要解除这种对通道的依赖，可以考虑引入Lookup服务来查找该通道资源。 若要做到充分的灵活性，可以将与通道相关的信息存储到配置文件中，Lookup服务首先通过读取配置文件来获得通道。消息通道通常以队列的形式存在，这种先进先出的数据结构无疑最为适合这种处理消息的场景。
Publisher-Subscriber模式
一旦消息通道需要支持多个消费者时，就可能面临两种模型的选择：拉模型与推模型。拉模型是由消息的消费者发起的，主动权把握在消费者手中，它会根据自己的情况对生产者发起调用。无论推模型，拉模型，对于消息对象而言，都可能采用类似Observer模式的机制，实现消费者对生产者的订阅。
通常情况下，发布者和订阅者都会被注册到用于传播变更的基础设施（即消息通道）上。发布者会主动地了解消息通道，使其能够将消息发送到通道中；消息通道一旦接收到消息，会主动地调用注册在通道中的订阅者，进而完成对消息内容的消费。
对于订阅者而言，有两种处理消息的方式。一种是广播机制，这时消息通道中的消息在出列的同时，还需要复制消息对象，将消息传递给多个订阅者。例如，有多个子系统都需要获取从CRM系统传来的客户信息，并根据传递过来的客户信息，进行相应的处理。此时的消息通道又被称为Propagation通道。另一种方式则属于抢占机制，它遵循同步方式，在同一时间只能有一个订阅者能够处理该消息。实现Publisher-Subscriber模式的消息通道会选择当前空闲的唯一订阅者，并将消息出列，并传递给订阅者的消息处理方法。
消息路由（Message Router）模式
在企业应用系统中，当系统变得越来越复杂时，对性能的要求也会越来越高，此时对于系统而言，可能就需要支持同时部署多个队列，并可能要求分布式部署不同的队列。这些队列可以根据定义接收不同的消息，例如订单处理的消息，日志信息，查询任务消息等。这时，对于消息的生产者和消费者而言，并不适宜承担决定消息传递路径的职责。事实上，根据单一职责原则，这种职责分配也是不合理的，它既不利于业务逻辑的重用，也会造成生产者、消费者与消息队列之间的耦合，从而影响系统的扩展。既然这三种对象（组件）都不宜承担这样的职责，就有必要引入一个新的对象专门负责传递路径选择的功能，这就是所谓的Message Router模式。
通过消息路由，我们可以配置路由规则指定消息传递的路径，以及指定具体的消费者消费对应的生产者。例如指定路由的关键字，并由它来绑定具体的队列与指定的生产者（或消费者）。路由的支持提供了消息传递与处理的灵活性，也有利于提高整个系统的消息处理能力。同时，路由对象有效地封装了寻找与匹配消息路径的逻辑，就好似一个调停者（Meditator），负责协调消息、队列与路径寻址之间关系。
消息队列（MQ）
MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。MQ是消费-生产者模型的一个典型的代表，一端往消息队列中不断写入消息，而另一端则可以读取队列中的消息。
消息队列是分布式系统中重要的组件，其通用的使用场景可以简单地描述为：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。
当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
消息队列在实际应用中包括如下四个场景：
异步处理
多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；
具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。
1）串行方式：新注册信息生成后，先发送注册邮件，再发送验证短信。在这种方式下，需要最终发送验证短信后再返回给客户端。
2）并行处理：新注册信息写入后，由发短信和发邮件并行处理。在这种方式下，发短信和发邮件 需处理完成后再返回给客户端。
假设以上三个子系统处理的时间均为50ms，且不考虑网络延迟，则总的处理时间：
串行：50+50+50=150ms
并行：50+50 = 100ms
若使用消息队列：
在写入消息队列后立即返回成功给客户端，则总的响应时间依赖于写入消息队列的时间，而写入消息队列的时间本身是可以很快的，基本可以忽略不计，因此总的处理时间相比串行提高了2倍，相比并行提高了一倍。
应用耦合
多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败。
具体场景：用户使用QQ相册上传一张图片，人脸识别系统会对该图片进行人脸识别，一般的做法是，服务器接收到图片后，图片上传系统立即调用人脸识别系统，调用完成后再返回成功。
该方法有如下缺点：
- 人脸识别系统被调失败，导致图片上传失败；
- 延迟高，需要人脸识别系统处理完成后，再返回给客户端，即使用户并不需要立即知道结果；
- 图片上传系统与人脸识别系统之间互相调用，需要做耦合；
若使用消息队列：
客户端上传图片后，图片上传系统将图片信息、批次写入消息队列，直接返回成功；而人脸识别系统则定时从消息队列中取数据，完成对新增图片的识别。
此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上，由于用户并不需要立即知道人脸识别结果，人脸识别系统可以选择不同的调度策略，按照闲时、忙时、正常时间，对队列中的图片信息进行处理。
限流削峰
广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况。
具体场景：购物网站开展秒杀活动，一般由于瞬时访问量过大，服务器接收过大，会导致流量暴增，相关系统无法处理请求甚至崩溃。
若使用消息队列：
请求先入消息队列，而不是由业务处理系统直接处理，做了一次缓冲,极大地减少了业务处理系统的压力；
队列长度可以做限制，事实上，秒杀时，后入队列的用户无法秒杀到商品，这些请求可以直接被抛弃，返回活动已结束或商品已售完信息。
消息驱动的系统
系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；
具体场景：用户新上传了一批照片， 人脸识别系统需要对这个用户的所有照片进行聚类，聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。
若使用消息队列：
这三个子系统间由消息队列连接起来，前一个阶段的处理结果放入队列中，后一个阶段从队列中获取消息继续处理。
避免了直接调用下一个系统导致当前系统失败；
每个子系统对于消息的处理方式可以更为灵活，可以选择收到消息时就处理，可以选择定时处理，也可以划分时间段按不同处理速度处理。
延迟队列
延迟队列就是进入该队列的消息会被延迟消费的队列。而一般的队列，消息一旦入队了之后就会被消费者马上消费。
延迟队列多用于需要延迟工作的场景。最常见的是以下两种场景：
延迟消费。
场景一：在订单系统中，一个用户下单之后通常有30分钟的时间进行支付，如果30分钟之内没有支付成功，那么这个订单将进行一场处理。这是就可以使用延时队列将订单信息发送到延时队列。
场景二：用户希望通过手机远程遥控家里的智能设备在指定的时间进行工作。这时候就可以将用户指令发送到延时队列，当指令设定的时间到了再将指令推送到只能设备。
场景三：用户注册成功之后，需要过一段时间比如一周后校验用户的使用情况，如果发现用户活跃度较低，则发送邮件或者短信来提醒用户使用。
延迟重试。
比如消费者从队列里消费消息时失败了，但是想要延迟一段时间后自动重试。
如果不使用延迟队列，那么我们只能通过一个轮询扫描程序去完成。这种方案既不优雅，也不方便做成统一的服务便于开发人员使用。但是使用延迟队列的话，我们就可以轻而易举地完成。
阻塞队列
阻塞队列与普通队列的区别在于，当队列是空的时，从队列中获取元素的操作将会被阻塞，或者当队列是满时，往队列里添加元素的操作会被阻塞。试图从空的阻塞队列中获取元素的线程将会被阻塞，直到其他的线程往空的队列插入新的元素。同样，试图往已满的阻塞队列中添加新元素的线程同样也会被阻塞，直到其他的线程使队列重新变得空闲起来