一、系统模型引言

这篇文章描述系统模型。我们知道在上一篇博客当中主要介绍了分布式系统的概念、前景和挑战。这篇文章主要介绍系统模型。什么是系统模型呢？系统模型也就是分布式系统是如何设计的、整体的架构是什么？在这里从三个方面来介绍，物理模型、体系结构模型、基础模型。下面先看一下这三个模型的介绍以便在下面详细介绍时有更加深刻的认识。

物理模型：考虑分布式系统中计算机是如何互联的，以及这些设备的类型，不考虑特定的技术细节（也就是从硬件方面来看如何组成分布式系统的）
体系结构模型：他是从系统的计算元素执行的计算和通信任务来描述分布式系统的。这里的计算元素指的是网络上互联的计算机集合。C-S模型和对等模型是最常见的体系结构模型。
基础模型：采用了抽象的观点描述了分布式系统中单个问题的解决方案，他通过三个模型来讨论

交互模型：处理分布式系统中的性能问题和设置时间约束的困难（在系统元素之间通信的结构与顺序）
故障模型：他定义了可靠地通信和正确的进程（考虑分布式系统正确操作的方式）
安全模型：讨论对进程和通信通道的各种可能的危险（考虑不被干扰或者是不被窃取数据）

二、物理模型

1、基线物理模型

在上一篇博客当中我们介绍了分布式系统的概念，被定义为位于联网计算机上的硬件或者是软件组织通过消息传递进行通信和协调的系统。这引出了分布式系统中的最小的物理模型，也就是可以扩展的计算机节点，这些节点通过网络进行消息传递。

2、三代分布式系统

由基线物理模型，引出下面三代分布式系统。

早期的分布式系统：这样的系统在70年代中期到80年代早期，随着局域网的出现而出现，这时候一般由10到100各节点组成，他们与互联网链接有限只支持少量的服务，比如本地打印机还有电子邮件等等。此时的系统是同构的，开放性不是主要的问题。
互联网规模的分布式系统：实在90年代早期开始出现，此时底层的物理础设施是如下图所示的。这些节点是可扩展的，通过互联网连接。在这样的系统中，其异构性其异构性是非常突出的，这使得开放标准和中间件技术的不断增加。在这样的全球化系统中采用了额外的服务来提供端到端的服务质量特性。
当代的分布式系统：在上面的系统中通常是台式机，因此是相对静态的、分立的（没有嵌入到其他物理实体内）、自治的。第一、但是当前笔记本电脑和智能手机这样的节点可以从一个位置移动到另外一个位置，第二、并且无处不在计算的出现导致了体系结构从分立节点型开始转变，开始转变到计算机被切入到日常物品和周围环境当中（比如智能家居）。第三、云计算的出现导致了之前是一个自治节点完成一个任务，现在是一柱节点完成一个任务。这些原因最终导致了异构性得到很大增加的物理体系结构。

系统的系统：超大规模的分布式系统，其子系统也是一个系统，他们一起完成一个或者是多个任务。举一个例子考虑一个洪水预测的环境管理系统，传感器收集洪水状态的系统与预测洪水可能性的系统耦合在一起为民众提供早期的洪水报警。

最后对这三代系统做出一个总结：

三、体系结构模型

一个系统的体系结构是这样一种结构，用独立的组件以及这些组件之间的关系来表示的结构。整体的目标是满足现在和将来可能的需求。主要关系的是系统的可靠性、可管理性、适应性和性价比。比如说设计一个建筑物，不仅要决定它的外观，还决定其总体结构和体系结构风格（哥特式、现代是），并设计一个参考框架。

1、体系结构元素

为了理解一个分布式系统的基础构建块，现在考虑下面四个问题：

分布式系统中通信的实体是什么
分布式系统如何通信？使用什么通讯范型？
这些实体在整个系统中扮演什么角色？承担什么责任？
他们被放置到哪里？

下面来一个一个看这些问题：

第一：通信实体

