第二章·分布式计算范型

2.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.2 客户/服务器范型
客户/服务器范型(简称C/S范型)是网络应用中使用最多的一种分布式计算范型，该模型将非对称角色分配给两个协作进程。其中,服务器进程(server process)扮演服务提供者角色，被动地等待请求的到达;客户进程(client process)向服务器发起请求，并等待服务器响应。
如图2-2所示，客户/服务器范型的概念很简单，它有效地抽象了网络服务的请求，客户进程发起请求和接收响应。通过为双方分配非对称的角色，即服务器进程监听和接收请求，客户进程发送请求和接收响应。进程间的事件同步也被简化了:服务器进程等待来自客户的请求，客户进程则等待来自服务器的响应。

有许多Internet服务都是基于客户/服务器范型的应用，我们称它们为客户/服务器应用。这些服务通常根据它们所实现的协议来命名。比较著名的Internet服务包括HTTP、FTP、 DNS、finger和gopher等。当前最流行的互联网应用WWW (或称为Web)是基于客户/服务器范型的一个典型分布式应用。它由Web服务器进程和浏览器客户进程构成。Web服务器进程不断侦听从Web浏览器进程发出的请求，服务器处请求并发送响应。- -旦收到应答后，浏览器进程解释收到的响应,并将文档显示出来。浏览器客户进程负责发送请求和接收响应。Web应用的原理是基于HTTP协议的客户/服务器应用，在后面的内容将更具体地介绍HTTP协议。
2.3 P2P范型
P2P (Peer-to-Peer) 范型源于P2P网络(又称为对等计算网络)。P2P网络是无中心服务器，依赖用户群交换的互联网体系。与客户/服务器结构的系统不同，在P2P网络中，每个用户端既是一个结点，又有服务器的功能，任何一个结点无法直接找到其他结点，必须依靠其用户群进行信息交流。

如图2-3所示，在P2P范型中，各参与进程的地位是平等的，具有相同的性能和责任(因此，称它们为peer)。每个参与者(进程) 都可以向另-一个参 与者发起请求和接收响应。在-一个基于P2P范型的分布式应用中，每-一个参与的进程往往既承担服务器进程的角色(资源提供者)，又承担客户进程的角色(资源请求者)。客户/服务器范型是集中式网络服务的理想模型(其中服务器进程提供服务，而客户进程通过服务器访问服务)。而P2P范型更适合于诸如即时消息传送、P2P文件传输、视频会议、协同工作等应用。当然，基于P2P范型的应用也可以同时使用C/S结构来辅助处理一些任务。P2P范型可以采用任何提供消息传递的工具来实现。JXTA是Sun Microsystem于2001年定义的一个开源的P2P协议, JXTA协议被定义为XML消息的集合,允许任何设备独立于底层网络拓扑结构连接网络交换消息或相互协作。我们可以基于Java
使用JXTA技术创建P2P应用程序。如图2-4所示为P2P的应用系统实例一Napster。 Napster.com是一 个著名的P2P文件传输服务实例，它是一种在线音乐服务,是第一个被广 泛应用的P2P音乐共享服务，是一个可以在网络中下载自己想要的MP3文件的软件，同时能够让自己的
机器也成为一台服务器，为其他用户提供下载服务。Napster是基 于P2P范型的，因为所有参与Napster应用的客户软件(进程)既是音乐文件的请求者，也是音乐文件的提供者，它们之间构成一个P2P网络。 与Napster类似的站点允许在Internet上的多个计算机之间传输文件(主要指音频文件)。除了P2P计算外，该站点还利用了- -台服务器来提供目录服务。

2.4消息系统范型
消息系统范型或面向对象的中间件(Message-Oriented Middleware, MOM)是在基本的消息传递范型的基础上扩展而来的。如图2-5所示，在这种范型中，消息系统充当- -些相当独立的进程之间的中介。不同的进程以非耦合的方式，通过消息系统异步地交换消息。消息发送者(进程) 在发送消息时，将- -条消息放入消息系统中，后者接着将该消息转发到与各个接收者(进程)相应的消息接收队列中，一旦消息发送出去，发送者即可执行其他任务了。

