当前各种 RPC 中间件技术已经广泛应用于各个领域。其中，服务器之间消息通讯这种功能广泛应用于这些中间件中，于是，将这种面向消息的中间件（ Message Oriented Middleware ， MOM ）抽象出来，形成通用的消息中间件，成为业内主流。目前消息中间件的标准主要有： JMS 和 AMQP 。实现则是百花齐放。

消息中间件从功能上需要解决以下问题：

1． 同步或异步的消息传输，尤其是异步的消息传输

同步发送消息是发送消息后，阻塞等待消息是否发送成功的回馈，如果设置有超时时间，则超时后跳出阻塞状态。

异步发送消息是发送消息后，不阻塞立即执行其他操作。如果关心消息是否发送成功，则可以通过回调函数（Java 中的 Listener ）处理消息是否成功。

2． 消息的安全性，消息中间件对持久的支持

在分布式系统中，消息从发送到接收，环节非常多，没有任何一个环节是安全的，而任何环节出了问题，都会导致丢消息。当有需求是，我们必须保证在不是绝对安全的多环节里，完成消息安全的传输。这其中，消息中间的持久是非常重要的。

3． 消息的重发性

如果使用的系统保证了幂等性，则对此没有要求。否则，有些场景需要保证消息不重发。在既要保证消息安全，又要保证消息不重发，是非常困难的。目前业内还没有人能解决此问题。

目前，在有消息重发的情况下，使用的系统都是使用状态机保证了系统对消息的幂等性。

4． 消息的顺序性

如果使用的系统有要求，则有可能需要保证消息的顺序。在大规模分布式不可靠环境下，在保证消息传输高效和消息安全的情况下，要解决此问题，也是非常困难的。

如果只是小规模的系统，对性能要求不高，可以以服务器时间为准，使用排队队列即可解决。

如果以发送端时间为准，并且保持顺序的消息由此一个发送端发送，则使用消息序号即可解决。

另外，有些系统只需要满足局部的消息顺序性，在排序消息数量不大的情况下，可以使用多条排序消息一次性发送解决。

5． 消息传输模型：点对点的传输消息（ PTP ），订阅 / 发布模型（ Pub/Sub ）

PTP ，就是你在消息方设置消息接收者的唯一标识符，然后，消息发送方和消息接受方建立一一对应的关系。消息发送方发送所有的消息都被消息接收方接收。

Pub/Sub ，就是消息发送方和消息接收方都确定自己的发送和接收消息的标签（或者你可以理解为组 GroupID），所有有这个标签的消息，订阅了这个标签的消息接收方一定能接收到。

JMS （ Java 消息服务， Java Message Service ）是专用于 J2EE 的一种消息中间件规范。它主要做了接口上的规范，消息传输模型和消息类型的规范，并没有给予实现。同样，它也完全没有给出服务器端的架构，你甚至可以不使用服务器直接在客户端之间传输消息（虽然可能最终结果只是一个玩具）。http://java.sun.com/products/jms/docs.html 。 JMS 也没有规定消息的顺序，安全，重发等特性。

AMQP （高级消息队列协议， The Advanced Message Queuing Protocol ）是一种和语言无关的，在金融行业使用的新兴消息中间件，目前成为消息中间件圈内关注的焦点。与 JMS 规范了 API 不同，它是一个异步消息传递所使用的应用层协议规范。 AMQP 的原始用途只是为金融界提供一个可以彼此协作的消息协议，而现在的目标则是为通用消息队列架构提供通用构建工具。 http://www.amqp.org/

目前开源的消息队列有：kafka一般用于日志采集，RocketMQ，rabbitMq，

淘宝开源分布式消息中间件Metamorphosis， 消息中间件分为推模式和拉取模式，推模式：推送给消费者就ok，拉模式：消费者主动轮训消息队列，微服务系统开发消息异步处理是不可缺少的环节