RPC和异步消息传送

为什么80%的码农都做不了架构师？>>>   

RPC（Remote Procedure Call，远程过程调用）是通常用于描述分布式计算模型的术语，现在 Java 和 .NET这两种平台都在使用这个术语。对于许多应用程序来说，基于RPC的技术已经是，并且将来继续是切实可行的解决办法。不过，企业消息传送模型在特定类型的分布式应用程序中表现更为出色。下面我们将讨论每种模型的优缺点。

紧密耦合的RPC

在调用一个远程过程时，调用者将被阻塞，直到该过程完成并将控制权返回给调用者。从开发者的角度看，这种同步模型使得该系统就好像运行在一个进程当中。这些工作会依次完成，同时确保以预定顺序完成。RPC同步的本质特性，将客户端和服务端二者紧密耦合在一起。因为客户端已被阻塞，所以它无法继续进行工作，直到服务器做出响应为止。RPC紧密耦合的本质特性导致出现了相互高度依赖的系统，其中一个系统的失效会对其它系统产生立竿见影的弱化影响。虽然RPC在许多场景中表现优秀，但是在系统对系统（system-to-system）的处理过程当中，它的同步、紧耦合等本质特性却是一个严重的缺陷，因为“系统对系统”有很多垂直的应用程序集成在一起。在系统对系统场景中，垂直系统之间的通信线路不仅数量众多，而且方向也是错综复杂的。如图：

让我们设想一下使用紧密耦合的RPC机制实现这种基础设施所面临的挑战。这些系统之间的连接管理是多对多的问题。当你向混合系统中加入另一个应用程序时，你不得不回过头来让其余所有的系统都知道它，而且，这些系统也会崩溃。正是RPC系统的同步、紧密耦合、相互依赖等本质特性，使得子系统中出现的故障最终会导致整个系统的失效。就像在“系统对系统”场景中那样，当RPC紧密耦合的本质特性不再适用时，消息传送机制为此提供了另一种选择方案。

企业消息传送

消息传送机制的一个基本思想就是：规定应用程序之间的通信应该采用异步方式。将各部分连接在一起的代码会假定这是一条单向消息，它不需要立即从另一个应用程序那里得到响应。换句话说，也就是没有出现阻塞现象。一旦一条消息被发出，消息传送客户端就能够转向其它任务，它不必等待对这条消息的响应。这是RPC和异步消息传送之间的主要区别，而且，它对于理解消息传送系统的优点来说至关重要。

在一个异步消息传送系统当中，每个子系统都不存在和其他系统的耦合。如下图，它们通过消息传送服务器进行通信，因此，某个子系统出现故障，并不会妨碍其它子系统的运行。

在网络化系统中会出现局部故障，这是一个不可避免的事实。其中的一个系统可能会在其连续运行期间的某个时刻发生不可预测的故障，或者需要停机。这种现象可能会由于内部系统和合作系统地理上的分散而被进一步放大。考虑到这个因素，JMS提供了保证传送（guaranteed delivery）方式，它可以确保即便发生了局部故障，预定消费者最终也会接收到这条消息。保证传送使用的是一种“保存并转发（store-and-forward）”的机制，这就意味着，如果预定消费者当前并不可用，底层消息服务器会将输入的消息写到一个持久存储器之中。随后，当该接收应用程序变为可用时，“保存并转发”机制会把预定消费者在不可用时错过的所有消息传送给它们。

转载于:https://my.oschina.net/fhd/blog/214735