ActiveMQ in Action-1.2 Using ActiveMQ: why and when?- 高飞网

1.2 Using ActiveMQ: why and when?

2016-05-31 15:12:45.0

1.2 ActiveMQ的使用:为什么使用和何时使用

    回到2003年,一群开源开发者走到一起形成了Aapche Geronimo。在这过程中,他们发现当时并没有基于BSD许可的可靠消息服务。Geronimo需要一个JMS规范的实现,兼容JavaEE,所以几个开发者开始讨论这件事情的可行性。使用过高昂费用的商用消息中间件经历与他们之前写过的消息中间件结合,这些开发者开始创建下一个更伟大的开源消息服务。另一个创建ActiveMQ的动机事实上是,当时市场上的消息中间件大多是商用、闭源的,且必须花大价钱来获得技术支持。这些商用中间件在企业中很流行,但有些企业支付不起这个开销。从长远发展来看必须要有一个开源的替代品。使用Apache许可,并且开源的消息中间件,这是个清晰的市场需求。这便是后来的Apache ActiveMQ。

    ActiveMQ即实现了JMS规范和分布式应用的远程消息通讯。为更好理解其中的意思,最好的方式就是去看看几个分布式应用背后的设计思想,尤其是通讯这一方面。

1.2.1 松耦合

    ActiveMQ提供了颇具优势的应用架构间的松耦合方案。通常提到松耦合是为了减少经典的远程过程调用,即Remote Process Calls(RPC)的紧密耦合性。松耦合的设计是异步的,来自一个应用的调用不会影响另一个应用,没有依赖和时序要求。应用可以依靠ActiveMQ的功能保证消息的传递。因此,经常说应用发完消息就不再理会(fire-and-forget),他们发送消息到达ActiveMQ,然后就不关心它们何时去传递消息,怎么传递的。相似地,消费应用也无须关心消息从哪里产生,它们是怎样发到ActiveMQ的。这在多样化的环境中是个很特性强大的特性,允许客户端用不同的语言来写,甚至可以是不同的协议。ActiveMQ作为一个中间件,允许多种异步的集成与互动方式。下文中详细说明。

    当考虑分布式应用设计时,耦合性是重中之重。耦合是指依赖了2个或更多的应用或系统。理解耦合性最好的方式就是改变系统中的任意一个应用的场景:这些隐含依赖的特点,贯穿于架构的应用之间。当一个应用进行改造时,需要强制要求涉及的其他应用也跟着改造吗?如果是,这些应用就紧密地耦合在一起了。但是如果一个应用在不影响其他应用的情况下进行改造,就说这些应用是松耦合的。下面展示了强耦合应用相对于松耦合应用更难以维持。换句话说,松耦合应用更易于应对不可预知的变化。

    第2章中讨论的那些RPC技术(COM,CORBA,DCE和EJB)被认为是紧密耦合的设计。使用RPC,当一个应用调用另外的应用时,调用者将被阻断,直到被调用者把控制权返还给调用者。图1.1说明了这点。


    图1.1中的调用者(一个应用)被阻断直到被调用者(第2个应用)返还控制权。很多系统构架使用RPC并且是成功的。但是紧耦合设计有很多劣势:最值得注意的就是需要更多的维护成本,因为即使再小的改变,也会涉及系统架构。两个应用间保持正确的时序是很重要的。对同一次从第1个应用到第2个应用的请求,两个应用都必须同时可用才可以,因为响应将要从第2个应用回到第1个应用。这种时序要求是笨重的,导致系统变得更脆弱。对比一下这种紧耦合设计,和图1.2中描述的另外一种全然不知另外应用存在的设计。

    图1.2中。一个应用以单向方式向MOM发送一个消息,然后,可能要过一会儿,第2个应用亦会以单向方式从MOM收到一个消息。任何一个应用都不知道另一个应用的存在,两个应用之间也没有时序的要求。单向的互动方式维护成本更低,因为一个应用的改变几乎不影响另外的应用。因为这个原因,在分布式构架中,低耦合应用相对于紧耦合设计就有很大的优势。这就是图中ActiveMQ应用之处。


    有时一个应用必须要迁移到另外一个地方,考虑下这个变更需求是必要的。如当引入新的硬件时,或应用本身需要迁移。当使用紧耦合的系统设计时,由于所有的应用经历断点过程,这种迁移将是非常困难的。那如果是松耦合设计的话,不同的阶段的系统可以相对另外的独立迁移。考虑下,如果应用A的多个实例和应用B的多个实例,其中每个实例部署在不同的机器上。ActiveMQ部署在单独的机器上既不在A也不在B的机器上。使用这种方案的话,其中一个应用A或B的实例,可以直接去迁移而不会影响到另外的应用。实现上,可以使用诸如network of brokers配置,ActiveMQ就可以部署多个实例。这将允许ActiveMQ实例迁移时不会影响到其他应用如A或B。这意味着任何部分的系统架构,在任何时刻,都可以在不停止全部系统的情况下停机维护、更为详情介绍在第10章中。

    ActiveMQ为应用架构提供了足够的灵活性,使得松耦合的设计理念成为现实。如果给定的用例不能完全使用异步消息,ActiveMQ也支持请求/响应(request/reply)式的消息模式。那么何时ActiveMQ会用于引入这些特性呢?

