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使得开发用来处理负载平衡和动态方法寻径的一般底层结构成为可能。这种底层结构能够定义一套标准界面，它可以用来在客户进程和组件之间传递状态信息的出现和消失情况。一旦组件位于客户端的部分发现状态信息消失，它就能动态地将客户重连接到另一台服务器上。