通常情况下，通信的实体被认为是进程，这导致普遍的认为分布式系统其实就是，带有恰当进程间通信范型的多个进程。但是在一些情况下不是这样的，比如说在传感器网络当中，操作系统中可能不支持进程抽象，这时候系统通信的实体是节点。还有一些系统中，使用线程而不是进程，所以严格的来讲，通信的末端是线程。我们已经抽象出了进程和线程的概念，然而从编程的观点来看，这还不够，更多问题的抽象已经被提出：

对象：在分布式面向对象的方法中，一个计算由若干相互交互的对象组成，并通过结构访问这些对象。
组件：组件类似于对象，也是通过结构访问，关键的区别在于组件不仅给出接口，而且给出其他组件/接口的假设。他为系统提供了一个更加完成的合约。类似于Android中的组件，当然这里只是类比其实完全不一样，在这里姑且这样理解。我们通过接口使用Android中的组件，并且可以通过这些组件开发其他组件（自定义View的实现）。
web服务：web服务与对象和组件紧密相关，也是采用基于行为封装和通过接口访问的方法。W3C联盟把web服务定义成如下的概念：

第二：通信范型

在上面已经看到分布式系统中通信的实体很多，有进程、线程、对象、组件等等。在这里开始讨论这些实体如何进行通信。

我们考虑三种通信范型：

进程间通信
远程调用
间接通信

（1）进程间通信

进程间通信指的是用于分布式系统之间通信的相对底层的支持，包括消息传递原语、直接访问由互联网协议提供的API和对多播的支持.以后再详细介绍。

（2）远程调用

远程调用时分布式系统中最常见的通信范型，覆盖一系列分布式系统中通信实体之间基于双向交换的技术。请求应答协议是一个有效地模式，他加在一个底层消息传递服务之上，用于支持客户-服务器计算。比如请求一个网页，第一个消息包含在服务器端执行操作的编码，第二个消息包含操作的结果。这种范型相对原始。

远程过程调用（RPC）的出现是一个突破，在RPC中，远程计算机上的进程能够被调用，好像在本地调用一样。就好像在QQ里面的远程控制一样，我们可以控制别人的电脑，此时我们的电脑（服务器）通过一个服务接口提供一套操作，当这些操作在本地可用时候，我们可以直接调用这些操作（在别人电脑上操作）。因此RPC系统提供访问和位置透明性。

远程方法调用（RMI）类似于远程过程调用，用这种方法，一个对象可以调用远程对象中的方法。与RPC一样，底层的细节都对用户隐藏。我对此的理解就好比WebService。

上面这些方法都有一个共同点：通信代表了发送者和接受者之间的双向关系，在大多数情况之下，双方必须同时存在。相比之下，开始出现一些新的技术，这些技术支持间接通信。他们通过第三个实体之间进行通信，实现了发送者与接受者之间的解耦合。

（3）间接通信

为什么要使用间接通信呢？先看一下下面这两个问题：

发送者不需要知道他们发给谁
发送者和接受者不需要同时存在

这时候发送者和接受者如何进行通信呢？就是刚刚提到的使用第三个实体进行通信。下面是一些实现的技术。

组通信：组通信指的是消息传递给若干接受者，是一对多的通信。一个组在系统中用一个组标识符来表示，接受者通过加入这个组，有选择性的接收到组内的消息。此时发送者只需要通过组标识符发送消息，而不需要知道消息的接受者。
发布-订阅系统：类似于报纸系统，报社发报纸，用户订报纸。ROS的发布-订阅系统和这个原理是一样的。
消息队列：消息队列提供了一种点到点的服务，其中生产者进程发送消息到一个指定的队列，消费者从队列中接收消息，因此，队列是生产者和消费者进程之间的中介。
元组空间：进程能把任意的结构化数据项（元祖）放到一个持久的元祖空间，其他进程可以指定感兴趣的模式，从而可以在元组空间读或者是删除元组。因为元组空间是持久的，因此不需读写操作同时存在。这也被称之为生成通信。
分布式共享内存（DSM）：它提供了一种抽象，用于支持在不共享物理内存的进程之间共享数据，程序员在使用这些数据时候，就好像这些数据在本地一样。

