消息中间件与JMS标准

初识消息中间件

维基百科上对于消息中间件的定义是"Message-oriented middleware(MOM) is software infrastructure focused on sending and receiving messages between distrubuted systems"。解释起来就是消息中间件是在分布式系统中完成消息的发送和传递的基础软件。看张图来更直观地理解消息中间件：

看到消息中间件有两个好处：

一、异步

二、解耦

应用A和应用B都和消息中间件打交道，这两个应用之间并不直接联系，这样就完成了解耦，目的是但愿收发消息的双方彼此不知道对方的存在，也不受对方的影响，因此将消息投递给接收者实际上都采用了异步的方式。

 

透过示例看消息中间件对应用的解耦

以苹果的App Store为例吧，App Store有一个功能：用户充值成功后向用户手机发送一条短信，算是一个安全选项。最直观的，咱们会这么实现：

而后，咱们须要把用户付款的信息（用户名、时间、IP等数据）传给安全系统，安全系统会根据安全策略进行相关的判断和处理，所以结构变成：

这么看起来还好，那么若是再增长一些要被调用的系统呢？好比：

这会让付款系统变得很是复杂，每增长一个在付款成功以后须要调用的系统，就须要修改付款系统来进行相关的调用。优雅一点的实现是把这个付款成功后的服务调用变为一种可扩展的配置，甚至能够动态生效，但这只能下降变动时的开发和部署成本，并无下降复杂性。付款系统被迫要依赖很是多的系统。

 

引入消息中间件进行服务解耦

能够考虑一下，从付款的角度看，这些系统是付款系统必须依赖的吗？答案是否认的，付款系统只须要验证用户帐号、付款帐号、付款密码的合法性，因此付款系统依赖的是可以系统用户帐号、付款帐号、付款密码的系统，而上图中的系统其实都不是付款系统必须依赖的系统。相反，这些系统都是必须依赖付款系统的，由于它们都关心付款是否成功。

在这样的场景中，咱们须要经过消息中间件把上面的结构解耦，上面结构中的服务调用将会被固定格式的消息传递所取代。付款系统负责向消息中间件发送消息，而其余的系统则向消息中间件来订阅这个消息，而后完成本身的工做，如图所示：

这样，经过消息中间件，付款系统就不须要关心到底有多少个系统须要知道付款成功这件事情了，也不用关心如何通知它们，只须要把登录成功这件事情转化为一个消息发送到消息中间件就行了，这样，须要了解付款成功这件事情的系统本身去消息中间件订阅就好了，而且各个系统之间也是互不影响的。

 

JMS概述

JMS是Java Message Service的缩写，即Java消息服务，它是Java EE中一个关于消息的规范，而Hornetq、ActiveMQ等产品是对这个规范的实现。若是是企业内部或者一些小型的系统，直接使用JMS的实现产品是一个经济的选择，而在大型系统中有一些场景不适合使用JMS。

在大型互联网中，咱们采用消息中间件能够进行应用之间的解耦以及操做的异步，这是消息中间件两个最基础的特色，也正是咱们所须要的。在此基础上，咱们着重思考的是消息的顺序保证、扩展性、可靠性、业务操做与消息发送一致性，以及多集群订阅者等方面的问题。固然，这些咱们要思考的东西，JMS都已经想到了，先看下JMS能帮开发者作什么：

一、定义一组消息公用概念和实用工具

全部Java应用程序均可以使用JMS中定义的API去完成消息的建立、接收与发送，任何实现了JMS标准的MOM均可以做为消息的中介，完成消息的存储转发

二、最大化消息应用程序的可移植性

MOM提供了有保证的消息发送，应用程序开发人员无需了解远程过程调用（PRC）和网络/通讯协议的细节，提供了程序的可移植性

三、最大化下降应用程序与应用程序之间的耦合度

因为MOM的存在，各个应用程序只关心和MOM之间如何进行消息的接收与发送，而无须关注MOM的另外一边，其余程序是如何接收和发送的

 

JMS两种消息模型

一、点对点模型

点对点模型（Pointer-to-Pointer）相似这样：

这种模型总结几点：

（1）一个消息中间件关联多个队列生产者和消费者

（2）一条消息仅仅能被一个消费者消费

（3）多个消费者正在监听队列上的消息，那么中间件将根据先来先得的原则肯定由哪一个消费者接收下一条消息，若是没有消费者正在监听队列，那么消息将保留在中间件中，直至消费者链接到中间为止

（4）收到消息后消费者必须确认消息已被接收，不然中间件江认为该消息没有被接收，那么这条消息仍然能够被其余消费者接收。程序能够自动确认，不须要人工干预

（5）生产者和消费者的运行前后没有限制

（6）此模型中，消息不是自动推送给消费者的，而是要消费者中间件中请求得到

二、发布/订阅模型

发布/订阅（Publish-Subscribe）模型相似这样：

这种模型中，仍是以分点的形式总结：

（1）有一个重要的概念topic，能够认为是主题

（2）生产者发布消息，消费者订阅感兴趣的消息，生产者将消息和一个特定的topic（主题）连在一块儿，中间件将根据消费者注册的topic，将消息传递给消费者

（3）发布/订阅模式容许多个消费者接收同一条消息，只要这些消费者注册了同一个主题

（4）消费者必须先运行，订阅主题，而后再等待生产者运行，这么点对点模型有所差异

（5）该模型中，消息会自动广播，消费者无须经过主动请求或者轮训主题的方法来得到新的消息

 

JMS为提供的要素

JMS为发开者提供了不少的要素，看一下比较重要的几个：

要    素	做    用
Destination	表示消息所走通道的目标定义，，用来定义消息从发送端发出后要走的通道，而不是接收方。Destination属于管理类对象
ConnectionFactory	顾名思义，用于建立链接对象，ConnectionFactory属于管理类的对象
Connection	链接接口，所负责的重要工做时建立Session
Session	会话接口，这是一个很是重要的对象，消息发送者、消息接收者以及消息对象自己，都是经过这个会话对象建立的
MessageConsumer	消息的消费者，也就是订阅消息并处理消息的对象
MessageProducer	消息的生产者，也就是用来发送消息的对象
XXXMessage	指各类类型的消息对象，包括ByteMesage、ObjectMessage、StreamMessage和TextMessage这5种

在JMS消息模型中，根据点对点模式和发布/订阅模式，这些要素由扩展出了各自的内容：

JMS标准	点对点模式	发布/订阅模式
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Destination	Queue	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver	TopicSubscriber

JMS是一个标准，具体仍是依赖实现，当前常见的JMS实现有ActiveMQ、ZeroMQ、RabbitMQ等，Kafka是一种相似JMS的实现，下一篇文章将会重点讲解一下Kafka，至于为何，仍是和之前写文章同样的缘由，由于工做用，呵呵。