金蝶ApusicMQ产品白皮书.docx
《金蝶ApusicMQ产品白皮书.docx》由会员分享，可在线阅读，更多相关《金蝶ApusicMQ产品白皮书.docx（20页珍藏版）》请在冰豆网上搜索。
金蝶ApusicMQ产品白皮书
ApusicMQ技术白皮书
金蝶中间件
2006.05.10
介绍
消息的流动和整合
信息已经成为驱动企业的一种动力，是一种为客户提供更好服务的动力，是改进产品和服务的动力，是工作得更快、更有效和更具灵活性的动力。
当然，也是通过降低成本、更好地利用企业资源的一种动力。
信息流过整个企业的方式决定了构成上述动力的能力，当合适的信息流能自由、快速地传递给需要它的人员时，整个企业就能获得一种动力，从而能够更好地进行决策，能够更快地回答问题，更多地节省客户、合作伙伴和职员的时间和金钱，更多地获取机会同时问题得到更好地解决。
但是，如果您的企业信息资源受到了保存或产生它们的系统的限制，那么怎么办？
您需要打开您的信息通道，让自由流动的信息融入您的业务活动中；您需要打破系统和应用之间的障隘，使数据不再受它们的限制。
ApusicMQ的主要目的是帮助您从信息投资中获取最大收益。
通过打破以前不兼容系统之间的障碍，ApusicMQ使您能够跨整个企业统一地利用信息资源。
财务部可以与市场部交流；分销部知道销售情况；执行官根据详实的事实而不是一些假设来做出决策；您的职员能立即对问题进行回答，而不需要跑到数据中心去。
还不仅仅是这些。
您的企业信息资源对提供更好的客户服务和保持与您商业合作伙伴良好的合作关系也非常关键。
更好的服务取决于您能让面向客户的职员有效地回答客户问题的能力。
另外，与供应商的密切合作意味着快速、精确地共享交易数据。
ApusicMQ能让您完成以上的所有工作，甚至更多。
ApusicMQ提供的有保证的应用到应用通信能力意味着您可以充满信心地将任何系统与其它的系统连接在一起，同时保证信息的连通性。
消息中间件
消息中间件使独立的分布式应用程序或应用程序组件可以通过消息进行交互。
这些组件无论是在同一主机、同一网络上运行，还是通过Internet松散地连接在一起，均可使用消息传送来传递数据以协调各自的功能。
为了使大量组件能够同时交换消息，并支持高密度吞吐量，消息的发送就不能取决于消费者是否已做好接收消息的准备。
如果某个消费者正忙或处于脱机状态，系统必须允许进行这样的操作：
当该消费者准备就绪时再接收消息。
这种去耦合的消息发送与接收称为“异步消息传送”。
异步消息传送模型非常适于完成集成复杂系统的任务；对于此类系统，在执行操作的过程中让一个组件为另一个组件提供支持既不切实际，也不值得这样做。
尽管异步消息传送放弃了同步系统所具有的某些控制功能，但大大提高了组件间相互作用的灵活性。
它还增强了系统的稳定性，因为一个组件的故障并不会导致整个系统瘫痪。
理解ApusicMQ
企业消息传递框架被设计用于使得一个或多个应用能够克服各种障碍进行通信。
常见的屏障包括：
异步通信的需求，多个应用获取同一条消息（多重传输）的需求，大多数系统都彼此异构，以及网络故障等。
面向消息的中间件系统来为不同类型的系统提供消息通道。
ApusicMQ为应用提供了一种公共的、可靠的方式，使这些应用能够轻松地创建、交换和处理消息，而无需考虑消息传递客户机的实现细节。
消息被发送到服务器目的地。
消息传递客户机只需简单地声明对某个特定的目的地感兴趣，然后通过那个目的地与消息传递服务器进行交互。
消息只是一个字节流（这个字节流可以是一个XML文档、一个序列化的Java对象（只是针对Java客户端有此特性）、一个文本字符串或甚至是一条空消息）。
对消息的解释留给应用程序域来做；ApusicMQ基础结构不对消息施加任何语义和结构限制。
消息存储在队列里，ApusicMQ服务器允许您将消息加入到队列以及从队列中取走消息。
从概念上来讲，这与现实生活中真实邮件的传递方式没什么不同。
消息的发送方只负责使用正确的包装，提供正确的地址，并附上适当的邮资。
邮局（这里是一个ApusicMQ系统）处理与消息的安全可靠的传递相关的所有问题，而不管出现在他们面前的任何障碍（机器故障，天气恶劣，等等）。
在一个ApusicMQ系统中，客户机之间的耦合性比较弱，这允许它们不必真正地全天“在线”便能维持服务的最佳质量。
如果能够去掉应用一直处于可用状态这一需求，那么维护和伸缩性将变得更加易于管理。
可以在一天中的任何时候将应用离线，更新应用，或者作为例行的维护工作刷新应用，而不必担心会影响服务的质量。
ApusicMQ不仅为信息传送提供必要的基础结构，而且它还能处理与服务质量、安全性、可靠性和性能有关的大部分基础结构问题。
JMS是J2EE规范中提出的消息中间件服务（JavaMessageService™）规范,提供应用程序间异步或同步的消息传递和管理服务，ApusicMQ中包含了高效、可靠的消息服务。
ApusicMQ中的消息服务接口同时既遵循JMSAPI规范，也对部分高级特性进行了功能扩充。
提高了企业应用中各组件的可移植性、松耦合特性，同时更加高效可靠；为分布式企业应用异步交换关键业务数据和事件提供了可靠而灵活的服务。
ComputerA,B,C分别为提供消息服务的ApusicMQ，称为Router,他们之间的连接被称为Connector，客户端直接与ComputerA连接，客户端要把消息传送到ComputerB的队列和主题时，只需指明接收消息的主机名和队列或主题的名称发送消息即可，ComputerA中的消息服务将会查找配置文件中的设置，如从A到B间有通路连通，消息服务将会按照最短路径发送消息到指定服务器（ComputerB）的指定队列或主题，如A到B无有效连接，消息将被保存在某一连通的服务器上，待有有效通路之后再发送消息。
应用场景
要求
企业应用程序系统一般都包括大量的分布式组件，这些组件在全天候的关键任务操作中交换数以万计的消息。
要支持这样的系统，除了支持异步消息传送外，企业消息传送系统还必须满足以下要求：
◆可靠性
从一个组件向另一个组件传送的消息不能由于网络或系统故障而丢失。
这就意味着，系统必须能够保证消息的传送。
◆安全性
消息传送系统必须支持基本的安全功能：
用户验证、消息及资源的访问授权和线上加密。
◆可伸缩性
消息传送系统必须能够在不降低系统性能或消息吞吐量的前提下容纳不断增长的负荷，即用户数量和消息数量的增加。
随着业务和应用程序的扩展，这将成为一个很重要的要求。
◆可用性
消息传送系统的停机时间必须非常短。
也就是说在发生故障时，系统具有足够的冗余以继续提供消息传送服务。
类别
集中式（MOM）消息传送
MessageQueue采用集中式消息传送系统，如图1中所示。
在此类系统中，每个消息传送组件只需与一个中央消息服务保持连接。
组件通过定义完善的接口与消息服务进行交互。
点对点消息传送
图中左侧所示为另一种系统，即点对点系统，在该系统中，每个消息传送组件均与所有其他组件保持连接。
点对点系统可以实现快速、安全和可靠的传送，但是支持可靠性和安全性的代码必须保存在每一个组件中。
消息的发送和接收紧密耦合，因而难以实现异步传送。
随着组件被不断添加到系统中，连接的数量将成指数级增加，因此，系统的可伸缩性很差。
在点对点系统中也很难实施集中式管理。
在集中式系统（企业首选消息传送方案）中，消息服务能够在组件间进行消息路由和传送，并负责可靠且安全地进行传送。
因为这种系统中的组件间是松散耦合的，所以更容易实现异步消息传送。
随着消息传送组件被不断添加到系统中，连接的数量成线性增加，这样就可以轻松地通过调整消息服务来调整系统。
基本消息服务体系结构
图2所示为集中式消息传送系统的基本体系结构。
它包括消息发送者和消息接收者，它们通过公共的消息服务来交换消息。
同一消息传送组件（或应用程序）中可以保存任意数量的消息发送者和消息接收者。
消息发送者使用消息服务编程API将消息发送至消息服务器。
消息服务器进行消息路由并将消息传送至一个或多个已注册申请此消息的消息接收者。
接收者使用消息服务编程API来接收消息。
消息服务负责保证将消息传送至所有相应的接收者。
就象日常生活中的邮局一样，尽管一封邮件上标注的是其最终收件人的地址，实际上却要通过邮局进行路由，并经由多个中转站后，才会到达收件人的邮箱。
实际场景
●客户可以呼叫您，并立即得到各种类型的信息。
不需要将他们从这个部门指派到那个部门，也不需要回电话，不会浪费时间也不会丢失生意。
●在Internet上做交易。
ApusicMQ将把您现有的应用和系统与已知的最富变化的市场结合在一起。
●供应商和商业合作伙伴可以与您进行电子方式交流，减少了纸面工作，消除了错误的可能，节省了时间和经费。
ApusicMQ能够保证将您的应用无缝地集成到您的供应链中。
●无论您的工作人员走到哪里，都能保持与他们的联系。
ApusicMQ将信息带入到您的企业系统中，并以第一时间随时提供给工作人员。
●您的信息系统技术人员的工作效率将会更高，因为ApusicMQ将处理这些专家应该关心的在集成所有的计算机系统时要处理的艰难问题。
所以，他们可以将把精力放在提供满足业务需要的应用和系统。
●将您可信的在线系统与一些新的发展如电子商务和Web服务器集成在一起。
●以更快和更有效的方式开发和推出新的企业应用，不用编写复杂的通信代码。
●释放应用开发资源－使您最有价值的职员可以集中精力解决商业问题，而不需要耗费在底层通讯等方面。
●构建安全、高性能的移动信息网络以支持不断变化的全球商业活动。
●使用重要的新技术如消息代理（MessageBroker）和发布/预订（Publish-and-Subscribe）引擎来建立信息提供系统。
ApusicMQ功能
基础功能
支持的规范
ApusicMQ支持的规范包括：
◆JavaMessageService1.1
◆JavaManagementExtentions1.2
◆JavaTransactionAPI1.0
◆JavaTransactionService
◆ObjectTransactionService1.1（分布式事务管理规范）
支持的消息模型
ApusicMQ支持两种消息模型PTP和Pub/Sub。
PTP：
PTP（Point-to-Point）模型是基于队列的，发送方发消息到队列，接收方从队列接收消息，发送方和接收方是一对一。
和邮件系统中的邮箱一样，队列可以包含各种消息，ApusicMQ提供工具管理队列的创建、删除。
ApusicMQPTP模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。
Pub/Sub：
Pub/Sub（Publish/Subscribe）模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题（topic），发送方和接收方通常是一对多。
主题可以被认为是消息的传输中介，发布者（publisher）发布消息到主题，订阅者（subscribe）从主题订阅消息。
主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。
消息构成
消息由消息头和消息体构成。
消息头（Header）-消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：
消息目的地、消息ID、消息类型等。
除了消息头中定义好的标准属性外，ApusicMQ提供一种机制增加新属性到消息头中，这种新属性包含以下几种：
▪应用需要用到的属性;
▪消息头中原有的一些可选属性;
▪JMSProvider需要用到的属性。
消息体（Body）
ApusicMQ支持JMS规范中定义的五种消息体格式：
消息类型
消息体
TextMessage
java.lang.String对象，如xml文件内容
MapMessage
名/值对的集合，名是String对象，值类型可以是Java任何基本类型
BytesMessage
字节流
StreamMessage
Java中的输入输出流
ObjectMessage
Java中的可序列化对象
Message
没有消息体，只有消息头和属性
消息传递模式
ApusicMQ支持两种消息传递模式：
PERSISTENT和NON_PERSISTENT，PERSISTENT表示该消息一定要被送到目的地，否则会导致应用错误。
在选择PERSISTENT模式情况下，消息会被存放到硬盘上，以确保当宕机发生时，消息可被恢复。
NON_PERSISTENT表示偶然丢失该消息是被允许的，在NON_PERSISTENT下消息的传输性能要超过PERSISTENT模式。
用户在选择哪种传递模式时，通常需要在可靠性和吞吐量之间作出选择，当可靠性比较重要时，选择PERSISTENT，当吞吐量更重要时，选择NON-PERSISTENT。
消息签收
消息签收指接收方接收到消息后，系统会自动发送回执给发送方，通知发送方消息已收到。
用户在发送消息时可指定该消息需要签收。
另外，当消息接收方包含在事务中时，消息签收会有commit和rollback两种结果对事务进行提交和回滚。
消息优先级
ApusicMQ支持用户设置消息优先级。
消息优先级包括0-9十个级别，0-4是普通消息，5-9是加急消息。
ApusicMQ会根据消息优先级的高低安排消息的发送次序，同时保证加急消息先于普通消息送达。
消息的同步和异步接收
ApusicMQ支持消息的同步接收和异步接收。
消息的同步接收
同步接收是指客户端主动去接收消息，ApusicMQ客户端可以采用MessageConsumer的receive方法去接收下一个消息。
消息的异步接收
异步接收是指当消息到达时，主动通知客户端。
ApusicMQ客户端可以通过注册一个实现MessageListener接口的对象到MessageConsumer，这样，每当消息到达时，ApusicMQ会调用MessageListener中的onMessage方法。
消息选择
在消息应用中，经常需要对消息进行选择，只接收自己感兴趣的消息。
ApusicMQ提供消息过滤功能，用户可自己定义消息过滤规则。
比如，当一个消息被广播给许多接收者时，用户可以在消息头加入消息识别信息，ApusicMQ会根据消息识别信息将消息发送到对这类消息感兴趣的接收者。
对事务的支持
ApusicMQ支持本地事务和分布式事务。
ApusicMQ提供分布式事务管理器管理事务，同时，ApusicMQ分布式事务管理器能够和其他分布式事务管理器协作共同完成一个分布式事务。
ApusicMQ对事务的支持包括：
多个消息发送和接收可包含在一个事务里，ApusicMQ保证一个事务中的所有消息发送和消息接收的单元操作要么全部成功，要么全部失败。
数据库操作可以和消息发送接收放到同一个事务里。
支持多种语言调用
ApusicMQ采用纯Java语言实现，提供JavaAPI调用接口，可以运行在各种平台上。
另外，ApusicMQ还提供了C、C++、.Net等其它多种语言的调用接口，从而能够支持多种语言编写的应用之间的通讯。
ApusicMQ具备有完善的异常处理机制。
由于支持多种语言调用并支持多种平台，ApusicMQ可以作为各种异构应用集成的底层支撑平台。
日志
ApusicMQ提供完备的日志功能，根据重要程度对日志进行分级，用户可根据需要灵活选择需要输出的日志级别，也可以选择日志输出的目标。
日志级别：
ApusicMQ日志分以下几个级别：
◆DEBUG调试级别日志信息
◆INFO报告类信息
◆NOTICE常规但重要的信息
◆WARNING警告类信息
◆ERROR错误类信息
◆FATAL重大情况信息（最高级别）
以上日志级别从低到高，DEBUG级别最低，FATAL级别最高。
当用户选择输出某个级别的日志时，比这个级别高的日志信息也会自动输出。
比如：
当用户选择输出NOTICE级别时，则比NOTICE高的WARNING,ERROR和FATAL级别的日志也会被自动输出，而INFO和DEBUG级别的请求将被忽略。
另外，可以将日志级别设置为OFF以关闭对日志输出，也可将日志级别设置为ALL输出所有的日志信息。
日志输出目标：
用户还可以选择日志输出的目标，ApusicMQ日志可输出到以下目标：
◆控制台日志输出，日志输出到系统控制台。
◆日志文件输出，日志输出到指定的文件或者一个循环的文件集合。
对于循环的文件集合，当对某个文件的输出达到了指定限制，此文件将被关闭，新的接收日志输入的文件将被打开，旧的日志文件将会在基本日志文件名后被连续地加上如：
1,2,3等数字标识。
◆端口日志输出，日志记录被输出到指定的网络端口的输出流。
和J2EE应用服务器集成
ApusicMQ可以很好地和J2EE应用服务器集成，集成方式包括：
◆从Servlet、JSP中调用ApusicMQ发送或接收消息。
◆从EJB中调用ApusicMQ发送或接收消息，当EJB方法处在事务中时，对ApusicMQ的调用也会自动加入到当前事务中。
◆通过ApusicMQ发送消息到Message-DrivenBean。
◆J2EE应用服务器可通过配置消息适配器连接到ApusicMQ。
◆分布式事务支持，队列操作可以同其它资源（如数据库）一起参加分布式事务。
增强功能
智能路由
在一个拓扑网络中，消息传输的路径直接影响到消息的传输效率。
ApusicMQ提供智能路由功能，在选择路径时可根据路径的长度及负载情况进行综合考虑，以保障消息以最快速度传送到目的地。
如在一个由A、B、C、D、E、F、G七个路由节点的网络中，如下图：
C
B
A
G
F
E
D
有消息需要从A发送到G，在这个网络中，A到B有5条传输路径，分别是：
1.A->B->C->G
2.A->C->G
3.A->F->G
4.A->E->G
5.A->D->E->G
ApusicMQ智能路由会首先选择最短的传输路径2、3、4，然后在这最短的三条传输路径中选择负载最轻的传输路径4，也就是A->E->G路径传输消息。
集群
消息队列集群
ApusicMQ支持消息队列集群（MessageQueueClustering）。
所谓消息队列集群是指将多个消息路由器之间建立路由连接，从而组成一个消息路由网络。
在网络中任何一个节点上定义的消息队列都将被其他一个或全部节点所共享，通过任何一个节点向一个集群队列发送消息都是等效的，对客户来说无法察觉是否正在使用集群，集群中网络拓扑结构发生变化对客户也没有任何影响。
当路由节点与其他节点建立连接时通过发布自身定义的消息队列从而使消息队列获得共享，无须系统管理员干预，大大减少了路由网络的维护量。
使用集群还可以提高系统的可用性，路由网络中单个节点发生故障停机或部分网络无法连通时并不影响集群队列的使用，同时在发送消息时根据各节点的负荷情况对负载进行分配，从而使节点处理能力和网络带宽被充分利用。
获取远程队列消息
ApusicMQ支持在本地直接获取远程队列上的消息。
当本地需要消息时，向集群中的所有成员发出一个请求，表示本地需要消息，远程节点在收到请求后对其本地队列进行侦听，当消息出现时将消息通过路由算法发送到发出请求的节点的本地队列，本地节点再从本地队列中获取消息。
集群队列简易管理
ApusicMQ对集群队列实现简易管理，只需要将一个本地队列发布出去就可以被集群中的任何节点使用。
消息切分
ApusicMQ支持将一个大的消息切分成多个小块发送，在目的节点重新组合成完整的消息。
同样，被切分的消息将获得集群及智能路由带来的好处，将沿着多条路径同时向目的结点发送，充分利用网络带宽。
断线续传
断线续传指在消息传输过程中，由于网络原因导致消息传输中断，当网络恢复时，不需要重新传输整个消息，而只是从中断的位置传送即可。
ApusicMQ因为实现了消息切分，所以能够支持断点续传。
即消息被传送中途出现网络故障时，仍可在故障恢复重新连线后将后续的消息片段重新发送，而不必将整个消息重新发送。
由于消息可被切分，因此可以支持大消息传送，理论上消息最大可达到2G。
消息压缩
ApusicMQ提供数据压缩API，方便用户在收发消息时对消息进行压缩和解压缩，以提高消息传输效率，这对于传送大文件是非常重要的。
消息加密
ApusicMQ支持在消息传输过程中对消息进行加密，保证消息传输的安全性。
加密的密码由用户进行设置。
消息存储方式
ApusicMQ支持三种消息存贮方式，文件、BerkelyDB和通过JDBC接口存放到关系数据库。
文件方式
以文件方式保存消息，但配置非常简单并具有较高的性能。
在可靠性要求不高但对性能要求很高的环境下可以使用这种消息存储方式。
BerkelyDB
使用BerkelyDB保存消息。
BerkelyDB的伸缩性和可靠性都较高，可以满足大多数应用的需要。
BerkelyDB同样具有配置简单的特点。
由于BerkelyDB的License限制商业使用，因此Apusic发行包中并不包含BerkelyDB运行库，需要单独从下载。
JDBC
使用关系数据库保存消息。
对可靠性要求很高的应用环境下建议使用这种消息存储方式。
jdbc消息存储方式的缺点是配置较复杂。
大文件传输
ApusicMQ提供了使用MQ进行大文件传输的功能。
它具有不限制传输文件大小、断点续传、多线程传输、高可靠性、简单易用等特点。
如下图所示，发送端可以登录MQ服务器，利用现有的网络将文件发送到目的服务器，然后接收端再登录到目的服务器，将文件接收下来，MQ服务器保证了文件传输过程的可靠性和安全性。
使得整个过程就像发送或者接收一个消息一样，简单、方便、可靠、安全、高效。
ApusicMQ还提供了一套进行文件传输的客户端API，使用该套API可以方便地在不同的MQ节点间传输文件，而且在API级别提供了传输文件时的断点续传、多线程传输、删除传输文件等功能，从而让开发人员可以通过这套API在应用程序中方便地使用ApusicMQ进行文件传输。
支持多种平台
ApusicMQ完全采用Java语言开发，支持多种硬件平台和操作系统，如HP-UX、IBMAIX、SUNSOLARIS、Windows98/NT/2000/2003/XP、各种Linux等，使用户可以灵活选择硬件平台。
ApusicMQ支持的操作系统如下：
●HP-UNix11.0,11i（PA-RISC）
●HPNonStopserver（MIPS）
●HP-UNIX11iV2（Itanium）
●HPOpenVMS7.3-1（Alpha）
●HPTru64UNIX5.1（Alpha）
●RedHatEnterpriseLinux2.1AS,ES,WS（Pentium）
●RedHatEnterpriseLinux2.1AS,ES（Itanium）
●RedHatEnterpriseLinux3.0-1AS,ES,WS（x86）
●RedHatLinuxAdvancedServer2.1（Pentium）
●RedFlagLinux4.0,4.1
●SuS
升级会员 