现在总结一下到目前为止说的体系结构：

第三：承担的角色与责任

在这里我们考察两种起源于单个进程角色的体系结构风格：客户-服务器风格和对等风格。

（1）客户-服务器风格

这是分布式系统中最常用的体系结构，下面给出一个简单的结构，其中进程扮演服务器和客户的角色。

如图所示，一台服务器也可以是其他服务器的客户。比如web服务器和大多数其他互联网服务是DNS服务的客户，DNS服务用于将互联网域名翻译成网络地址。

（2）对等体系结构

在这种体系结构中，设计意向任务或者是活动的所有进程都扮演这相同的角色，作为对等关系进行交互，没有客户与服务器的关系。使用这种体系结构是因为客户-服务器模型虽然为数据和其他资源提供了一个直接和相对简单的方法，但是他的伸缩性比较差，比如我们把一个服务放在同一个地址，此时意味着集中化的管理这个服务，当我们集中的去使用这个服务时候，就会出现问题。因为我们的电脑提供服务的能力和这个计算机所在的网络连接的带宽是有限的。他的伸缩性会受限。

针对这个问题，就促使了对等系统的发展，这是因为在对等系统中，一个用户使用一个服务时，自己的计算机所拥有的网络和计算资源也能被投入使用，以支持哪个服务。这会产生一个非常好的效果，当我们的用户数量增加时候，此时可用于运行的服务也会随之增加。

第四：实体被放置在哪？

这是最后一个要考虑的问题，也就是对象、组件、进程这样的实体是怎么映射到底层的物理设施之上的。物理分布式基础设施由大量的机器组成，这些机器通过一个任意复杂的网络互联。放置是一个很重要的操作，因为它会影响分布式系统的性能、安全等特性。我们主要关注下面的这些放置策略：

将服务映射到多个服务器
缓存
移动代码
移动代理

（1）将服务映射到多个服务器

意思是服务器将服务所基于的对象集分区，然后将这些分区分布到各个服务器上，或者是服务器可以在几个主机上维护复制的对象集。这两种选择可以用下面例子说明

web是一个常见的将数据分区的例子。一个基于复制数据的服务是Sun网络信息服务。

（2）缓存

它类似于我们手机中的缓存，缓存用于存储最近使用的数据对象，当服务器接受一个新对象时候，就将他存入缓存，必要的时候会替换掉那些对象。比如我们的浏览器，当我们访问一个界面时候，浏览器会在本地的文件系统中寻找是否含有我们访问的那个界面，如果有就直接拿出来使用。web代理服务器为一个或者是多个地点的客户机提供共享的存放web资源的缓存。代理服务器的目的是通过减少广域网和web服务器的负载，提供服务的可用性和性能。

（3）移动代码

applet是一个广泛使用的移动代码的例子，也就是运行浏览器的用户选择了一个到applet的链接，applet的代码存储在web服务器上将applet的代码下载到浏览器并在浏览器端运行。

（4）移动代理

移动代理可以通过安装和维护一个组织内部的计算机软件，或者是通过访问每个销售商的站点并执行一些列数据库操作，来比较多个销售商的产品价格。和移动代码一样，移动代理对所访问的计算机上的资源而言是一个潜在的安全威胁，另外移动代理自身是脆弱的，如果他们访问所需要信息的要求被拒绝时候，那么他们可能完成不了任务。

2、体系结构模式

在上述的体系结构元素中都是单个的，而这里的体系结构模式是组合重复出现的结构。在本节中给出几个关键的体系结构模型，包括分层体系结构、层次化体系结构、瘦客户。

（1）分层

在分层方法中，一个系统被分成若干层，每一层利用下一层提供的服务。因此，一个给定的层提供了一个软件抽象，更高层次的层不清楚其下面的层的实现细节。他只使用下层提供的服务。

举一个例子，在互联网上基于网络时间协议可以实现一个网络时间服务，意思是服务器在互联网的主机上，给请求的用户提供当前的时间。下面是其分层的体系结构。