消息系统范型可以进一步划分为两种子类型:点对点消息范型(point-to-point message model)和发布/订阅消息范型(public/subscribe message mod1)。
1.点对点消息范型
在点对点消息范型中，消息系统将来自发送者的一条消息转发到接收者的消息队列中。与基本的消息传递模型不同的是，这种中间件模型提供了消息暂存的功能，从而可以将消息的发送和接收分离。通过中间件消息系统，发送者可将消息存入接收进程的消息队列中。接收进程则从自己的消息队列中提取消息，并加以处理。与基本的消息传递范型相比，点对点消息范型为实现异步消息操作提供了额外的一层抽象。如果要在基本的消息传递范型中达到同样的结果,必须借助于线程或者子进程技术。①无识别结果
2.发布/订阅消息范型
在发布/订阅消息范型中，每条消息都与某一主体或事件相关。 对某个事件感兴趣的应用程序可以订阅与该事件相关的消息。当订阅者等待的事件发生时，触发该事件的进程将发布一条消息来宣布该事件或主题。中间件消息系统将这条消息分发给该消息的所有订阅者。发布/订阅消息范型提供了一种用于组播或组通信的强大抽象机制。 发布操作使- -个进程可以向一组进程组播消息， 订阅操作则使一个进程能够监听这样的组播消息。消息系统范型或MOM模型在分布式应用中的应用已经有相当长的一-段历史了。消息队列服务(Message Queue Services, MQS)的应用始于20世纪80年代，直到现在仍然有大量的应用使用该范型: IBM公司的MQ Series应用、Microsoft公司的Microsoft’ s Message Queue、Sun公司的Java Message Service等。JMS即Java消息服务(Java Message Service)应用程序接口是一个Java平台
中关于MOM的API,用于在两个应用程序之间或分布式系统中发送消息，进行异步通信。JMS是-一个与具体平台无关的API,绝大多数MOM提供商都对JMS提供支持。
如图2-6所示为消息系统的应用系统实例一电子邮件系统。 电子邮件系统是基于消息系统范型的一-种具体应用。电子邮件系统由用户代理、传输代理、投递代理组成，首先用户通过用户代理将电子邮件发至电子邮件服务器，电子邮件服务器即传输代理，将收到的电子邮件放入电子邮件队列,并根据电子邮件的目的地址由投递代理转发电子邮件。

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

