消息的基本知识

作者：skyfree

为何使用消息

·         系统集成的优良渠道

·         不同系统或平台沟通的渠道

·         异步机制。提高系统可靠性的同时，消除了一部分系统瓶颈。

消息的定义

自包含的数据包，其中包括了商业数据以及网络路由标头信息。而消息在不同系统之间的交互是通过中间件的协调来实现的。

面向消息的中间功能包括：容错性、负载平衡、可扩展性、事务处理

消息的使用过程

1、 创建消息

2、 加载负载信息

3、 添加路由信息

4、 发送消息

消息的发送者和接受者之间是松耦合的关系，并不依赖于对方。

JMS可以使用相同接口访问不同的系统。如果其他系统提供了兼容JMS的接口，那么JMS就可以访问该系统。

JMS的优点：

异构系统集成

有些系统提供了JMS的接口，这说明这些系统可以使用JMS API进行访问，但这些系统也可以拥有自己本地的访问接口面向特定的语言或平台。

进行异构系统集成的方法有：FTP/sneakernet/database sharing/RPC/Web Service

但是，消息队列仍然是集成异构系统的优秀解决方案，最重要的原因是消息机制解除了数据与功能实现之间的耦合，也解决了发送消息和接收消息之间的耦合。Web Service在一定程度上也实现了上面的特点，但由于它缺乏可靠性，因此并不是异构系统集成的最佳解决方案。

降低系统瓶颈

不同的系统之间进行信息交流，但这种交流并不是时时刻刻处于和谐而有序的状态，多数情况下，不同系统之间进行信息交流最会存在，“你等我，我等你”的现象，这种等待不能使子系统很好的发挥效率，那些处理效率低下的子系统，就会产生整体系统的瓶颈。

提高可扩展性

消息机制可以有效的提高可扩展性、系统吞吐能力以及降低系统响应时间。

1、消息系统中的可扩展性是通过引入多个消息接收器，同时处理不同消息而实现的。

2、通过异步传输机制来提高整体系统的可伸缩性。

通过对组件之间的解耦，可以实现不同系统之间的横向扩展。(我认为在设计模式中体现的纵向和横向思想是：继承体现的是纵向的垂直扩展，而组合则体现的是横向的低耦合的聚合形式。)，尽管我可以在消息队列中使用更多的消息监听器，但是对于消息系统本身的数据库来说，它的信息处理能力是有限的，因此消息系统本身的数据库将可能成为消息系统的又一瓶颈。

增加终端用户的效率

通过使用异步传输来实现增加终端用户效率的目的。这种思想与AJAX的思想是一致的。

系统架构的灵活性和易改动性

使用消息机制可以提高整个系统架构的灵活性。这是因为在使用消息机制的时候，已经引入了解耦和抽象的思想。整个系统中的子系统、组件、服务均可以抽象成一个点。抽象意味着具体是可以变化的，系统之间的关联性不是固定不变的。可以在不知道内部具体实现的情况下，实现与系统的交互，这就实现了系统的可变动性。

企业消息

企业消息机制并不是新概念，曾经有过：

IBM        WebSphereMQ

SonicMQ

Microsoft Message Queuing(MSMQ)

TIBCO Rendezvous

ActiveMQ(开源的，可以用在生产环境)

目前，引入了新的概念比如说

SOA, Service-Oriented Architecture:

在微软的产品中，WCF代表就是这一个方向，事实上WCF体现的是面向接口的架构思想。

ESB, Enterprise Service Bus:

企业服务总线，ESB通过HTTP协议以及消息机制，实现不同系统之间的交互。在实际中，它常常用来对企业内部已有的不同系统之间的集成整合。

企业消息的关键点是异步机制，异步意味着消息的发送者和接受者之间的解耦，消息本身将成为自治单元，自己要对自己负责，自己要承载所有的必要信息。

企业消息的实现原理非常简单：就是通过对消息的封装，之后将消息发送到消息中间件，再有消息中间件发送打单个或多个系统。

面向消息的中间件的架构

集中式架构：消息服务器对整个系统的消息路由负责。

非集中式架构：分布服务器来处理客户端。

