ActiveMQ In Action 第一章 消息传递和ActiveMQ简介 1.2 何时何地使用ActiveMQ

1.2 何时何地使用ActiveMQ

回到2003年,一群开源软件开发者共同组建了Apache Geronimo(Apache软件基金会的开放源码J2EE服务器)。在做这些事的时候,他们发现手头没有使用BSD-style许可证的优秀消息代理。Geronimo基于JavaEE兼容性原因而需要一个JMS实现,随后一些开发人员开始讨论实现的可行性。这些拥有丰富商业MOM经验，甚至之前就自己构建过几个MOM的开发人员,着手创建下一个伟大的开放源码消息代理。成立ActiveMQ的灵感来自于这样一个事实:大多数的MOM在市场是商业,闭源以及需要高昂的购买费用和技术支持费用。商业MOM虽然深受企业欢迎,但一些企业负担不起高昂的成本。这为构建一个开源的替代方案增添了动力。显然提供一个使用Apache许可的开源的MOM是有市场的。这就是Apache ActiveMQ的由来。

1.2.1 ActiveMQ和松耦合

ActiveMQ能实现应用程序体系结构的松耦合。体系结构引入松耦合，通常是为了减轻远程过程调用(RPC)的耦合度。松耦合被设计成异步的,从而使应用程序间的请求呼叫不会互相影响;他们没有依赖和时序的要求。应用程序可以依赖ActiveMQ的能力保证消息传递。正因为如此,人们常说这类应用程序发送消息只是即发即弃(fire-and-forget)——它们将消息发送给ActiveMQ后,就不再关心消息是何时以及何种方式传递的。同样的,订阅应用程序也不会关注消息源自哪里或他们如何被发送到ActiveMQ。异构环境的一个极大的好处就是,允许使用不同语言甚至是不同连接协议编写的客户端。ActiveMQ充当中间人,使异构集成以及使用异步方式交互。更多的相关内容将在下一节中介绍。

在考虑分布式应用设计时,耦合是非常重要的。耦合是指两个或两个以上的应用程序或系统的相互依存。耦合可以更简单的想成是系统中的任何应用程序被改变时产生的影响:当体系结构中的其他应用程序添加新特性时产生的影响。当一个应用程序改变时会迫使其他应用程序也需要相应调整吗?如果答案是肯定的,那么这些应用程序是紧耦合的。但如果一个应用程序的更改,不影响其他应用程序,我们就说这些应用程序耦合更松。总的来说就是是紧耦合应用程序比起松耦合的应用程序更难于维护。另一种方式说,松耦合应用程序可以很容易地处理意料之外的变化

如在第二章讨论的使用RPC的技术(DCE,COM,CORBA和EJB)，被认为是紧耦合。使用RPC的工程中,当一个应用程序调用另一个应用程序时,调用者将被阻塞,直到被调用者将控制权返回给调用者。图1.1描述了这个概念。

调用者(应用程序1)在图1.1中被阻塞,直到被调用者(应用程序2)返回控制权。许多系统架构成功地使用了RPC，但这种紧耦合设计依然有许多缺点:最显著的是高昂的维护成本,因为即使是很小的变更也会波及整个系统架构。两个应用程序不得不在时序上达到统一。当请求从应用程序1到应用程序2的时候两个应用程序必须同时可用①，响应从应用程序2返回应用程序1时也有这个要求②。这种时序依赖可以变得十分繁琐,导致应用程序的健壮性不高。比较一下这种紧耦合设计与图1.2所示的两个应用程序间互不关联的设计。

在图1.2中应用程序1以单向模式发送一条消息到MOM。一段时间后,应用程序2以单向模式从MOM接收一条消息。两个应用程序甚至不知道对方的存在,在两个应用程序之间也没有时序的关系。因为改变一个应用程序对其他应用程序毫无影响，这种单向风格的交互可以极大的降低维护成本。由于这些原因,在分布式应用程序设计中松耦合应用程序比起紧耦合体系结构有很大的优势。这就是ActiveMQ的价值所在。

