第2章 分布式计算范型

2.1 消息传递范型
消息传递是进程间通信的基本途径。如图2- 1所示,在消息传递范型中，表示消消息传递是进程间通信的基本途径。如图2- 1所示,在消息传递范型中，表示消息的数据在两个进程(进程A和进程B)间交换一 个是发送者，另一个是接收者。
消息传递是分布式应用的最基本范型。-个进程发送代表请求的消息，该消息被传送到接收者，接收者处理该请求，并发送一条应答消息。 随后，该应答消息可能触发下一个请求，引起下一个应答消息。如此不断反复传递消息，实现两个进程间的数据交换。
2.2客户/服务器范型
客户/服务器范型(简称C/S范型)是网络应用中使用最多的一-种分布式计算范型,该模型将非对称角色分配给两个协作进程。
其中，服务器进程(server process)扮演服务提供者色，被动地等待请求的到达;客户进程(client process)向服务器发起请求，并等待服务器响应。
客户/服务器范型的概念很简单，它有效地抽象了网络服务的请求，客户进程发起请求和接收响应。
通过为双方分配非对称的角色，即服务器进程监听和接收请求，客户进程发送请求和接收响应。
进程间的事件同步也被简化了:服务器进程等待来自客户的请求，客户进程则等待来自服务器的响应。
当前最流行的互联网应用WWW (或称为Web)是基于客户/服务器范型的一一个典型分布式应用。
它由Web服务器进程和浏览器客户进程构成。Web服务器进程不断侦听从Web浏览器进程发出的请求，服务器处理请求并发送响应。一旦收到应答后，浏览器进程解释收到的响应,并将文档显示出来。浏览器客户进程负责发送请求和接收响应。
Web应用的原理是基于HTTP协议的客户/服务器用户。
2.3P2P范型
P2P (Peer-to-Peer) 范型源于P2P网络(又称为对等计算网络)。
P2P网络是无中心服务器，依赖用户群交换的互联网体系。与客户/服务器结构的系统不同，在P2P网络中，每个用户端既是一个结点，又有服务器的功能，任何一个结点无法直接找到其他结点，必须依靠其期户群进行信息交流。
在P2P范型中，各参与进程的地位是平等的，具有相同的性能和责任(因此，称它们为peer)。
每个参与者(进程)都可以向另一个参与者发起请求和接收响应。在一个基于P2P范型的分布式应用中，每一个参与的进程往往既承担服务器进程的色(资源提供者)，又承担客户进程的角色(资源请求者)。
客户/服务器范型是集中式网络服务的理想模型(其中服务器进程提供服务，而客户进程通过服务器访问服务)。
而P2P范型更适合于诸如即时消息传送、P2P文件传输、视频会议、协同工作等应用。当然，基于P2P范型的应用也可以同时使用C/S结构来辅助处理一些任务。
2.4 消息系统范型
消息系统范型或面向对象的中间件(Message-Oriented Middleware, MOM)是在基本的消息传递范型的基础上扩展而来的。
在这种范型中，消息系统充当一些相当独立的进程之间的中介。不同的进程以非耦合的方式，通过消息系统异步地交换消息。消息发送者(进程)在发送消息时，将一条消息放入消息系统中，后者接着将该消息转发到与各个接收者(进程)相应的消息接收队列中，一旦消息发送出去，发送者即可执行其他任务了。
消息系统范型可以进一步划分为两种子类型: 点对点消息范型(point-to-point message model)和发布/订阅消息范型(public/subscribe message mode|)。
1.点对点消息范型
与基本的消息传递范型相比，点对点消息范型为实现异步消息操作提供了额外的一层抽象。如果要在基本的消息传递范型中达到同样的结果，必须借助于线程或者子进程技术。
2.发布/订阅消息范型
发布/订阅消息范型提供了一种用于组播或组通信的强大抽象机制。发布操作使一个进程可以向一 组进程组播消息， 订阅操作则使一个进程能够监听这样的组播消息。
消息系统范型或MOM模型在分布式应用中的应用已经有相当长的一段历史.了。消息队列服务的应用始于20世纪80年代，直到现在仍然有大量的应用使用该范型: IBM公司、Microsoft公司、Sun公司等。
2.5 远程过程调用范型
对于基本的网络协议和基本的网络应用程序来说，消息传递范型是适用的。但是，随着应用程序变得越来越复杂，需要为网络编程提供进一步的抽象。 最好有一种范型能使开发人员可以像编写在单处理器上运行的传统应用程序-样， 编写分布式软件系统。远程过程调用(Remote Procedure Call, RPC)范型就提供了这种抽象。利用这一抽象，可以采用与本地过程调用类似的思想与概念，以进行进程间通信。
2.6分布式对象范型
分布式对象范型将面向对象应用到分布式系统中，是面向对象软件开发技术的自然扩展。该范型使应用程序可访问分布于网络上的各个对象。通过调用对象的方法，应用程序可获取对服务的访问。
2.6.1远程方法调用
远程方法调用(Remote Method Invocation, RMI) 是面向对象版本的RPC。如图2-9所示，在该范型中，进程可以调用对象方法，而该对象可驻留于某远程主机中。与RPC- 样，参数可随方法调用传递，也可提供返回值。
2.6.2对象请求代理
对象请求代理范型由对象请求者(object requestor)、对象提供者(object)和对象请求代理(Object Request Broker, ORB)组。在对象请求代理范型中，进程向对象请求代理发出请求,对象请求代理将请求转发给能提供预期服务的适当对象。
对象请求代理范型与RMI范型非常相似。两者的主要区别在于，对象请求代理范型多了-一个对象请求代理,对象请求代理充当中间件角色，作为对象请求者的应用程序可访问多个远程(或本地)对象。
对象代理还可以作为异构对象之间的协调者，允许由不同API实现的对象及运行于不同平台上的对象进行交互。
2.7网络服务范型
网络服务范型由服务请求者、服务提供者(对象)和目录服务三者组成。
网络服务范型的工作原理为:服务提供者将自身注册到网络上的目录服务器上，当服务请求者(进程)需访问服务时，则在运行时与目录服务器联系，然后，如果请求的服务可用，则目录服务器将向目录服务进程提供一个有关该服务的引用后，进程利用该引用来与所需的服务进行交互。
2.8移动代理范型
移动代理是一种可移动的程序或对象。，在移动代理范型中，一个代理从源主机出发，然后根据其自身携带的执行路线，自动地在网上主机间移动。在每一主机上，代理访问所需的资源或服务，并执行必要的任务来完成其使命。
2.9云服务范型
美国国家标准与技术研究院(NIST) 定义了云计算的三种服务模型:基础设施即服务(laaS) 、平台即服务(PaaS) 、软件即服务(SaaS) 。3种类型云服务对应不同的抽象层次，如图2-14所示，它们的详细描述如下：
1)基础设施即服务:云供应处理、存储、网络以及其他基础性的计算资源，以供用户部署或运行自己的软件，包括操作系统或应用。用户并不管理或控制底层的云基础设施，但是拥有对操作系统、存储和部署的应用的控制，以及一些网络组件的有限控制。
2)平台即服务:用户可在云基础设施之上部署用户创建或采购的应用，这些应用使用服务商支持的编程语言或工开发，用户并不管理或控制底层的云基础设施，包括网络、服务器、操作系统、或存储等，但是可以控制部署的应用，以及应用主机的某个环境配置。
3)软件即服务:用户可使用服务商运行在云基础设施之上的应用，用户使用各种客户端设备通过"瘦”客户界面(例如浏览器)等来访问应用(例如基于浏览器的邮件)。户并不管理或控制底层的云基础设施，例如网络、服务器、操作系统、存储甚至其中的单个应用，除了某些有限用户的特殊应用配置项。

标签：范型,请求,对象,分布式计算,消息,进程,服务器
来源： https://blog.csdn.net/weixin_45975558/article/details/117781292