混合式架构：上述两种结构的混合型

传输协议

                TCP/IP, HTTP, SSL, IP广播

消息客户端的含义

                整个消息系统是由消息客户端和消息中间件服务器组成，消息客户端发送消息到消息中间件服务器，而后服务器再将这些消息发送和其他消息客户端。

集中式架构

这个消息系统依赖消息服务器，消息服务器充当路由的角色或者是中间人的角色。它要负责消息在不同系统之间的传递，实质上它是实现了消息客户端之间的解耦。因此，消息客户端可以很方便的加入到消息系统或从消息系统中移除。

但同时也要看到，如果消息服务器停机，那整个系统将不能工作，因此它的可靠性并不是最高的，在实际中，常常将这种集中式架构作为分布式集群的一个逻辑单元。

非集中式架构

在网络层次上，所有的非集中式架构都采用了IP广播的形式。客户端可以加入到一个或多个IP广播组，可以通过广播的形式发送和接收消息，消息的发送和接受完全是通过网络层来实现。

混合式架构

非集中式架构意味着使用了广播机制，而集中式架构意味着使用了TCP/IP协议。有些消息系统是将这两种形式进行了融合。

JMS中的消息模型

JMS支持两种类型的消息模型：

1、 点到点模型,Point to Point,P2P: 一对一模型

2、 发布-订阅模型, Publish and subscribe, pub/sub：一对多模型

在JMS系统中，消息客户端成为JMS客户端，消息系统称为JMS提供者。JMS系统就是有许多的JMS客户端组和JMS提供者组成的。在JMS消息客户端，如果是用于产生消息的称为消息生产者，如果是接收消息的称为消息消费者。

点到点模型

支持同步或异步传输（通过队列实现）

消息生产者：sender， 消息接受者：receiver

基于推/拉模型创建队列。

相对于发布-订阅模型，点到点的模型的耦合度更高。原因就是，当使用点到点的模型时，发送者往往知道接收者是谁。

支持负载均衡

特征：发送到队列的消息，有且仅有一个客户端可以接收。

发布-订阅模型

通过主题来发布消息（topic）

消息生产者：publishers， 消息接收者： subscribers

实现一对多的消息发布（广播的形式）

以推模型实现

松耦合实现

结合观察者的设计模式来理解这种发布-订阅模型。

订阅者的类型：

临时订阅者：监听时，可以接收到消息，不监听时，不可以接收到消息。

永久订阅者：可以接收到所有的消息，即使是在离线的时候，也可以获取到消息。

JMS API

Sun JSR-914

JMS并不是消息系统，也就是说它并不是想微软的消息队列一样的是个具体产品，它仅仅是一组抽象的接口和类，而这些接口和类可以确保消息客户端与消息系统之间的交互。

JDBC, 以抽象的方式访问关系数据库

JNDI， 以抽象的方式访问命名和目录服务

JMS， 以抽象的方式访问消息系统。

JMS API主要分为三个部分：

1、 通用API：点到点API， 发布-订阅API

七个主要的JMS API 接口

ConnectionFactory

Destination

Connection

Session

Message

MessageProducer

MessageConsumer

ConnectionFactory, Destination通过JNDI实例化。

其他接口通过工厂方法来创建

 

JMS 通用API 实例化过程。

Point to Point API

·         QueueConnectionFactory

·         Queue

·         QueueConnection

·         QueueSession

·         Message

·         QueueSender

·         QueueReceiver

 

Publish-and-Subscribe API

·         TopicConnectionFactory

·         Topic

·         TopicConnection

·         TopicSession

·         Message

·         TopicPublisher

·         TopicSubscriber

 

场景

SOA, Service-Oriented Architecture

SOA架构系统是，考虑的是接口而非实现。SOA的思想给企业服务总线（ESB）以更好的启示。目前JMS支持绝大多数的商业和开源ESB产品，但是微软不支持JMS接口，因此不能使用JMS来访问（MSMQ/BizTalk）

EDA, Event-Driven Architecture

前提假设：过程和事件的结合是变化的，复杂的。触发事件会引发响应的处理过程，在这里事件就可以认为是一种消息