第一章

1.2.1小节  松耦合与ActiveMQ

ActiveMQ为应用程序架构提供送耦合实现组件。松耦合经常被引入到系统架构中，来减轻紧耦合的远程工程调用的使用。松耦合的设计是异步的，来自其他系统的调用与其他系统无关，并且没有相互依赖和时间的要求。系统能够通过ActiveMQ确保消息的传送。因此，发送消息的应用程序只要把消息发送给ActiveMQ，而不用关心消息是何时或者什么方式发送出去的。对于消息接收方，它没有必要考虑消息从哪里来或者消息什么时候到达的。在异构的系统架构中，ActiveMQ将体现出它的价值。它允许应用程序使用不同的编程语言和不同的传输协议。ActiveMQ作为中间件，允许异构的系统，以异步的方式交互数据。下面的章节，我们将讲解更多。

在设计分布式系统时，系统的耦合是非常重要的。耦合是指两个或者更多应用程序或系统之间的依赖关系。一个简单的方式理解耦合是考虑，当修改系统中的任何一个程序时，对其他程序的影响（导致多少程序修改）。当修改一个应用程序是不是必须强制修改其他的应用程序？如果答案是：是，那么系统是紧耦合的。换句话说，松耦合的架构，能够应变意料之外的修改或变化。

(COM, CORBA, DCE, and EJB)是紧耦合的系统调用，使用的是RPC。当一个应用程序调用另外一个应用程序的时候，调动者被阻塞，直到被调用者有信息返回时。

调用者被阻塞直到调用的对象有返回信息。许多系统的架构使用RPC，并且成功投产。但是这样的紧耦合设计有很多劣势：显著的问题是，即使很小的系统调整，也需要高额的修改费用。另外，系统的调用时间必须正确。两个应用程序必须在同一时间发送请求到系统B，并返回结果到系统C。在紧耦合的系统设计中，有一种设计两个应用系统是完全相互不知道的。如下图：

如上图，一个应用程序发送消息给消息中间件；或许一段时间后，另一个应用程序从消息中间件中获取消息。两个应用程序根本不知道对方系统的存在，并且发送消息没有时间限制。这样的设计，当一个系统需要修改时，对另一个系统的影响非常小，所以维护的费用就比较低。基于上述原因，当考虑分布式架构时，松耦合的系统比紧耦合的系统提供了更多的优势。这时，ActiveMQ就该上场了。

系统架构设计时，必须考虑系统的改变，改变包括添加新的硬件或者移动服务器。紧耦合的设计系统，在添加新硬件的时候，所有的应用程序可能要经历中断的过程。但松耦合的系统，不同的部分可以单独移动。考虑这样的场景：有多个实例A和多个实例B分别部署在不同的物理机上。ActiveMQ安装在另外一台单独机器上。这种情况下，移动实例A或者实例B，不会影响其他系统。事实上，可以实例化多个ActiveMQ，组成群集。这样允许ActiveMQ实例被移动而不影响整个系统的运行。在多实例（冗余）时，任何部分可以暂停下来进行升级维护，而不影响整个系统。

ActiveMQ提供了极大的灵活性，让松耦合的系统架构成为现实。如果完全一部分方式不能满足系统的需要，ActiveMQ支持消息请求/应答模式。

1.2.1小节  何时使用ActiveMQ

在系统架构中，ActiveMQ和异步消息有很多使用场合。例子如下：

l   ActiveMQ是java语言开发的，客户端当然支持java。但ActiveMQ也支持C、Perl、PHP、Ruby等语言。若你的系统架构中使用不同的语言开发，使用ActiveMQ作为消息中间件，是最好的选择。

l   ActiveMQ将广泛替换RPC风格的同步调用RPC应用。考虑到大部分客户端-服务器应用程序都在使用RPC，包括ATM、web应用程序、信用卡系统、销售点系统等等。尽管这些系统非常成功，更换为使用异步消息会带来好处，但放弃了快速的反应。同步调用的扩展能力是有限的，当请求量比较大时，请求信息将会会缓存或者堵塞，从而影响整个系统的响应速度。

l   作为事件驱动的体系结构，异步的架构允许任意扩容，来处理更多的业务。扩容不仅仅包括增加内存和硬盘（垂直伸缩），也包括随机增加物理处理机（横向扩展）。举例：当我们在亚马孙上购物时，必须经过，下订单、发票创建、付款处理、订单履行、航运等。但是，当用户下单后，立即跳转到“感谢那您的订单” 页面。不仅如此，若果没有延迟，用户还会受到一封电子邮件。在这个过程中，使用了异步调用。当用户下单后，有一个同步调用，以提交订单，而整个订单流程不会同步调用。订单的流程就是依靠异步系统完成的，若流程不能完成将通过邮件通知。这种异步流程满足系统的可扩展性和高可用性。

l   为提高应用程序的可扩展性，许多应用程序使用事件驱动的架构，以提供大规模的可扩展性。这时面向服务的（SOA）的架构，服务和服务之间的通信实现使用异步消息传递，最终达到一致性。