[转] ActiveMq why and when

 以下内容是对 《ActiveMq In Action》的翻译 第二章的部份翻译，体现了ActiveMq的核心思想，

转自

1.2使用ActiveMQ：为什么，何时

 时间回到2003年，一群开源开发者集合在一起形成了Apache Geronimo。之后，他们发现当前没有好用的使用BSD-style许可协议的消息代理器。Geronimo是由于java EE兼容性需要一个JMS实现。所以一些开发者开始讨论其可能性。拥有丰富MOMs经验甚至自己创建过一些MOMs的这些开发者开始创建下一个伟大的开源消息代理。ActiveMQ这么快开始是因为当时市场上大多数的MOMs是商业，闭源而且购买和支持昂贵。市场上的MOMs已经广泛地被使用，但是一些商业行为是买不起如此昂贵的软件。这使得创建一个开源MOMs的需求更加大。很明显，有一个市场急需一个开源的使用Apache License的MOM。最终就导致了Apache ActiveMQ的诞生。

    ActiveMQ遵循JMS规范，是为分布式应用远程交流而创建的。为了理解这目的，最好就是去看一些分布式应用的设计和是交互。

 

1.2.1松耦合与ActiveMQ

    ActiveMQ提供松耦合的应用架构。松耦合一般是为了减轻经典RPC（Remote Procedure Calls）调用的紧耦合架构而被引入的。该松耦合以异步形式存在，任何一个应用对ActiveMQ的调用不依赖于任何其它应用，没有任何依赖或者时序要求。应用依赖于ActiveMQ的能力保证消息传递。因此，我们把应用发送消息的形式称之为触发和忘记（fire-and-forget）--应用发送消息到ActiveMQ之后并不关心消息如何或者什么时候被传递。同样的消息的接收者也不关心消息从哪里或者如何到来。在不同的环境中这样做的好处是允许客户端使用不同的语言编写甚至使用不同的线路协议。ActiveMQ作为中间人存在，允许不同环境的集成和异步交互。更多内容将在下一节论述。

    当我们考虑分布式应用设计时，耦合是很重要的。耦合是指两个或多个应用间的相互依赖。考虑耦合的一个简单办法是思考其中某个应用改变所产生的影响，即其它应用所需要作出的改变。是否一个应用的变化会强制其它应用跟着改变？如果答案是肯定的，则这些应用是紧耦合的。如果一个应用的变化无需强制其它应用跟着改变，则这些应用是松耦合的。这说明了紧耦合系统比松耦合系统更难维护。也就是说，松耦合系统更能适应未知的变化。

    在第二章我们将讨论COM,CORBA,DCE和EJB等使用RPC的技术，它们是紧耦合的。使用RPC，当一个应用调用

 另一个应用，调用者将被阻塞知道被调用者返回结果。图1.1描述了这个过程。 

 

调用方（Application one）将被阻塞直到被调用方（Application two）返回控制权。很多系统使用RPC并且成功了。但是对于这样一个紧耦合系统确实有很多缺点：最显著的缺点是，即使很小的一个改变都要较高的维护代价;正确的时机也很重要，当请求从应用1发到应用2时，两个系统都必须正常工作，同样的，响应从应用2发送到应用1时，两个系统也必须正常工作。这样的时序要求有点麻烦，使得系统稳定性降低。现在我们把这个紧耦合系统和图1.2的系统进行比较。

 

 在图1.2中，应用1发送消息到MOM只是一个单方行为。可能一段时间后，应用2从MOM接收消息，这也是一个单方行为。任何一方都不需要知道另一方的存在，它们之间也没有任何时序要求。所以在分布式系统设计时，松耦合系统比紧耦合系统有巨大的优势。如图所示，这就是ActiveMQ存在的地方。

    考虑现在其中的一个应用必须搬到一个新的地方。这可能在新硬件引入或应用需要移动时发生。如果是一个紧耦合系统，这样的迁移会很困难，因为系统的其它部分都必须停止工作等待迁移完成。如果是松耦合系统，系统的各个部分能够自由迁移而不影响其它部分。考虑这样一个场景，应用A和B各有很多个实例，其中各个实例分布在不同的机器上。ActiveMQ安装在另外的机器上。在这种情况下，任何一个应用实例都可以自由移动而不影响其它应用。事实上，多个ActiveMQ实例也可以通过network of brokers配置联合使用。这就允许ActiveMQ实例自由迁移而不影响应用A或应用B。采用这种价构，系统的任何一部分在任何时间都可以停机进行维护而不影响整个系统。更多的介绍将放在第10章。

   总之，ActiveMQ提供一个令人难以置信的灵活性允许松耦合思想变成现实。对于某些情况不能使用异步方式实现，ActiveMQ也提供消息的请求/回复模式支持。那么什么时候使用ActiveMQ可以获得如上所述的好处呢？

 

