搜索
软件体系结构与设计浙江大学城市学院周苏教授QQ：81505050第12章分布式系统体系结构第12章分布式系统体系结构•分布式系统的概念•分布式系统的问题•交互模型•中间件•客户机-服务器计算•分布式系统的体系结构模式•软件作为服务•事实上，所有大型计算机系统现在都是分布式系统。与所有的系统组件在一台单独的计算机上执行的集中式系统相反，分布式系统中包括有许多台计算机，是“一个独立计算机的集合体，但给用户的感觉却是面对一个独立的系统。”由于系统组件可能运行在独立管理的计算机上以及组件间要经过网络通信，因此，分布式系统的设计中有许多特殊问题需要予以考虑。第12章分布式系统体系结构12.1分布式系统的概念•分布式系统（distributedsystem）是建立在网络之上的软件系统。正是因为软件的特性，分布式系统具有高度的内聚性和透明性。网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统与计算机网络在物理结构上是基本相同的。12.1分布式系统的概念•在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体。系统拥有多种通用的物理和逻辑资源，可以动态地分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。12.1分布式系统的概念•分布式操作系统的设计思想和网络操作系统不同，这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况，在网络中如果用户要读一个共享文件时，用户必须知道这个文件放在哪一台计算机的哪一个目录下；分布式操作系统是以全局方式管理系统资源的，它可以为用户任意调度网络资源，并且调度过程是“透明”的。12.1分布式系统的概念•当用户提交一个作业时，分布式操作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提交到该处理程序，在处理器完成作业后，将结果传给用户。在这个过程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个处理器一样。12.1分布式系统的概念•用分布式方法开发系统的主要优势是：–（1）资源共享。分布式系统允许硬件、软件资源，如磁盘、打印机、文件和编译器等共享使用。虽然在多用户系统上也是可以共享资源，但在这种情况下资源必须放在一个中央计算机上统一管理。–（2）开放性。是指系统通过添加非私有资源来扩展自己的能力。分布式系统是开放的系统，它一般包括来自不同厂商的软件和硬件的兼容产品。–（3）并发性。在分布式系统中，有许多过程可以在网络的不同计算机上同时运行。这些过程在其正常运行期间可以（但不是必需）彼此通信。12.1分布式系统的概念–（4）可扩展性。原则上，分布式系统至少要有可扩展性，系统的能力可以通过增加新的资源来满足对系统的新的需求。实际过程中，可扩展性可能受到网络的限制。–（5）容错性。多台计算机及其信息复制能力意味着系统对硬件和软件错误具有相当的容错能力。在绝大多数分布式系统中，当有错误发生时，可能会使提供的服务能力下降，但彻底丧失服务能力只有在发生网络错误时才会出现。12.1分布式系统的概念•由于具有这些优点，分布式系统已经大量地替换了早年所开发的大型机遗留系统。然而，还有许多个人计算机应用系统（例如，照片编辑系统）不是分布式的，这些系统运行在单个的计算机系统上。许多嵌入式系统同样也是单处理器系统。12.1分布式系统的概念•分布式系统本质上比集中式系统更复杂，因而更难设计、实现和测试。由于系统组件和系统基础结构之间交互的复杂性，分布式系统的总体特性是很难了解的。例如，系统性能不再取决于一个处理器的运行速度，它依赖网络带宽、网络负载和系统中所有计算机的速度。将系统某部分的资源转移到另外地方将严重影响系统的性能。•此外，分布式系统的响应是不可预知的。这个响应依赖于系统的总负荷、它的体系结构以及网络负荷。由于这些因素都是在一个较短时间内变化的，同一个用户的两个请求之间就会有极大的响应差别。12.2分布式系统的问题•分布式系统的复杂性主要源于该系统不可能有一个自顶向下的控制模型。系统中提供功能的节点通常是独立的系统，它们没有单独管理系统的权限。连接这些节点的网络是一个单独管理的一个系统，这个系统本身很复杂，并且不能被使用网络的用户所控制。因此，分布式系统的运行本质上就会有不可预测性。•在分布式系统工程中必须考虑的重要设计问题是：透明性、开放性、可扩展性、信息安全性、服务质量和失败管理。12.2.1透明性•理想情况下，系统的分布性对于用户应该是透明的。这意味着用户会把系统看成一个单一的系统，这个单一系统的行为不会受分布的影响。事实上这是不可能完成的，因为分布式系统不可能实现集中控制，并且系统中单独的计算机在不同时间的行为是不同的。此外，由于信号在网络中的传输需要一定的时间，网络延迟是不可避免的。延迟的长度依赖于系统中资源的位置、用户网络连接的质量和网络负载。12.2.1透明性•实现透明性的设计方法依赖于在分布式系统中创建资源的抽象，这样，这些资源的物理实现就可以改变而无需应用系统做任何改变。中间件用于将程序中引用的逻辑资源映射到实际的物理资源上，及管理这些资源之间的交互。12.2.2开放性•开放性的分布式系统是依据普遍接受的标准来建立的系统。这意味着提供商提供的组件可以整合到系统中，而且可以和其他系统组件互操作。在网络层面，开放性要遵从互联网协议，但是在组件层面，开放性还没有普及。开放性意味着系统组件可以使用任何编程语言独立的开发，并且如果这些组件符合标准，这些组件将会和其他组件一起运作。12.2.2开放性•CORBA（通用对象请求代理体系结构）标准是一个闻名的对中间件系统的描述，它是由对象管理集团（OMG）于20世纪90年代提出来的。它的目标是建立一个开放标准允许开发中间件支持分布的组件通信和执行，也提供一系列被这些组件使用的标准服务。已经有了CORBA的多个开放性实现，但是现在应用得不是很广泛了，用户倾向于使用专用的系统或是投向面向服务的体系结构，比如企业JavaBeans（EJB）或者.NET。SUN公司和微软公司的组件标准提供了更好的软件实现和软件支持以及对产业协议更好的长期支持。12.2.3可扩展性•系统的可扩展性反映了系统能在需求增长的情况下提供高质量服务的能力，包括以下3个方面：–（1）规模。应该可以增加更多的资源到系统来应付越来越多的用户。–（2）分布。应该可以地域性地分散系统的组件而不会降低系统的性能。–（3）可管理性。当系统的规模增加时应该可以管理它，即使系统的组件位于独立的机构。12.2.3可扩展性•所谓的规模，有增强扩展和增加扩展的区别。增强扩展意味着用更强大的资源替换系统中的资源。例如，你或许会把服务器的内存由16GB增加到64GB。增加扩展是指向系统增加更多的资源（例如，增加一个额外的服务器与现存的服务器一起工作）。增加扩展通常要比增强扩展更有成本效益，但是这意味着系统要设计得能并行处理才行。12.2.4信息安全性•与集中式系统相比，分布式系统可能遭到攻击的方式会明显增加。如果系统的一个部件被成功的攻击，那么攻击者很可能以此作为“后门”来入侵系统的其他部件。12.2.4信息安全性•分布式系统必须防卫以免遭到以下类型的攻击：–（1）拦截。系统部件之间的通信被攻击者拦截，因此将会丧失机密性。–（2）中断。系统的服务遭到攻击并且不能按照预期来提供服务。拒绝服务攻击包括使用非法请求轰击一个节点，使得该节点不能处理合法的请求。–（3）更改。系统中的服务和数据被攻击者修改。–（4）捏造。攻击者生成本不应该存在的信息并且使用这些信息获得一些权限。例如，一个攻击者可能会生成一个不真实的密码入口并借此访问系统。12.2.4信息安全性•分布式系统最大的难点是建立一个能可靠地应用于系统中所有组件的信息安全策略，它规定了一个系统所能达到的安全级别。信息安全机制，比如加密和认证，被用来执行信息安全策略。在分布式系统中出现的难点是由于不同的机构可能拥有系统的组件。这些机构或许有互不兼容的信息安全策略和信息安全机制。不得不制定安全协商以允许系统一起工作。12.2.5服务质量•分布式系统提供的服务质量（QoS）反映了系统的一种能力，即可靠地提供服务并使得响应时间和吞吐量对于用户来说都是可接受的。理想情况下，服务质量需求应该事先具体化并且设计和配置系统来提供这样的服务质量。但这通常是不现实的，有两个原因：–（1）设计和配置系统提供高负荷下的高服务质量是不符合成本效益的。这可能因为提供的资源在大多数时间是闲置的。“云计算”主要争论之一是它部分地解决这个问题。使用云，当需求增加时很容易增加资源。–（2）服务质量参数可能会相互矛盾。例如可靠性的提升可能意味着吞吐量的减少，这是由于引进了检查程序来保证所有的系统输入都是合法的。12.2.5服务质量•当系统处理时间紧迫的数据如语音或视频流时，服务质量是至关重要的。在这种情况下，如果服务质量降到了阙值以下，那么语音或视频可能会衰减到无法接受。系统处理语音和视频应该包括服务质量协商和组件管理。这些应该评估服务质量需求而不是可用资源，如果这些是不足的，协商提供更多的资源或者降低服务质量目标。12.2.6失败管理•失败管理，即系统失败如何检测、抑制（使对系统的其他组件造成的影响最小和修复？•在分布式系统中出现失败是不可避免的，所以系统在设计上必须要适应这些失败。失败管理包括应用容错技术，分布式系统因而应该包括一个发现机制，即一旦发现系统的一个组件已经失败，要持续尽可能地提供很多服务而不管组件失败，以及尽可能自动地从故障中恢复。12.3交互模型•分布计算系统中的计算机之间可能会发生两种基本类型的交互，即过程式交互和基于消息的交互。过程式交互指的是一台计算机请求其他计算机提供的一个已知的服务并（总是）等待将要传送的服务。基于消息的交互指的是“发送”计算机在消息中定义所需要的信息并发送给另一台计算机。较之对另一台机器的过程调用，消息总是在一个单独的交互中传送更多的信息。12.3交互模型•为了说明过程式交互和基于消息交互的区别，我们来考虑在餐馆中点菜的情形。当你和服务员交谈时，你是在一系列同步的过程式交互中指定你要的东西的。你做出了请求；服务员收到请求；你做出另一项请求，请求收到；等等。这好比软件系统中的组件交互，其中一个组件调用来自其他组件的方法。服务员记下你所点的菜，以及和你一起的其他人所点的菜，然后服务员将包括了所点的每个菜的细节的消息传递给厨房以准备食物。本质上讲，服务员传递消息给厨房，消息定义了需要准备的食物。这是基于消息的交互。12.3交互模型•在分布式系统中过程式通信往往是通过远程过程调用（RPC）实现的。在远程过程调用过程中，一个组件调用另一个组件就像是调用本地的程序或方法。系统中的中间件拦截调用并把它传送给一个远程的组件。远程组件执行了所要的计算，通过中间件返回结果给调用组件。Java中的远程方法调用（RMI）与远程过程调用差不多，RMI框架在Java程序中处理对远程方法的调用。12.3交互模型•RPC要求一个“桩”以便所要调用的过程在请求的计算机上是可访问的。这个桩被调用并把过程的参数转化为一种标准的表示以便传送给远程程序。经过中间件，接着发送执行请求给远程程序。远程过程使用库函数转换参数成需要的格式，执行相应计算，并传输结果给中间件以便继续传输给发送者。12.3交互模型•基于消息的交互通常是组件创建一个消息，这个消息详细地说明了来自另一个组件的服务需求。通过中间件，消息发送给接收组件。接收者分析消息，执行计算，并为发送组件创建一个带有需求结果的消息。这个消息接着传到中间件以便传送给发送组件。12.3交互模型•远程过程调用方法带来的一个问题是调用者和被调用者需要在通信时都是有效的，它们必须知道如何相互指引。本质上，远程过程调用和本地