📄 dcom实现分布式应用（五）.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0040)http://www.vckbase.com/article/atl/7.htm -->
<HTML><HEAD><TITLE>DCOM实现分布式应用（五）</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV align=center>
<CENTER></CENTER></DIV>
<DIV align=center>
<CENTER>
<DIV align=center>
<P><FONT color=#009933><B>DCOM实现分布式应用（五）</B></FONT></P>
<P align=left>负载平衡
<BR>一个分布式应用系统越成功，由于用户数量的增长而给应用系统中的所有组件带来的负载就越高。一个经常出现的情况是即使是最快的硬件的计算能力也无法满足用户的需求。
这一问题的一个无法必免的解决方案是将负载分布到多个服务器中去。在“可扩展性”部分简要地提到了DCOM怎样促进负载平衡的几种不同的技术：并行配置，分离关键组件和连续进程的pipelining技术。
“负载平衡”是一个经常被使用的名词，它描叙了一整套相关技术。DCOM并没有透明地提供各种意义上的负载平衡，但是它使得完成各种方式的负载平衡变得容易起来。
<BR><BR>静态负载平衡<BR>解决负载平衡的一个方法是不断地将某些用户分配到运行同一应用的某些服务器上。因为这种分配不随网络状况以及其它因素的变化而变化，所以这种方法称为静态负载平衡。
基于DCOM的应用可以很容易地通过改变登记入口将其配置到某些特定的服务器上运行。顾客登记工具可以使用Win32的远程登记函数来改变每一个客户的设置。在Windows
NT 5.0中，DCOM可以使用扩展的目录服务来完成对分布的类的储存，这使得将这些配置改变集中化成为可能。 在Windows NT
4.0中，应用系统可以使用一些简单的技术达到同样的效果。一个基本的方法是将服务器的名字存到诸如数据库和一个小文件这样的众所周知的集中环境中。当组件想要和服务器相连接时，它就能很轻易地获得服务器的名字。对数据库或文件内容的改动也就同时改变了所有的用户以及有关的用户组。
一个灵活得多的方法使用了一个精致复杂的指示组件。这个组件驻留在一台为大家所共知的服务器中。客户组件首先和此组件连接，请求一个指向它所需服务的索引。指示组件能够使用DCOM的安全性机制来对发出请求的用户进行确认，并根据发出请求者的身份选择服务器。指示组件并不直接返回服务器名，它实际上建立了一个到服务器的连接并将此连接直接传递给客户。然后DCOM透明地将服务器和客户连接起来，这时指示组件的工作就完成了。我们还可以通过在指示组件上建立一个顾客类代理店之类的东西而将以上机制对客户完全屏蔽起来。
当用户需求增加时，管理员可以通过改变组件而为不同的用户透明地选择不同的服务器。此时客户组件没有做任何改动，而应用可以从一个非集中式管理的模式变为一个集中式管理的模式。DCOM的位置独立性以及它对有效的指示的支持使得这种设计的灵活性成为可能。
<BR><BR>动态负载平衡<BR>静态负载平衡方法是解决不断增长的用户需求的一个好方法，但它需要管理员的介入，并且只有在负载可预测时才能很好地工作。
指示组件的思想能够提供更加巧妙的负载平衡方法。指示组件不仅可以基于用户ID来选择服务器，它还可以利用有关服务器负载、客户和可用服务器之间的网络拓朴结构以及某个给定用户过去需求量的统计数字来选择服务器。每当一个客户连接一个组件时，指示组件将其分配给当时最合适的可用的服务器。当然，从客户的观点看来，这一切都是透明发生的。这种方法叫做动态负载平衡法。
对某些应用来说，连接时的动态负载平衡法可能仍然是不充分的。客户不能被长时间中断，或者用户之间的负载分布不均衡。DCOM本身并没有提供对这种动态重连接以及动态的方法分布化的支持，因为这样做需要对客户进程和组件之间相互作用的情况非常熟悉才行，此时组件在方法激活过程中保留了一些客户的特殊的状态信息。如果此时DCOM突然将客户和在另一台机器上的另一个不同的组件再连接，那么这些信息就丢失了。
然而，DCOM使得应用系统的设计者能够很容易地将这种逻辑结构清楚地引入到客户和组件之间的协议中来。客户和组件能够使用特殊的界面来决定什么时候一个连接可以被安全地经过再寻径接到另一台服务器上而不丢失任何重要的状态信息。从这一点看来，无论是客户还是组件都可以在下一个方法激活前初始化一个到另一台机器上的另一个组件的再连接。DCOM提供了用来完成这些附加的面向特殊应用的协议的所有的丰富的协议扩展机制。
DCOM结构也允许将面向特殊组件的代码放到客户进程中。无论什么时候客户进程要激活一个方法时，由真实组件组件所提供的代理组件在客户进程中截取这一调用，并能够将其再寻径到另一台服务器上。而客户根本无需了解这一过程，DCOM提供了灵活的机制来透明的建立这些“分布式组件”。
有了以上独特的特性，DCOM使得开发用来处理负载平衡和动态方法寻径的一般底层结构成为可能。这种底层结构能够定义一套标准界面，它可以用来在客户进程和组件之间传递状态信息的出现和消失情况。一旦组件位于客户端的部分发现状态信息消失，它就能动态地将客户重连接到另一台服务器上。
<BR><BR>例子：微软的事务服务器（以前叫做“Viper”）使用这一机制来扩展了DCOM编程模型。通过一套简单的标准状态信息管理界面，事务服务器能够获得必要的信息来提供高级别的负载平衡。在这种新的编程模型中，客户和组件之间的相互作用被捆绑到事务中，它能够指出什么时候一系列的方法调用所涉及的组件的状态信息都是清楚的。<BR><BR>DCOM提供了一个用来完成动态负载平衡的强大的底层结构。简单的指示组件在连接时可以用来透明地完成动态服务器分配工作。用来将单一的方法调用再寻径到不同的服务器的更尖端的机制也能够轻易地完成，但是它需要对客户进程和组件之间的相互作用过程有更为深入的了解。微软的完全基于DCOM建立的事务服务器（“Viper”）提供了一个标准的编程模型用来向事务服务器的底层结构传递面向这一附加的特殊应用的有关细节问题，它可以用来执行非常高级的静态和动态的重配置与负载平衡。
<BR><BR>容错性<BR>容错性对于需要高可靠性的面向关键任务的应用系统来说是非常重要的。对于错误的恢复能立通常是是通过一定量的硬件、操作系统以及应用系统的软件机制来实现的。
DCOM在协议级提供了对容错性的一般支持。前面的“应用系统间的共享式连接管理”部分所描叙的一种高级pinging机制能够发现网络以及客户端的硬件错误。如果网络能够在要求的时间间隔内恢复，DCOM就能自动地重新建立连接。
DCOM使实现容错性变得容易起来。一种技术就是上一部分所说的指示组件的技术。当客户进程发现一个组件出错时，它重新连接到建立第一个连接的那个指示组件。指示组件内有哪些服务器不再有效的消息，并能提供在另一台机器上运行的这一组件的一个新的实例。当然，在这种情况下应用系统仍然需要在高级别上（一致性以及消息丢失问题等）处理错误的恢复问题。
因为DCOM可以将一个组件分别放到服务器方和客户方，所以可以对用户完全透明地实现组件的连接和重连接以及一致性问题。 <BR><BR><IMG
height=292 src="DCOM实现分布式应用（五）.files/dcompic15.gif" width=517 border=0>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -