消息订阅和发布

田玲 | 2014-04-28 | | 1439次阅读

中间件的异步通信的两个实例是消息存储和转发，以及消息订阅和发布。消息的订阅和发布应该是属于IBM在介绍EAI专题中提到的EAI层次化解决方案中的应用连接。

SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。这些接口是中立的方式定义的，独立于硬件平台、操作系统和编程语言。

消息的存储和转发模式

消息队列既是发送者发送消息的目的地，也是接收者接收消息的消息源，发送者和接收者通过队列交换消息。消息队列是一个驻留消息的容器，直到接收者从队列中接收到消息。消息队列独立于发送程序和接收程序，在进行通信的应用之间充当缓冲区。在这种类型的通信中，发送者应用和接收者应用分别与消息队列相关联。

消息订阅/发布的模式

什么是消息订阅/发布？

最早公开描述发布/订阅系统之一的是Isis Toolkit的“新闻”子系统，1987年，在计算机协会 (ACM)的操作系统原理的研讨会上，,在论文《在分布式系统中利用虚同步》中。该文描述的发布/订阅技术是由Frank Schmuck发明的。

拓扑结构上，发布者将消息发布到一个中间的消息代理，然后订阅者向该消息代理注册订阅，由消息代理来进行过滤。消息代理通常执行存储转发的功能将消息从发布者发送到订阅者。

消息订阅和发布是除消息存储与转发外另一种可靠传输消息的方式。与存储与转发相比，消息订阅和发布具有更好的伸缩性。在这类异步通信中，生成消息的应用发布该消息，需要这类消息的其他应用则订阅该消息。发布应用将包含新信息的消息放置在针对每一个订阅者的队列中。系统中的每一个应用都可以有两个角色，可以充当不同类型信息的发布者和订阅者。

发布/订阅消息传送的流程如下。假设发布者应用发布了一个具体主题的消息，诸如向零售商发送新产品的价格或新产品的描述。多个订阅应用都可以订阅该主题，并接收发布应用所发布的消息。如下图所示，消息发布者发布消息，将消息发布到主题，对于已经在该主题上注册的订阅者来说，一旦发布者将消息发布到主题，这些订阅者即可接收这些消息。图2.12描述了发布/订阅的工作流程。

消息过滤：

在发布/订阅模型中，订阅者通常接收所有发布的消息的一个子集。选择接受和处理的消息的过程被称作过滤。有两种常用的过滤形式：基于主题的和基于内容的。

在基于主题的系统中，消息被发布到主题或命名通道上。订阅者将收到其订阅的主题上的所有消息，并且所有订阅同一主题的订阅者将接收到同样的消息。发布者负责定义订阅者所订阅的消息类别。

在基于内容的系统中，订阅者定义其感兴趣的消息的条件，只有当消息的属性或内容满足订阅者定义的条件时，消息才会被投递到该订阅者。订阅者需要负责对消息进行分类。

一些系统支持两者的混合：发布者发布消息到主题上，而订阅者将基于内容的订阅注册到一个或多个主题上。

优势：

松耦合： 发布者与订阅者松散地耦合，并且不需要知道对方的存在。由于主题是被关注的，发布者和订阅者可以对系统拓扑毫无所知。发送者和订阅者都可以继续正常操作，不管对方。在传统的紧耦合的客户端-服务器范式中, 在服务器进程不运行时，客户端无法发送消息给服务器，服务器也无法在客户端不运行时接收消息。许多发布/订阅系统不单解耦发布者和订阅者的位置，还从时间上解耦发布者和订阅者。

可缩放性： 对于相对小的安装，发布/订阅通过并行操作，消息缓存，基于树的或基于网络的发送等，与传统的客户端/服务器相比，提供了更好的可缩放性的机会。可是，当系统升级城外包含数千台服务器的数据中心共享发布/订阅基础设施时，这一好处通常会丧失；实际上，在大型部署中在高负载时发布/订阅产品的可缩放性是一个非常大的研究课题。

消息机制与应用程序的远程调用和网络连接的最大区别就在于，发出消息后，不用关心其所要到达的地方，这些工作会自动完成，我们只需要关注消息如何发出。

EAI内涵及技术研究

什么是EAI？

EAI(Enterprise Application Integration) 是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了 EAI，企业就可以将企业核心应用和新的Internet解决方案结合在一起。

英文原文：

Enterprise application integration is the practice of understanding, defining, and organizing the data and business processes of enterprises and devising a structured approach to communicating changes in the state of enterprise data or requesting changes in the state of enterprise data.

EAI的概念通常是指的在信息系统集成过程中的概念、原则和问题。其出现的背景可以这样理解，所有企业都趋向于不断发展壮大，而企业内部会使用到大量的信息系统，而且随着企业规模的扩大，企业与企业之间合作关系的进一步密切，需要解决不同异构系统之间的数据交互，跨企业之间的数据共享处理等。这就促使企业急切地需要一套可以应用在所有应用集成上的方法。The goal of the OpenEAI project is to explore and codify the science of enterprise application integration in a practical, public, and methodical way.（摘自http://www.openeai.org/live/?p=5&sub=1）

企业应用集成（EAI）的目标就是将组织的内部应用转换为集成在一起的企业框架。为了实现这一点，企业应用集成以业务流程的形式将企业的各种应用无缝地集成起来，并可进行无缝的通信。

一个典型的集成各种企业信息系统的EAI解决方案如下：

尽管EAI常常表现为对一个商业实体(例如一家公司)的信息系统进行业务应用集成，但当在多个企业系统之间进行商务交易的时候，EAI也表现为不同公司实体之间的企业系统集成，例如B2B的电子商务。主要的功能在解读并转换异构系统间不同的应用程序的数据、