我们有时候会碰到移动应用程序到一个新的地点。这可能发生在更换新硬件或应用程序需要搬家的时候。紧耦合系统设计中,这种工程十分棘手,因为所有的应用程序必须经历一个中断。在松耦合的设计中,系统的不同部分可以相互独立地移动。想象这样一种场景,有多个实例的应用程序A和多个实例的应用程序B,各自安装在不同的机器上。而ActiveMQ安装在其他的机器上。在这种情况下,任何一个应用程序A或应用程序B的实例可以随意移动而不影响其他实例。事实上,ActiveMQ的多个实例添加到所谓的代理网络配置中。这能使ActiveMQ实例随意移动时不影响应用程序A和应用程序B。这意味着系统架构任何部分可以单独维护，而不需要关闭整个系统。关于这点的更多细节在第10章中会有记述。
ActiveMQ为应用程序体系结构中带来了难以置信的灵活性,使系统环境松耦合成为现实。如果给定一个用例无法使用完全异步的消息传递方式，ActiveMQ还支持消息传递的请求/应答模式。但什么情况下，我们该使用ActiveMQ来获得这些好处呢？
1.2.2 何时使用ActiveMQ

■异构应用程序集成——ActiveMQ代理是用Java语言编写的,所以自然提供了一个Java客户端API。ActiveMQ还提供了对于C/C++、.NET、Perl、PHP、Python、Ruby和一些其他语言编写的客户端的支持。这提供了巨大的便利，当你想在不同的平台上集成不同语言编写的应用程序时。在这种情况下,无论使用什么语言编写的客户端API都可以通过ActiveMQ发送和接收消息。除了ActiveMQ提供的跨语言能力,无需使用RPC就集成这些应用程序无疑是一个巨大的优点（因为消息机制有助于分离应用程序）。

■作为RPC的替代方案——使用RPC模式同步调用的应用程序普遍存在。绝大多数的C/S应用程序使用RPC，比如自动取款机,大多数web应用程序,信用卡系统,销售系统等等。虽然许多这些系统是成功的,然而使用异步消息传递机制在保证响应质量的同时还可以带来许多好处。依靠同步请求的系统通常扩展能力有限,因为最终请求将开始积压,从而降低系统的响应速度。而使用异步消息传递机制,可以轻松地添加额外的消息接收器,并发处理消息,因此处理速度更快，所以不会有这个问题。当然,假设您的应用程序是可解耦的。

■为应用程序解耦——我们已经讨论过,紧耦合体系结构会有许多问题,特别是如果他们是分布式的。另一方面，松耦合体系结构表现出更少的依赖,使它们更好地处理意料之外的变化。不仅表现在改变一个组件而不波及整个系统,而且组件间交互也大大简化。组件将利用异步通信(只简单发送消息而无需等待响应,也称为“即发即弃（fire-and-forget）”)，而不是使用一个同步方案进行组件交互(一个方法调用另一个然后等待被调用者的响应)。当松耦合贯穿整个系统设计的时候就是所谓的事件驱动架构(EDA)。

■作为事件驱动体系结构的支柱——解耦,在前面的描述中，异步机制体系结构允许代理本身通过内存分配调优和增加内存等等方式进一步扩展功能和请求处理能力(即垂直伸缩性【 vertical scalability】) ，而不只依赖通过增加节点数量来增加请求处理能力(即水平可伸缩性【horizontal scalability】)。请想象一个拥有极大交互量的电子商务网站,如亚马逊。当用户在亚马逊上进行购物时,一份订单必须经过包括提交定单,开发票,付款,订单执行,发货等等的不同阶段。但实际上当用户下完订单后,将立即前往“谢谢惠顾。”的页面。不仅如此,稍后,用户也将收到一封电子邮件,声明该订单已收到。然而提交定单只是一大堆异步处理过程的第一步。订单的每个阶段由一个单独的服务离散地处理。当用户提交订单时,有一个同步调用来提交订单,但整个订单处理流程并不通过web浏览器同步调用。相反,订单马上被接受和确认。剩余的步骤将被异步处理。如果处理过程出现问题而被终止,用户将得到邮件通知。这种异步流程提供极强的可伸缩性和可用性。

■提高应用程序的可伸缩性——许多领域的应用程序使用事件驱动的体系结构,以提供强大的可伸缩性。包括电子商务、政府软件、制造业、和网络游戏等等。随着在业务领域中使用异步消息传递机制达到应用程序分离的方式开始普及,出现了许多其他的可能性。为一个特定的任务设计一个应用程序服务，这是面向服务的体系结构(SOA)的要点。然后通过组合这些服务构建应用程序,而服务间的通信采用异步消息传递机制和最终一致性达成。这种风格的应用程序设计可以引入复杂事件处理(CEP)的概念。使用CEP，可以跟踪系统中组件间的交互从而为深入分析提供条件。由于异步消息传递机制只是在一个系统组件间添加一个中间层，因此这种可能性是无止境的。

现在您已经得到了一些使用ActiveMQ的例子,是时候安装并开始使用它了。