DCOM实现分布式应用（五）
DCOM实现分布式应用（五） (上一篇)
DCOM实现分布式应用（五）负载平衡 一个分布式应用系统越成功，由于用户数量的增长而给应用系统中的所有组件带来的负载就越高。一个经常出现的情况是即使是最快的硬件的计算能力也无法满足用户的需求。 这一问题的一个无法必免的解决方案是将负载分布到多个服务器中去。在“可扩展性”部分简要地提到了DCOM怎样促进负载平衡的几种不同的技术：并行配置，分离关键组件和连续进程的pipelining技术。 “负载平衡”是一个经常被使用的名词，它描叙了一整套相关技术。DCOM并没有透明地提供各种意义上的负载平衡，但是它使得完成各种方式的负载平衡变得容易起来。
静态负载平衡解决负载平衡的一个方法是不断地将某些用户分配到运行同一应用的某些服务器上。因为这种分配不随网络状况以及其它因素的变化而变化，所以这种方法称为静态负载平衡。 基于DCOM的应用可以很容易地通过改变登记入口将其配置到某些特定的服务器上运行。顾客登记工具可以使用Win32的远程登记函数来改变每一个客户的设置。在Windows NT 5.0中，DCOM可以使用扩展的目录服务来完成对分布的类的储存，这使得将这些配置改变集中化成为可能。 在Windows NT 4.0中，应用系统可以使用一些简单的技术达到同样的效果。一个基本的方法是将服务器的名字存到诸如数据库和一个小文件这样的众所周知的集中环境中。当组件想要和服务器相连接时，它就能很轻易地获得服务器的名字。对数据库或文件内容的改动也就同时改变了所有的用户以及有关的用户组。 一个灵活得多的方法使用了一个精致复杂的指示组件。这个组件驻留在一台为大家所共知的服务器中。客户组件首先和此组件连接，请求一个指向它所需服务的索引。指示组件能够使用DCOM的安全性机制来对发出请求的用户进行确认，并根据发出请求者的身份选择服务器。指示组件并不直接返回服务器名，它实际上建立了一个到服务器的连接并将此连接直接传递给客户。然后DCOM透明地将服务器和客户连接起来，这时指示组件的工作就完成了。我们还可以通过在指示组件上建立一个顾客类代理店之类的东西而将以上机制对客户完全屏蔽起来。 当用户需求增加时，管理员可以通过改变组件而为不同的用户透明地选择不同的服务器。此时客户组件没有做任何改动，而应用可以从一个非集中式管理的模式变为一个集中式管理的模式。DCOM的位置独立性以及它对有效的指示的支持使得这种设计的灵活性成为可能。
动态负载平衡静态负载平衡方法是解决不断增长的用户需求的一个好方法，但它需要管理员的介入，并且只有在负载可预测时才能很好地工作。 指示组件的思想能够提供更加巧妙的负载平衡方法。指示组件不仅可以基于用户ID来选择服务器，它还可以利用有关服务器负载、客户和可用服务器之间的网络拓朴结构以及某个给定用户过去需求量的统计数字来选择服务器。每当一个客户连接一个组件时，指示组件将其分配给当时最合适的可用的服务器。当然，从客户的观点看来，这一切都是透明发生的。这种方法叫做动态负载平衡法。 对某些应用来说，连接时的动态负载平衡法可能仍然是不充分的。客户不能被长时间中断，或者用户之间的负载分布不均衡。DCOM本身并没有提供对这种动态重连接以及动态的方法分布化的支持，因为这样做需要对客户进程和组件之间相互作用的情况非常熟悉才行，此时组件在方法激活过程中保留了一些客户的特殊的状态信息。如果此时DCOM突然将客户和在另一台机器上的另一个不同的组件再连接，那么这些信息就丢失了。 然而，DCOM使得应用系统的设计者能够很容易地将这种逻辑结构清楚地引入到客户和组件之间的协议中来。客户和组件能够使用特殊的界面来决定什么时候一个连接可以被安全地经过再寻径接到另一台服务器上而不丢失任何重要的状态信息。从这一点看来，无论是客户还是组件都可以在下一个方法激活前初始化一个到另一台机器上的另一个组件的再连接。DCOM提供了用来完成这些附加的面向特殊应用的协议的所有的丰富的协议扩展机制。 DCOM结构也允许将面向特殊组件的代码放到客户进程中。无论什么时候客户进程要激活一个方法时，由真实组件组件所提供的代理组件在客户进程中截取这一调用，并能够将其再寻径到另一台服务器上。而客户根本无需了解这一过程，DCOM提供了灵活的机制来透明的建立这些“分布式组件”。 有了以上独特的特性，DCOM使得开发用来处理负载平衡和动态方法寻径的一般底层结构成为可能。这种底层结构能够定义一套标准界面，它可以用来在客户进程和组件之间传递状态信息的出现和消失情况。一旦组件位于客户端的部分发现状态信息消失，它就能动态地将客户重连接到另一台服务器上。
例子：微软的事务服务器（以前叫做“Viper”）使用这一机制来扩展了DCOM编程模型。通过一套简单的标准状态信息管理界面，事务服务器能够获得必要的信息来提供高级别的负载平衡。在这种新的编程模型中，客户和组件之间的相互作用被捆绑到事务中，它能够指出什么时候一系列的方法调用所涉及的组件的状态信息都是清楚的。
DCOM提供了一个用来完成动态负载平衡的强大的底层结构。简单的指示组件在连接时可以用来透明地完成动态服务器分配工作。用来将单一的方法调用再寻径到不同的服务器的更尖端的机制也能够轻易地完成，但是它需要对客户进程和组件之间的相互作用过程有更为深入的了解。微软的完全基于DCOM建立的事务服务器（“Viper”）提供了一个标准的编程模型用来向事务服务器的底层结构传递面向这一附加的特殊应用的有关细节问题，它可以用来执行非常高级的静态和动态的重配置与负载平衡。
容错性容错性对于需要高可靠性的面向关键任务的应用系统来说是非常重要的。对于错误的恢复能立通常是是通过一定量的硬件、操作系统以及应用系统的软件机制来实现的。 DCOM在协议级提供了对容错性的一般支持。前面的“应用系统间的共享式连接管理”部分所描叙的一种高级pinging机制能够发现网络以及客户端的硬件错误。如果网络能够在要求的时间间隔内恢复，DCOM就能自动地重新建立连接。 DCOM使实现容错性变得容易起来。一种技术就是上一部分所说的指示组件的技术。当客户进程发现一个组件出错时，它重新连接到建立第一个连接的那个指示组件。指示组件内有哪些服务器不再有效的消息，并能提供在另一台机器上运行的这一组件的一个新的实例。当然，在这种情况下应用系统仍然需要在高级别上（一致性以及消息丢失问题等）处理错误的恢复问题。 因为DCOM可以将一个组件分别放到服务器方和客户方，所以可以对用户完全透明地实现组件的连接和重连接以及一致性问题。
图15 用于容错的分布式组件
另一技术经常被称为“热备份”。同一服务器组件的两个复本并行地在不同的机器上运行，它们处理相同的信息。客户进程能够明确地同时连接这两台机器。DCOM的“分布式组件”通过将处理容错性的服务代码放到客户端使得以上过程对用户应用完全透明。另一种方法是使用另一台机器上运行的一个协作组件，由它代表客户将客户请求发送给那两个服务器组件。 当错误发生时试图将一个服务器组件转移到另一台机器上经事实证明是失败的。Windows NT组的最初版本使用了这一方法，当然它可以在应用级完成。DCOM的“分布式组件”使得完成这一机能更容易了，并且它对用户隐蔽了实现细节。 DCOM使得完成高级的容错技术变得更为容易。使用DCOM提供的部分在客户进程中运行的分布式组件技术能够使解决问题的细节对用户透明。开发者无需改动客户组件，甚至客户机进行重新配置就能够增强分布式应用系统的容错性。 轻松配置 如果不容易安装和管理的话，即使是最好的应用系统也是没有用的。对于分布式应用来说，能够集中管理和尽可能简单的客户安装过程是非常关键的。同时，提供一些办法使系统管理员能够在潜在的错误造成任何损害之前尽可能早的发现它对于分布式应用也是非常必要的。 DCOM提供了什么技术能够让一个应用更加易于管理呢？
安装简化客户端安装的一种普遍方法可以概括为一个词“稀薄的客户”，意思是驻留在客户端的机能越少，安装以及可能发生的维护问题也就越少。 然而，客户组件越“稀薄”，整个应用的用户友好度就越低，对网络和服务器的需求也就越高。稀薄的客户还不能充分利用当今桌面办工系统所能得到的强大的计算能力，而由于诸如字处理软件以及电子表格软件这些桌面生产应用系统本身就具有统一而庞大的特性，所以大多数用户对于这种系统的强大的计算能力的需求也不会减弱。因此在正确的级别实现“浓厚”对于分布式应用的设计来说是一个非常重要的决定。DCOM通过让开发者甚至管理员来选择每个组件的位置来促进配置的简单性和灵活性之间的平衡。可以通过对配置的简单改动使同一个事务组件（例如数据登录检查组件）分别在服务器和客户端执行。应用能够动态地选择所使用的用户界面组件（服务器上的HTML产生器或者客户端的ActiveX控件）。 保持“肥胖的”客户的一个最大的问题是将这些客户更新到最新版本的问题。现在通过对代码下载的支持，微软的Internet Explorer 3.0提供了解决这一问题的一个非常优雅的办法。只要用户在浏览一页页面，微软的Internet Explorer就会检查页面中所使用的ActiveX控件，并在必要时自动对其进行更新。应用也可以在不明确使用浏览器的时候使用这一被微软直接支持的特性（ActiveX的CoCreateClassFromURL函数）。 在Windows NT 5.0中，代码下载的概念将被扩展到本地COM类库中。这一类库将使用扩展目录来储存组件的配置信息和到实际代码的索引，它改变了当前使用的本地登记概念。这个类库将向Intranet（扩展目录）和Internet（代码下载，Internet路径搜索）提供代码仓库，并使它们对已存在的应用完全透明。 安装和更新服务器组件通常不是一个严重的问题。然而，在一个高度分布化的应用中，同时更新所有的客户一般来说是不太可能的。如第一部分中“功能的发展：版本化”部分所述的DCOM的健壮的版本化支持允许服务器在保持向后兼容的基础上加入新的功能。服务器组件既可以处理旧客户进程，又可以处理新客户进程。一旦所有的客户都被更新，组件就可以停止对新客户所不需要的功能的支持。 使用代码下载技术以及以后它的扩展技术，类库、管理员能够有效而安全地集中安装和更新客户，并能在不用削减太多功能的情况下将“肥胖的”客户变为灵巧的客户。DCOM对于健壮性版本化的支持使得无需先更新所有客户就可以更新服务器程序。
管理安装和更新客户组件的部分工作是对这些组件的配置和对这些配置的保持。DCOM所涉及的最重要的配置信息是运行客户所需组件的服务器的消息。 使用代码下载和类库技术，我们可以在一个集中位置管理配置信息。对配置信息和安装包的一个简单改动就能够透明地更新所有的客户。 管理客户配置的另一种技术是“负载平衡”部分所描述的指示组件技术。所有客户都连接到指示组件，指示组件中包含所有的配置信息，它向每个客户返回合适的组件。只需改动指示组件就可以改变所有的客户。 一些组件，特别是服务器组件，需要附加的特殊组件配置。这些组件能够使用DCOM来显示允许改变配置和恢复现有配置的界面。开发者可以使用DCOM的安全性底层框架使得这些界面只能被有合适访问权限的管理员使用。对于加速开发过程的工具的广阔的支持使我们能够很容易地写出使用管理界面的前端界面。同样的界面可以用诸如Visual Basic Script或Java Script这样的简单剧本语言写的代码来完成自动的配置变换。 代码下载和类库技术可用于集中配置组件，而指示组件方法是一种使配置信息更加集中化的方法。某些组件可以使附加的DCOM界面只能被管理员看到并使用，这就使同样的DCOM底层结构能够被用来进行组件的配置和管理。
协议无关性许多分布式应用需要集成到一个顾客或者公司的现存的网络结构中。这时可能需要一个特殊的网络协议，而这需要更新所有潜在的客户，这在大多数情况下是不可能的。因此应用的开发者需要小心地是应用对下面的网络底层结构尽可能的保持独立性。 DCOM使得这一过程变得透明了：因为DCOM能够支持包括TCP/IP、UDP、IPX/SPX和NetBIOS在内的任何一种传输协议。DCOM提供了基于所有这些无连接和面向连接的协议的一个安全性框架。 开发者能够轻易地使用DCOM提供的特性并可以确信他们的应用系统是完全对协议无关的。
平台无关性分布式应用系统经常要把不同的平台集成到客户端以及服务器端。开发者经常要面对那些平台之间在许多方面的重要差别：不同的用户界面原理，不同的系统服务甚至是整套网络协议的不同。这一切使得使用和综合多平台变得十分困难。 这个问题的一个解决办法是所有平台重最特殊的一个并使用一个抽象层来保存基于所有平台的简单代码。这一方法被传统的跨平台开发框架系统所使用，例如Java虚拟机环境。它的实现依赖于对于所有可支持平台都适用的一个代码集甚至二进制代码。 然而，这种简单化是要付出代价的。抽象层的引入带来了额外的开支，并且不能使用与平台有关的一些强大的服务和优化。对于用户界面组件来说，这一方法意味着与别的应用在界面上相似程度会非常少，从而导致使用起来更加困难以及要花更多的钱来进行培训。对服务器组件来说，这一方法对任一平台来说牺牲了协调重要组件的执行性能的能力。 DCOM技术对于所有的跨平台开发工作都是公开的。它不排斥基于特殊平台的服务和优化，也不会专门适用于某些系统。 DCOM结构允许将平台无关性框架和虚拟机环境（Java）以及高执行性能、平台优化的顾客组件综合到一个分布式应用中。
平台二进制标准 从某一方面来说，DCOM定义了一个平台二进制标准，因此顾客和开发者可以将使用由不同卖主提供的工具开发的组件互相混合和匹配起来，甚至可以在不同的DCOM运行库中使用它们。虽然DCOM运行库的细节可能随着完成时间的不同而改变，但是运行库和组件以及组件之间的相互作用是标准化的。与其它更加抽象的对象摸型不同，使用DCOM可以将一个二进制版本的组件分布到一个运行着所有其它组件和运行库的平台上去。
（下一篇）
