《分布式计算、云计算与大数据》第二章

第二章、分布式计算范型

1、消息传递范型
消息传递是进程间通信的基本途径。如图2-1所示，在消息传递范型中，表示消息的数据在两个进程（进程A和进程B）间交换：一个是发送者，另一个是接收者。

消息传递是分布式应用的最基本范型。一个进程发送代表请求的消息，该消息被传送到接收者；接收者处理该请求，并发送一条应答消息。随后，该应答消息可能触发下一个请求，并引起下一个应答消息。如此不断反复传递消息，实现两个进程间的数据交换。
消息传递范型所需的基本操作为send和receive。对于面向连接的通信来说，还需要connect操作和disconnect操作。利用该模型提供的抽象，互连进程在彼此之间执行输入操作和输出操作，操作方式类似于文件的输入操作和输出操作。和文件I/O相似，这些操作封装了操作系统层的网络通信细节，因此，程序员可以使用这些操作发送和接收消息，而不必关注操作系统底层的通信细节。
基于该范型的开发工具有Socket应用程序接口（Socket API）和信息传递接口（Message Passing Interface，MPI）等。
利用Socket API接口，可以使不同主机或者同一台计算机上的进程间相互通信，Socket API接口允许应用程序控制和使用网络里的套接字进行消息传递。一般的Socket API都是基于伯克利套接字（Berkeley Socket）标准的。在后面的内容中，我们将使用Java Socket API提供的方法或函数在进程间传递消息。
信息传递接口是一个并行计算的信息传递应用程序接口，包括协议和语义说明，它们指明其如何在各种实现中发挥其特性，常在超级计算机、计算机簇等非共享内存环境程序设计。MPI属于OSI参考模型的第五层或更高，但它的实现可能通过传输层Socket覆盖大部分层，因此，拥有良好的可移植性和速度。大部分的MPI实现由一些API组成，可由Java或C语言等直接调用。
消息传递模式是最基本的传递消息的范型，很多即时通信工具（如QQ等）都是基于该范型的具体应用。

2、客户/服务器范型
客户/服务器范型（简称C/S范型）是网络应用中使用最多的一种分布式计算范型，该模型将非对称角色分配给两个协作进程。其中，服务器进程（server process）扮演服务提供者角色，被动地等待请求的到达；客户进程（client process）向服务器发起请求，并等待服务器响应。
客户/服务器范型的概念，它有效地抽象了网络服务的请求，客户进程发起请求和接收响应。通过为双方分配非对称的角色，即服务器进程监听和接收请求，客户进程发送请求和接收响应。进程间的事件同步也被简化了：服务器进程等待来自客户的请求，客户进程则等待来自服务器的响应。
3、P2P范型
P2P（Peer-to-Peer）范型源于P2P网络（又称为对等计算网络）。P2P网络是无中心服务器，依赖用户群交换的互联网体系。与客户/服务器结构的系统不同，在P2P网络中，每个用户端既是一个结点，又有服务器的功能，任何一个结点无法直接找到其他结点，必须依靠其用户群进行信息交流。
在P2P范型中，各参与进程的地位是平等的，具有相同的性能和责任（因此，称它们为peer）。每个参与者（进程）都可以向另一个参与者发起请求和接收响应。在一个基于P2P范型的分布式应用中，每一个参与的进程往往既承担服务器进程的角色（资源提供者），又承担客户进程的角色（资源请求者）。

4、消息系统范型
消息系统范型或面向对象的中间件（Message-Oriented Middleware，MOM）是在基本的消息传递范型的基础上扩展而来的。在这种范型中，消息系统充当一些相当独立的进程之间的中介。不同的进程以非耦合的方式，通过消息系统异步地交换消息。消息发送者（进程）在发送消息时，将一条消息放入消息系统中，后者接着将该消息转发到与各个接收者（进程）相应的消息接收队列中，一旦消息发送出去，发送者即可执行其他任务了。
消息系统范型可以进一步划分为两种子类型：点对点消息范型（point-to-point message model）和发布/订阅消息范型（public/subscribe message model）。