实施EAI的好处：

1) 首先能减低开发成本和IT维护成本。

2) 其次是优化流程。应用程序整合的主要目的在于不同系统间的执行过程连接起来，让各个应用程序间流程管理更加科学、合理地进行。

3) 通过将人工过程自动化来降低管理成本。

4) 通过更高效的价值链过程降低运营成本。

5) 提供新服务，提高用户满意度和收入。

6) 通过推出新服务和节目来获得更高的客户满意度和忠诚度。

7) 加速商业决策的过程。

8) 增强企业的灵活性和适应性。

9) 更佳和更快的业务决策。

EAI的工具消息代理中间件：

消息代理中间件：消息代理（Message Broker）是一种在数据源与目的地之间移动数据使信息处理流畅的软件技术，数据源与目的地包括已有的应用、文件、数据库、对象（如CORBA、COM）、硬拷贝输出及Web客户端等。消息代理技术实现之后的产品形式就是一种中间件。它是面向消息中间件（MOM）的一部分。

现有的EAI平台工具-消息中间件

IBM的WebSphere MQ

IBM的MB（这个是基于消息存储和转发的一种EAI平台工具，跟我们想要采用的消息订阅和发布的有所区别）

MB是消息代理的简称。由于消息的异步性，我们只需要关注消息的发出，一旦消息发出后，我们不用再继续跟踪它执行。中间件会完成其他剩下的工作，这些工作包括统一数据，出错后的提示信息等。消息代理包含两层概念：“消息”和“代理”。

消息（Message Queue：MQ），是IBM的消息中间件主打产品，IBM几乎所有SOA相关的产品，都是构建于MQ之上的。可以把MQ理解为一个可靠传输的通道。

有了MQ，可以不用考虑网络连接，平台异构，但是在配置的时候，必须指明消息传递的目的地，比如IP地址，这样增加了程序间的耦合性，如果一个程序变更了位置，与其相关的组件都需要变动，轻则改配置，重则重写代码。这就需要“代理”来起作用了。

有组件的MQ队列都可以直接连接到MB上，MB相当于一个公共服务中心。MB接收所有消息，然后自动分析其中的内容，找到相应的目的地，进行路由转发，好比你在写信时，只需写明收信人的姓名、身份证，哪怕收信人搬到天涯海角，只要他在MB邮局中登记了，那MB就可以把信交给他，这样进一步地分离了业务和底层通信，我只需要知道业务概念上的“他”，就可以把消息交给他。此外，MB还可以进行消息转换，这就像是自动翻译信件，我现在可以用中文写封信给本拉登，我不需要知道他具体藏在哪里，信件就会自动翻译成阿富汗的文字，送到本拉登手里。

所以，代理的两个核心功能就是：“消息路由”和“消息格式转换”。MB本质上也是一个服务总线，所有的服务组件接入到MB中，服务将消息塞给MB，MB来决定怎么转发，这样让服务愈加成为一个独立的实体，和其他服务的耦合性进一步降低，从而达到SOA的境界。

MB的消息流：

代理broker是真正体现MB设计思想的地方，上面的图片中有像流程图一样的东西，即message flow，是消息的流程图（从什么地方流进来，再从什么地方流出去）；还有message set，即消息集，说白了是描述消息长什么样子，它的结构、内容是怎样的。其实，message flow对应了上文所说的“消息路由”，而message set则对应“消息格式转换”，你肯定要清楚两种消息的格式，才能定义互相转换的规则。

Kafaka

Kafka是一个分布式的消息发布-订阅系统。它的特性如下：

1) 通过在O(1)的磁盘数据结构上提供消息持久化，对于即使数以TB的消息存储也能够保持长时间的稳定性能。

2) 高吞吐：在商用机器上可以提供每秒数十万条的消息

3) 支持在Kafaka服务器集群上进行messages分片，并在把messages在消费集群的机器上分配的同时维护每个分片的顺序信息。

4) 支持将数据并行的加载到Hadoop中。

OpenEAI研究

OpenEAI defines a straightforward messaging protocol and message format in XML for both request/reply and publish/subscribe messaging models for any enterprise message object.

OpenEAI为请求/应答和发布/订阅的消息模型定义了一个明确的消息协议和XML的消息格式。这个消息协议（message protocol）是基于EAI固有的原则，并且不与任何一种用在集成上的技术相绑定（技术无关性的）。

The OpenEAI methodology outlines a clear process for documenting requirements for interfaces among enterprise applications, requirements for enterprise data services, and requirements for information exchange with trading partners.（定义了一个过程来描述接口的要求）然后有一个理解分析的模板和说明来促进这个过程。（原文描述：A comprehensive analysis template and instructions facilitate this process for analysts and functional experts.）

这个分析过程最后会得到一个定义企业消息对象的XML，并在分析过程中指出这个OpenEAI Message Protocol中定义的哪个XML消息是企业消息对象所要求的。（This analysis process culminates in defining enterprise message objects using XML and specifying which XML messages defined in the OpenEAI Message Protocol will be required for each enterprise message object identified during the analysis process.）

The OpenEAI application foundation和message object APIs这两个文档为构建应用入口（application gateway）和消息感知应用（message-aware application）提供了模式和一个基础，它采用的是由XML消息对象概念中衍生出的一种叫做business-objected-oriented API来在集成分析中进行区分。它的开发语言是用的java，但是其他非java的技术一样可以面向这样的gateway或者是制作用OpenEAI的概念和基础API来实现的message-aware。