RPC机制使得编程，人员可以采用一种类似于本地过程调用的程序设计构造，以构建网络应用程序。这种机制为进程间通信和事件同步提供了-种方便的抽象。因此，RPC模型使得程序员们能够采用类似于本地过程调用的编程方法，以构建网络应用程序。1993年，Microsoft提出 了一种组件式软件平台，可用于进程间通信，还可用于组件式软件开发，该平台即组件对象模型(Component Object Model, CO
M)。COM提供跟编程语言无关的方法实现-一个软件对象，因此可以在其他环境中运行。COM提供了一套允许同一 台计算机上的客户端和服务器之间进行通信的接口，它要求软件组件必须遵照一个共同的接口，但是隐藏接口的实现，它可以被其他对象在不知道其内幕的情况下正确使用。COM作为Windows 下主要的软件开发平台，利用接口来隐藏实现的组件式开发模型的机制影响和改变了很多其他的技术。
COM使得软件开发不断趋向于组件化，开发人员将单个应用程序分隔成单独或多个独立的部分，即组件,通常我们在Windows系统下使用的动态链接文件(Dynamic Link Library, DLL)就是一个组件。我们可以随着技术的发展不断更新组件，还可以利用原有的组件快速构建新应用。DCOM (Distributed COM,分布式COM)是可以在网络上通信的COM组件，又可以称为Network OLE,依据RPC的规范来发展的,它将COM组件的能力扩及网络上。DCOM及分布式组件对象模型是一 系列Microsoft的概念和程序接口，利用这个接口，客户端程序对象能够请求来自于网络中另- – 台计算机上的服务器程序对象。DCOM处理网络协议的低层次的细节问题，从而使用户能够集中精力解决所要求的问题。
Microsoft公可的ActiveX是基于标准COM接[实现对象链接与嵌入的一种技术，可以运行在- -些浏览器上,使得网页可以通过脚本和ActiveX控件交互以产生更加丰富的效果。ActiveX组件也可以运行在服务进程之间，例如，ADO (ActiveX Data Objects)是-一个访问数据源的COM组件，允许开发人员编写代码来访问不同的数据源。对象连接与嵌入技术(Object Linking and Embedding, OLE)定义和实现了-种允许应用程序作为软件对象(数据集合和操作数据的函数)彼此进行连接的机制。对象链接嵌入数据库(Object Linking and Embedding Database, OLED
B)是Microsoft为以统一 -方 式访问不同类型的数据存储设计的一-种应用程序接口，是一组用组件对象模型(COM)实现的接口。图2-8所示为远程过程调用的应用系统实例-远程数据库访问。在分布式系统中，数据库一般驻存在服务器上， 客户机(进程)通过远程数据库服务功能访问数据库服务器，现有的远程数据库服务是使用RPC模式的，例如，Oracle数据库提供了存储过程机制，系统与用户定义的存储过程在数据库服务器上，用户在客户端使用RPC模式调用存储过程获取数据。

2.6 分布式对象范型
分布式对象范型将面向对象应用到分布式系统中，是面向对象软件开发技术的自然扩展。该范型使应用程序可访问分布于网络上的各个对象。通过调用对象的方法，应用程序可获取对服务的访问。
2.6.1远程方法调用
远程方法调用(Remote Method Invocation, RMI)是面向对象版本的RPC。如图2-9所示，在该范型中，进程可以调用对象方法，而该对象可驻留于某远程主机中。与RPC- -样,参数可随方法调用传递，也可提供返回值。

我们常说的RMI范型是指Java RMI,即Java远程方法调用(Java Remote Method Invocation)，用于实现远程过程调用的Java应用程序编程接口。Java RMI使用接口化编程。在需要服务端的某一个远程对象时， 编程人员通过定义-一个该对象的接口来隐藏它的实现，并在客户端定义一个相同的接口，客户端使用该接口可以像本地调用一样实现远程方法调用。Java RMI使编程人员能够在网络环境中分布工作，极大地简化了远程方法调用的过程。后面将详细绍Java RMI的具体内容。
2.6.2对象请求代理
对象请求代理范型由对象请求者(object requestor)、对象提供者(object)和对象请求代理(Object Request Broker, ORB)组成(如图2-10所示)。在对象请求代理范型中，进程向对象请求代理发出请求，对象请求代理将请求转发给能提供预期服务的适当对象。对象请求代理范型与RMI范型非常相似。两者的主要区别在于，对象请求代理范型多了-一个对象请求代理，对象请求代理充当中间件角色，作为对象请求者的应用程序可访问多个远程(或本地)对象。对象代理还可以作为异构对象之间的协调者，允许由不同API实现的对象及运行于不同平台上的对象进行交互。

ORB是OMG (Object Management Group)组织提出的CORBA (Common Object Request Broker Architecture)的基础，CORBA是由OMG组织为解决分布式处理环境中不同平台之间的互联而制定的一种标准的面向对象应用程序体系规范。ORB提供了客户与服务器联系的中间件，使得客户对象可以不关心服务器对象的位置、工作的平台,以及采用何种技术实现。根据CORBA规范，软件开发人员可以实现CORBA框架定义的任何构建。其中Java IDL是兼容CORBA规范的开发工具，我们可以利用它以及其他兼容设施来开发CORBA应用。
2.7网络服务范型
如图2-11所示，网络服务范型由服务请求者、服务提供者(对象)和目录服务三者组成。网络服务范型的工作原理为:服务提供者将自身注册到网络上的目录服务器上;当服务请求者(进程)需访问服务时，则在运行时与目录服务器联系;然后，如果请求的服务可用，则目录服务器将向目录服务进程提供一个有关该服务的引用;最后，进程利用该引用来与所需的服务进行交互。

该范型本质上是对远程方法调用范型的扩展，区别在于服务对象在全局目录服务中注册，允许网络中的服务请求者查询和访问这些服务。在理想情况下，可以采用全局唯一标志符注册和访问服务，在这种情况下，范型将提供额外的一种抽象:位置透明性。位置透明性允许软件开发者在访问对象或服务时,无需知道对象或服务所在的具体位置。Java的JINI (Java Intelligent Network Infrastructure)和Web Service都是
属于该范型的网络设施。Web服务使用XML和XSD标准来自我描述,用简单对象访问协议(Simple Object Access Protocol, SOAP)交换数据。使用Web服务技术，能使运行于不同机器上的不同应用无需借助其他的支持就可以相互通信。Web服务向外界提供一个能够通过Web进行调用的API, 即目录服务。服务访问者可以通过远程过程调用(RPC) 的方式访问Web服务,无需知道服务的位置、工作的平台以及实现方式。图2-12所示为一个网络服务的应用系统实例一-WebXm。 Web服务提供给人们日常生活中很多便利，webxml.com提供很多实用Web服务,如数据来源于中国气象局的天气预报Web服务、IP地址来源查询Web服务等。图2-12展示 了WebXml网络服务的基本访问流程。

2.8 移动代理范型
移动代理是一-种可移动的程序或对象。如图2-13所示， 在移动代理范型中，一个代理从源主机出发,然后根据其自身携带的执行路线，自动地在网上主机间移动。在每一主机上,代理访问所需的资源或服务,并执行必要的任务来完成其使命。

移动代理范型为可移动的程序或对象提供了抽象。这种范型不进行消息互换，而是当程序/对象在各个参与结点间移动时,携带并传递数据。支持移动代理范型的商业软件包有Concordia系统和IBM公司的Aglet系统。一个移动代理的典型应用系统实例为Agent Tcl (Tool Command Language)。到目前为止,已经出现了多种移动代理应用，其中大部分系统还只是原型系统，它们的针对性不同，实现方法也不同Dartmouth大学的D’ Agents小组致力于移动代理的开发和应用，由他们研发的Agent TcI系统实现了多语言跨平台的移动代理功能，详细信息请参见网站Agent.cs.dartmouth.edu.
2.9云服 务范型
美国国家标准与技术研究院(NIST) 定义了云计算的三种服务模型:基础设施即服务(laaS) 、平台即服务(PaaS) 、软件即服务(SaaS) 。3种类型云服务对应不同的抽象层次，如图2-14所示，它们的详细描述如下。

1. 基础设施即服务:云供应处理、存储、网络以及其他基础性的计算资源，以供用户部署或运行自己的软件，包括操作系统或应用。用户并不管理或控制底层的云基础设施，但是拥有对操作系统、存储和部署的应用的控制，以及一些网络组件的有限控制。
   2)平台即服务:用户可在云基础设施之上部署用户创建或采购的应用，这些应用使用服务商支持的编程语言或工具开发，用户并不管理或控制底层的云基础设施，包括网络、服务器、操作系统、或存储等，但是可以控制部署的应用，以及应用主机的某个环境配置。
   3)软件即服务:用户可使用服务商运行在云基础设施之上的应用。用户使用各种客户端设备通过“瘦”客户界面(例如浏览器)等来访问应用(例如基于浏览器的邮件)。用户并不管理或控制底层的云基础设施，例如网络、服务器、操作系统、存储甚至其中的单个应用，除了某些有限用户的特殊应用配置项。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8699 人正在系统学习中

来源：她是人间十月天