1.点对点消息范型
在点对点消息范型中，消息系统将来自发送者的一条消息转发到接收者的消息队列中。与基本的消息传递模型不同的是，这种中间件模型提供了消息暂存的功能，从而可以将消息的发送和接收分离。通过中间件消息系统，发送者可将消息存入接收进程的消息队列中。接收进程则从自己的消息队列中提取消息，并加以处理。
如果要在基本的消息传递范型中达到同样的结果，必须借助于线程或者子进程技术。

2.发布/订阅消息范型
在发布/订阅消息范型中，每条消息都与某一主体或事件相关。对某个事件感兴趣的应用程序可以订阅与该事件相关的消息。当订阅者等待的事件发生时，触发该事件的进程将发布一条消息来宣布该事件或主题。中间件消息系统将这条消息分发给该消息的所有订阅者。
发布/订阅消息范型提供了一种用于组播或组通信的强大抽象机制。发布操作使一个进程可以向一组进程组播消息，订阅操作则使一个进程能够监听这样的组播消息。

5、过程调用范型
于基本的网络协议和基本的网络应用程序来说，消息传递范型是适用的。但是，随着应用程序变得越来越复杂，需要为网络编程提供进一步的抽象。最好有一种范型能使开发人员可以像编写在单处理器上运行的传统应用程序一样，编写分布式软件系统。远程过程调用（Remote Procedure Call，RPC）范型就提供了这种抽象。利用这一抽象，可以采用与本地过程调用类似的思想与概念，以进行进程间通信。
远程过程调用涉及两个独立的进程，它们可以分别位于两台独立的计算机上。例如，如果进程A希望向另一个进程B发出请求，就可以向进程B发出一个过程调用，同时传递的还有一组参数值。与本地过程调用的情况一样，该远程过程调用也会触发进程B所提供的某一过程中预定义的动作。过程执行完毕后，进程B将返回一个值给进程A。

6、分布式范型
分布式对象范型将面向对象应用到分布式系统中，是面向对象软件开发技术的自然扩展。该范型使应用程序可访问分布于网络上的各个对象。通过调用对象的方法，应用程序可获取对服务的访问。

1．远程方法调用
远程方法调用（Remote Method Invocation，RMI）是面向对象版本的RPC。如图2-9所示，在该范型中，进程可以调用对象方法，而该对象可驻留于某远程主机中。与RPC一样，参数可随方法调用传递，也可提供返回值。

2.对象请求代理
对象请求代理范型由对象请求者（object requestor）、对象提供者（object）和对象请求代理（Object Request Broker，ORB）组成。在对象请求代理范型中，进程向对象请求代理发出请求，对象请求代理将请求转发给能提供预期服务的适当对象。对象代理还可以作为异构对象之间的协调者，允许由不同API实现的对象及运行于不同平台上的对象进行交互。

7、网络服务范型
网络服务范型由服务请求者、服务提供者（对象）和目录服务三者组成。网络服务范型的工作原理为：服务提供者将自身注册到网络上的目录服务器上；当服务请求者（进程）需访问服务时，则在运行时与目录服务器联系；然后，如果请求的服务可用，则目录服务器将向目录服务进程提供一个有关该服务的引用；最后，进程利用该引用来与所需的服务进行交互。

8、移动代理范型
移动代理是一种可移动的程序或对象。如图2-13所示，在移动代理范型中，一个代理从源主机出发，然后根据其自身携带的执行路线，自动地在网上主机间移动。在每一主机上，代理访问所需的资源或服务，并执行必要的任务来完成其使命。
移动代理范型为可移动的程序或对象提供了抽象。这种范型不进行消息互换，而是当程序/对象在各个参与结点间移动时，携带并传递数据。支持移动代理范型的商业软件包有Concordia系统和IBM公司的Aglet系统。

9、云服务范型