设计服务器环境中的可伸缩性

可伸缩性是 Web 管理员关心的问题，因为他们必须确保他们的 Web 平台可以处理稳定的通信增长以及预料不到的通信量。如果软件和硬件都不能缩放，那么连接到该服务器的客户端会遇到错误或问题。IIS 是可缩放的，虽然硬件配置和自定义应用程序可能会削弱该软件。

本主题介绍了如何设计 Web 服务器环境的可伸缩性，以便 IIS 服务器能根据您的需要最佳地运行。

Web 服务器的可伸缩性取决于 Web 服务器环境中可伸缩性最差的部分；如果一个部件发生故障，那么整个 Web 服务器环境的可伸缩性都会受到影响。Web 服务器环境中的可伸缩性只有在可伸缩性被设计应用到系统的每一个部件的情况下才能实现。服务器环境，包括硬件、软件、Internet 服务器 API (ISAPI) 筛选器、自定义组件以及应用程序都必须是可缩放的。因此，改善可伸缩性要求长期的评估、计划以及严格的测试。

通常，管理员无法独立构建可缩放的 Web 平台和基础结构；他们必须与设计人员和管理人员在各个环节（从概念到生产）进行合作。如何进行缩放以及选择缩放的方法在很大程度上取决于 Web 平台的目标、预算，以及公司的体系结构原则。

本节包括下列信息，从较高的层次介绍了在系统中设计可缩放性的要求：

• 为 Web 平台定义长期的目标
• 了解您的用户
• 定义设计目标并优先考虑可伸缩性
• 测试服务器环境、客户端连接和应用程序
• 始终打开通信线路

为 Web 平台定义长期的目标

Web 平台的长期目标很可能由企业的性质来决定。例如，Internet 服务提供商 (ISP) 希望在一台服务器上容纳尽可能多的站点同时又要以最小的服务器管理来维护优良的性能。而电子商务站点通常希望通过安全的连接对金融事务进行快速、高效的处理。如果要为 Intranet 使用 IIS，您的长期目标可能是将所有的人力资源福利和薪水表单都放到网上。定义目标可以帮助您确定如何构建基础结构。

了解您的用户

确定用户想要什么以及他们如何访问站点上的产品和服务。例如，用户是通过 T1 连接还是通过 56K 调制解调器访问您的站点？如果站点上提供的产品和服务需要大量的带宽才能够正常查看或体验，那么您可能无法应付大量潜在的用户。此外，向拨号调制解调器发送大型图像文件或音乐文件也会损坏您的系统对于其他用户的性能和可伸缩性。您的站点应该使那些使用拨号调制解调器连接的用户仍能顺利访问。

定义设计目标并优先考虑可伸缩性

请确保参与您的 Web 平台开发的各方都理解应将可伸缩性设计应用到服务器环境的各个部分。制定冗余计划，并考虑按照下面的原则设计服务器环境：

• 与代码基中频繁使用的功能保持一致。
• 使配置简单。
• 请确保您的站点的功能是可配置的，以使功能在破坏可伸缩性和性能的情况下可以删除。
• 最大限度地减少中间层和后端之间的往返次数。
• 最大限度地减少客户端与服务器之间的往返次数。
• 优化数据流。
• 考虑使用分布式体系结构和分布式应用程序。
• 确定关键的组件并确保这些组件对于您定义的目标是可缩放的。
• 考虑使用脱机处理。
• 使特定的错误事件在各个功能之间是一致的；即，对于需要类似解决办法的问题使用相同的错误代码。
• 为绘制、编写、成员资格和通知定义标准。
• 使用已经存在的服务。

测试服务器环境、客户端连接和应用程序

为了测试服务器，请考虑使用下面建议的做法：

• 用比您预期的服务器连接多得多的大量连接测试服务器。
• 了解服务器在负载状况下的运行性能如何。
• 了解性能何时开始降低。
• 了解可以采取何种措施以防止服务器出现故障。
• 在准备产品服务器时，执行跨平台的脚本安装，以确保一致性并同时降低人工成本。

也可以通过检查 IIS 生成的日志来监视服务器。这些日志扩展了 Microsoft Windows® Server 2003 家族生成的日志。

此外，应执行客户端测试，以验证站点是否按照设计的那样运行。

最后，一定要测试应用程序的可伸缩性。任何应用程序（托管的 Microsoft ASP.NET 或未托管的 ISAPI）都可能会有设计缺陷，造成可伸缩性问题。如果通过测试判定某应用程序降低了性能或可伸缩性，您可能需要删除或重新设计该应用程序。

始终打开通信线路

应该与设计人员和测试人员一起维护通信，以便进行有效的故障排解。管理员需要知道何时用硬件或软件对重新设计的站点功能进行缩放。

© 1997-2003 Microsoft Corporation。保留所有权利。