在这里提到了两个概念：平台和中间件，下面看看其概念

平台：

中间件

中间件表示成计算机上的集成或者是对象，这些进程或者是对象相互交互，实现分布式系统应用的通信和资源共享支持。特别的，他提供多个协作的计算机上的分布，放置和检索、共享数据对象的复制以及多媒体数据的实时传送，提升应用程序通信活动的层次。其实就是把一些底层抽象，来提供两个计算机的通信。

（2）层次化体系结构

分层将服务垂直组织成抽象层，而层次化是一项组织给顶层功能的技术。他把这个功能放在合适的服务器上，或者作为第二选择放在物理节点上。我们先看二层和三层体系的结构概念：

表示逻辑：设计用户交互和修改呈献给用户的应用试图。
应用逻辑：涉及与应用相关的详细的应用特定处理。
数据逻辑：涉及应用的持久性存储，通常放在一个数据库管理系统中。

下图分别给出了两层和三层体系结构给出的解决方案：

二层和三层的对比
	二层	三层
优点	1、具有交互的低延迟 2、仅有调节信息的消息交换	1、提高软件的可维护性
缺点	1、将应用逻辑分离到不同的进程，带来的后果是一部分应用逻辑不能被另一部分直接调用	1、增加了管理三个服务器的复杂性 2、增加了与每个操作相关的网络流量和延迟

下面举一个例子来说明分层体系结构的好处：

以维基百科为例，它采用了多层体系结构（大于三层）来处理大量的web请求（每秒高达60000页）。我们知道浏览器发送了一个请求web网页的http请求，用户不能与该页面进行交互，一直到新的HTML内容被浏览器收到并呈现，这个时间间隔是不固定的，因为他受限于网络以及服务器延迟。此时便有了ajax。ajax能够有效地处理这种问题，他能局部的更新整个页面，就像我们浏览器中的时钟一样，我们的时间在一秒一秒的更新（更新时间需要请求服务器），此时我们的浏览器依然可以做其他事情。

专业一点的术语是：AJAX提供一套通信机制，使运行在一个浏览器中的前端组件能够发送请求，并从运行在服务器上后端的组件接受结果。

比如我们的地图，当地图被移动时候，浏览器中的Javascript代码重定位可见的图片，需要填充可见区域的额外的图片，可以通过AJAX调用Google服务器去获得。图片一旦收到就会被展示，但浏览器在等待的时候可以继续应答用户的交互。

（3）瘦客户

术语瘦客户指的是一个软件层，在执行一个应用程序或者访问远程计算机上的服务时候，由该软件层提供一个基于窗口的本地用户界面。他减少了用户的硬件要求，各种复杂的服务，通过云来解决。它的缺点是，因为各种复杂的服务都是通过云来解决，此时会有网络延时。

比如，QQ的远程桌面控制。

（4）其他经常出现的模式

代理：支持远程过程调用或者是远程方法调用的位置透明性
web服务中的业务代理：在一个可能很复杂的分布式基础设施中支持互操作性的体系结构模式。
反射

3、相关的中间件解决方案

先看中间件的分类

四：基础模型

在上述完全不同的系统模型中，都有一个共同点，也就是所有的进程都由若干进程组成，这些进程通过在计算机网络上发送消息而相互通信，但是所有的模型都没有达到下列需求：实现进城以及网络的性能和可靠性特征，确保系统中资源的安全性。

因此，我们希望在我们的基本模型中提取的分布式系统情况能解决下列问题

交互：计算在进程中发生，进程通过传递消息交互，并引发进程之间的通信和协调。交互模型必须反映通信带来的延迟，这些延迟的持续时间会比较长。并且，交互模型必须反映独立进程相互配合的准确性受限于这些延迟，受限于在分布式系统中很难跨所有计算机维护同一时间概念。
故障：只要分布式系统出现故障，我们的模型将对这些故障进行定义和分类。
安全：分布式系统暴露在外部代理和内部代理的攻击之下。我们的安全模型对这些攻击进行定义和分类。

分布式系统（2）系统模型