application
组件负载平衡应用
下面的说明可使 CLB 得到迅速应用。这些说明假设将用 stager 来将内容部署到 Web 层和 COM+ 群集上。并假定您掌握了有关 Visual Basic、ASP 和 HTML 的实际使用知识。
- 在 stager 上使用 Visual Basic，创建一个导出以下函数的 COM+ 组件。
Public Function GetName() As String
Set WS = CreateObject("wscript.network")
GetName = WS.Computername
Set WS=nothing
End Function - 使用 COM+ Services Explorer 将组件打包进 COM+ 应用程序中。
- 在 stager 上，创建包括 COM+ 组件的 Application Center 应用程序。
- 将 COM+ 组件部署到 COM+ 群集。切记在部署向导中选中 Deploy COM+ applications，否则将不部署组件。
- 用下面的脚本创建一个名为 Default.asp 的 ASP 文件。
<script language=vbscript runat="server">
for n=1 to 50
set x=createobject ("YourComponent.YourClass")
Response.Write "Component created on: "
Response.Write x.GetName
Response.write "
"
set x=nothing
next
</script> - 用在第 1 步中创建的组件的 ProgID 替换 ProgID "YourComponent.YourClass"。
- 在 stager 上创建一个 Application Center 应用程序（包括第 5 步中的 Default.asp 文件和第 1 步中的 COM+ 组件）。
- 将应用程序部署到 Web 层群集。
- 确保 Web 层路由列表已经建立，COM+ 组件已标记为支持负载平衡。
- 从客户机上运行 Default.asp。如果一开始不工作，可能是 IIS Service 在组件部署期间被重启动的结果。请稍候片刻再重试。
如果重试成功，您将看到一个用来创建组件实例的 COM+ 群集成员的列表。
何时使用 CLB
CLB 是用于建立分布式解决方案的一项绝妙的技术。但有些时候，CLB 或许不是最好的解决方案。关键问题是性能、可伸缩性和安全性。理解这些问题将有助于建立更好的群集拓扑。
性能
无论一个 Web 站点多么吸引人，功能多么强大，如果用户从站点得不到令人满意的性能，这个站点就不会获得成功。有两个问题很重要：
- 吞吐量 — Web 站点所完成的工作。
- 响应时间 — 给用户提供反馈所需的时间。
两者是相互关联的，CLB 也有些问题与它们有关。
吞吐量
当通过网络进行任何类型的调用时，吞吐量性能将有所下降。使用 CLB 会明显导致这一现象，所以在决定群集体系结构时需要考虑这个问题。为了进一步阐述该问题，下面的数据显示了每秒钟对一个单线程 Visual Basic 6 COM 组件（该组件以字符串属性返回“Hello, world”）的调用次数。客户机早已超前绑定，且不在对检索属性的调用之间发布引用。 方案
每秒钟的调用次数
相对速度
COM+ Server Application，运行在 10BaseT 网络上
625
1.0x
COM+ Server Application，Out Proc，同一计算机
1923
3.08x
COM+ Library Application，In Proc，同一计算机
3333
5.33x
显然，通过网络进行的调用所产生的吞吐量，要低于调用同一台计算机上的软件所产生的吞吐量。在所有的软件通讯中，无论是否通过 Microsoft 的软件，都会发生同样的情况。因此，在吞吐量非常关键的地方，CLB 没有提出好的解决方案。这种情况下，最好将 COM+ 组件本地安装在 Web 层群集成员上，这样可以避免网络间的调用。虽然丧失了 CLB 支持，但仍可以通过 NLB 提供负载平衡。
file:///F:/My%20Work/技术文档/服务器群设置/Microsoft%20Application%20Center%202000%20组件负载平衡技术概述.files/CLBOVR05.gif
图 5 Web 层上的 COM+ 组件
响应时间
确保用户在访问 Web 站点时得到快速响应显然很重要，而 Web 站点的体系结构对响应时间的影响是很大的。运行在 Web 层群集上的 COM+ 组件可能执行一些明显降低 Web 站点的响应性能的操作。如果对于非 COM+ 组件的工作来说，响应时间的重要性大于组件吞吐量的重要性，那么有一个解决方案，就是将 COM+ 组件转移到一个 COM+ 群集层。这将减轻 Web 层群集的工作量，以便改进未使用 COM+ 组件的客户机的服务时间。例如，访问静态 Web 页的客户机。显然，当要求 COM+ 组件工作时，看不到响应时间的改进。实际上，性能很可能由于将发生穿越网络的调用而下降。另一个方法是将路由列表移到独立的 COM+ 路由群集上。这样做连 Web 层的工作量也减轻了，因为其上将不发生任何 CLB 特有的工作。此外，这虽然有利于 Web 层上的非 COM+ 组件工作，但因为有网间调用，所以会导致 COM+ 组件的性能进一步下降。
显然，高性能和 CLB 未必兼得，Web 站点设计人员必须知道这些局限性。
易管理性
使用独立的 COM+ 群集有助于提高易管理性。这使得 Web 站点的 COM+ 组件和 IP 请求能够被轻松、独立地管理。例如，许多组织把它们的 COM+ 组件放在位于不同物理位置的服务器上。使用独立的 COM+ 群集能够实现对群集的独立管理。此外，可以让多个 Web 层群集共享一个 COM+ 群集，反之亦然。
安全性
CLB 的一个常见用途是增强 Web 站点的安全性。当用作访问数据的手段时，COM+ 组件可以使用自己的基于角色的（或以编程方式实现的）安全机制来保护数据。如果组件位于 Web 层群集，这种安全机制很可能会受到危害。Web 层群集收到的调用可能来自一台不可信任的客户机，该客户机试图非法利用安装在群集成员上的 COM+ 组件。CLB 可以避免这种问题，方法是将 COM+ 组件从 Web 层群集转移到 COM+ 群集。COM+ 群集通常由防火墙（图 6 中的防火墙 B）保护，它只允许来自 Web 层群集内部的调用创建组件，而不允许来自客户机的调用创建组件。图 6 还显示了一个非军事化区 (DMZ)，通过两道防火墙来保护 Web 层。
file:///F:/My%20Work/技术文档/服务器群设置/Microsoft%20Application%20Center%202000%20组件负载平衡技术概述.files/CLBOVR06.gif
图 6 防火墙后面的 COM+ 群集
小结
CLB 是一项用来建立分布式解决方案的绝妙技术，然而在使用它时必须谨慎。在使用它时吞吐量性能会受到负面影响，但是其它一些优点，如安全性、可伸缩性、易于设置、负载平衡等，决定了它仍然不失为一种重要的工具。合理地使用 CLB 将有助于制定出很好的基于 .NET 的解决方案。
资源
http://www.Microsoft.com/ApplicationCenter — 有关 Application Center 的最新信息。
Microsoft Application Center 2000 Resource Kit — 含有对 Application Center 的深入探讨。给出了有关 CLB 的进一步信息，尤其是部署方案。不久即可供使用。
http://www.microsoft.com/com — 有关 COM 和 COM+ 的信息。
http://www.microsoft.com/net — 有关 .NET 的权威信息。
http://www.microsoft.com/windows2000/library/howitworks/cluster/nlb.asp — 有关网络负载平衡的详细信息。
本白皮书是一份初稿，在最终的商业版本之前可能会作重大改动。本文档仅供参考，Microsoft 在本文档中未作任何明示的或默示的担保。本文档中的信息可能在未经通知的情况下加以改动。使用本文档带来的风险和后果由用户自己负责。本文作为例子提到的公司、组织、产品、人和事件均是虚构的。决不意指任何实际的公司、机构、产品、人员和事件。遵守所有适用的版权法律是用户的责任。在不对版权法所规定的权利加以限制的情况下，未经 Microsoft Corporation 的书面明确许可，不得将本文的任何部分复制、存储或引入到检索系统，或以任何形式或手段（电子、机械、影印、录制等）、或出于任何目的，转发本文的任何部分。