1.2.2 何时使用ActiveMQ

    在系统架构的很多场合,ActiveMQ和异步消息都有深远的影响。这里列出以下几个场景:

    · 多样的应用集成:ActiveMQ服务端使用Java语言编写,因此提供了原生的Java客户端。但ActiveMQ也提供了C/C++、.NET、Perl、PHP、Python等其他语言的客户端。当你可能集成不同语言不同平台的应用的时候,这是一个非常大的优势。在这种情况时,多样的APIs使不管使用何种语言,通过ActiveMQ发送和接收消息成为可能。ActiveMQ除了跨语言的能力之外,以非RPC方式集成这些应用的能力也是个很大的优势,因为消息传递真正将应用解耦了。

    ·  作为RPC框架的替换器:使用RPC模式的应用异步调用是很普遍的。想一下使用客户端-服务器的应用,包括ATM机,多数的web应用,信用卡系统,销售系统等。即使这些系统多数是成功的,然而在不放弃响应保证情况下,通过使用异步消息也能带来好处。

    · 应用之间解耦:正如前面讨论过的,紧耦合的架构可能由于多方面的原因导致问题,尤其是在他们分散后。另一方面,松耦合的构架,表现为更少的依赖性,使之可以更好的处理不可预知的变更。不仅仅是对系统中一个组件的修改不会影响到整个系统,而且组件之间的影响也明显变弱了。组件交互时不再使用同步的策略(一个调用者调用另一个调用者并等待后者的响应),取而代之的是异步交互(只是简单的发送一个消息,不必等待消息响应————也被称为fire-and-forget)。贯穿系统的这种松耦合导致一种被称为事件驱动的构架(event-driven architecture)。

    · 作为事件驱动型构架的主干:前面描述的这种解耦的,异步风格的架构允许broker自身通过配置,规模更大并处理更多的客户端。额外的内存分配,等等(称为垂直扩展)而不是仅仅依赖增加服务端节点的能力去增加处理更多的客户端(称为横向扩展)。想像下增长飞快的电商网站,如亚马逊。当用户在亚马逊上购物时,有好几步操作是必须做的,包括下单,创建发票,支付,订单完成,发货等等。但当用户真实去下订单时,用户会在页面上立即看到“感谢您的惠顾”。不仅如此,亚马逊的下单处理是在如此庞大的一套处理流程中的一个好示例。订单流程中的每一步都会有一个独立的服务来处理。当用户下单时,一个同步的调用提交到订单,但是完整的订单流程在web浏览中没有使用同步调用。而是立即给出订单接收和响应。剩余流程的由异步来处理。如果发生问题阻塞了流程进行,用户将收到一个email通知。这样的异步处理提供了很大的扩展性和高可用性。

    · 提供应用的可扩展性:前面描述的这种解耦的,异步风格的架构允许broker自身通过配置,规模更大并处理更多的客户端。额外的内存分配,等等(称为垂直扩展)而不是仅仅依赖增加服务端节点的能力去增加处理更多的客户端(称为横向扩展)。想像下增长飞快的电商网站,如亚马逊。当用户在亚马逊上购物时,有好几步操作是必须做的,包括下单,创建发票,支付,订单完成,发货等等。但当用户真实去下订单时,用户会在页面上立即看到“感谢您的惠顾”。不仅如此,亚马逊的下单处理是在如此庞大的一套处理流程中的一个好示例。订单流程中的每一步都会有一个独立的服务来处理。当用户下单时,一个同步的调用提交到订单,但是完整的订单流程在web浏览中没有使用同步调用。而是立即给出订单接收和响应。剩余流程的由异步来处理。如果发生问题阻塞了流程进行,用户将收到一个email通知。这样的异步处理提供了很大的扩展性和高可用性。