1.2.2何时使用ActiveMQ

    有很多情况ActiveMQ和异步消息能对一个系统的架构产生有意义的作用。下面列举一些场景。

·         不同语言应用集成----ActiveMQ使用java编写，并且提供一个java客户端API。但ActiveMQ也为C/C++，.NET,Perl,PHP,Python,Ruby等提供客户端。当你考虑在不同平台不同语言下的各个应用进行集成时，这将是一个巨大的优势。不同语言的客户端API使各种不同的语言能够通过ActiveMQ发送和接收消息。对于ActiveMQ提供的多语言兼容，还有一个好处是相对于RPC调用，它能帮助系统各应用间的解耦。

RPC的替代者----应用广泛的使用RPC模式的同步调用。想一下，现在大量使用RPC调用的客户端服务器模式的应用，它们包括ATMs，大多数web应用，信用卡系统，销售点（point-of-sale）系统等。尽管它们大多数是成功的，但是转换到异步消息模式能够在保证正确响应的情况下带来一些好处。使用同步请求的系统在规模上有较大的限制，因为请求会被阻塞，从而导致整个系统变慢。如果使用异步消息替代，可以很容易增加额外的消息接收者，使得消息能被并发消耗，从而加快请求处理。当然，必须你系统应用间是解耦的。

·         应用间解耦----就是上面讨论过的，紧耦合系统能带来很多问题，特别是在应用是分布式的情况下。松耦合系统，也就是依赖性小的系统，可以更好地适应未知变化。不只是系统某部分的改变不会影响整个系统，而且部件间的交互也更简单。相比使用同步的系统（调用者必须等待被调用者返回信息），异步系统（调用方发送消息后就不管，即fire-and-forget）能够给我们带来事件驱动架构（event-driven architecture EDA）.

·         作为事件驱动架构的骨架----解耦，异步架构的系统允许通过代理器自己配置更多的客户端，内存等（即vertical scalability）来扩大系统，而不是增加更多的代理器（即horizontal scalability）。考虑如亚马逊这样繁忙的电子商务系统。当用户购买物品，事实上系统需要很多步骤去处理，包括下单，创建发票，付款，执行订单，运输等。但是用户下单后，会立即返回“谢谢你下单”的界面。不只是没有延迟，而且用户还会受到一封邮件表明订单已经收到。在亚马逊下单的例子就是一个多步处理的例子。每一步都由单独的服务去处理。当用户下单是，有一个同步的体积表单动作，但整个处理流程并不通过浏览器同步处理。相反地，订单马上被接受和反馈。而剩下的步骤就通过异步处理。如果在处理过程中出错，用户会通过邮件收到通知。这样的异步处理能提供高负载和高可用性。

·         提高系统扩展性。很多使用事件驱动设计的系统是为了获得高可扩展性，例如电子商务，政府，制造业，线上游戏等。通过异步消息分开商业处理步骤给各个应用，能够带来很多可能性。考虑设计一个应用来完成一项特殊的任务。这就是面向服务的架构（service-oriented architecture SOA）。每一个服务完成一个功能并且只有一个功能。应用就通过服务组合起来，服务间使用异步消息和最终一致性。这样的设计便可以引入一个复杂事件处理概念（complex event processing CEP）。使用CEP，部件间的交互可以被记录追踪。在异步消息系统中，可以很容易在部件间增加一层处理。