上下文
您已经决定在设计或修改基础结构层时使用群集，以便在能够适应不断变化的要求的同时保持良好的性能。
问题
在保持可接受的性能级别的同时，如何设计一个可适应负载变化的、可伸缩的基础结构层？
影响因素
在设计可伸缩的基础结构层时，请考虑下列影响因素：
- 对于任何指定的应用程序来说，单独的服务器会受到最大负载容量的限制。例如，如果单台服务器将 Web 页作为基于 Web 的应用程序的一部分提供给用户，而且用户或事务负载增加并超过了服务器的限制，则应用程序性能将降至预期值以下，在最坏的情况下还会变得不可用。
- 单独的服务器具有最大物理性能限制，包括总线速度、内存量、处理器数和任一服务器可以使用的外围设备数等限制。例如，如果服务器只能容纳四个处理器，则不能为了提高性能而添加第五个处理器。
- 某些应用程序对于可以使用的 CPU 数有限制。
- 服务器作为单独的实体，在解决方案中是故障单点。如果只有一台服务器负责在应用程序内传递组件的功能，则它的故障会导致应用程序运行失败。
- 添加服务器会增加管理和监视服务器硬件及其关联软件的复杂性。
解决方案
将 服务或应用程序安装到多台服务器上，并将这些服务器配置为共享工作负荷。这种类型的配置就是 Load-Balanced Cluster。负载平衡通过将客户端请求分散在多台服务器上，从而提高了基于服务器的程序（如 Web 服务器）的性能。负载平衡技术（通常称为"负载平衡器"）可以接收传入请求，并根据需要将它们重定向到特定主机。有负载平衡功能的主机能够同时响应不同客 户端请求，甚至是来自同一客户端的多个请求。例如，Web 浏览器有可能从群集中的不同主机获得单个 Web 页所包含的多个图像。这就分散了负载，加快了处理速度，并缩短了对客户端的响应时间。
负载平衡器使用不同的算法控制通信流量。这些算法用于以智能方式分散负载，并/或最大限度地利用群集内的所有服务器。这些算法中的一部分示例包括：
- 循环法。循环算法将负载均衡地分配给每台服务器，而不考虑当前的连接数或响应时间。循环法适合于群集中的服务器具有相同处理能力的情况；否则，一些服务器收到的请求可能会超过它们的处理能力，而其他服务器的处理能力则有富余。
- 加权循环法。加权循环算法适合于每台服务器具有不同处理能力的情况。管理员将性能权值手动分配给每台服务器，而且按照服务器权值自动生成调度序列。然后，系统按照循环调度序列将请求定向到不同的服务器。
- 最少连接。最少连接算法根据群集中哪台服务器当前正在处理的连接数最少，从而将请求发送给该服务器。
- 基于负载。基于负载算法先判断群集中哪台服务器当前的负载最低，然后将请求发送给该服务器。
此外，一些负载平衡器还具有故障检测功能。平衡器可以跟踪服务器或在服务器上运行的应用程序，并在出现服务器故障后停止向该服务器发送请求。图 1 显示负载平衡的基本组件。
图 1:负载平衡组件
当 负载平衡器收到来自客户端的请求时，群集组中的一台服务器将处理该请求。每台服务器都能够独立地处理请求。如果任何服务器因出现错误或正在维护而不可用， 其他服务器仍然可以为请求提供服务而不会受到影响。因此，服务的总体可用性比由单台服务器处理所有请求的方案要高得多。但是，如果在一组软件负载平衡服务 器前面使用单个物理负载平衡器或单个网络交换机，将会引入另一个故障单点。可以使用冗余负载平衡设备和/或交换机来减少这类风险。
会话状态管理
在 完整的用例中，应用程序通常需要在各个步骤之间与用户交互。在用户实现其目标的过程中，他们在交互时所作的每个响应会影响可供用户使用的选项和应用程序的 状态。术语"会话状态"通常用于描述这种以用例为中心的状态。此会话状态的一部分仅仅用于跟踪任务的进度，并在使用结束后丢弃该部分；如果用例成功结束， 则将会话状态的其他部分保存在数据库中进行长期存储。例如，在使用联机购物车的用户选择结帐按钮（购物车中至少有一个项目时，才会启用该按钮）之前，很少 要求该用户提供支付或运送信息。
分布式应用程序通常通过网络连接调用远程服务器上的软件组件。应用程序必须跟踪在各步骤之间会话状态发生的更改，以提供它们之间的连续性。应用程序设计人员通常在以下三个基本位置中的某一个维护会话状态：
- 客户端。应用程序设计人员将每个用户的会话状态存储在用户的计算机上。
- 中间服务器。应用程序设计人员将会话状态存储在一台在客户端计算机与永久存储用户信息的数据库服务器之间作为中介的计算机上。
- 数据库服务器。应用程序设计人员将会话状态与其他长期应用程序和用户数据一起存储在数据库服务器中。
只 有中间服务器方法影响此模式。每种方法及其优缺点在 Designing for Scalability with Microsoft Windows DNA [Sundblad00] 的第 2 章"Designing for Scalability"中有详细说明。
如 果所有服务器都是无状态的（就是说，在服务器处理请求后，服务器的状态将还原为默认值），一个简单的解决方案（如图 1 中所示的解决方案）就足够了。在两种情况下服务器可以是无状态的。其一，客户端不需要会话；也就是说，每个请求都是单独的工作单元，并且在请求之间没有持 续存在的临时值。其二（称为"客户端会话管理"），客户端本身将保存会话的状态，并在请求内发送会话状态信息，以便任何服务器都可以检查到请求，并继续处 理它。
在服务器会话管理方案中，服务器负责维护用户会话的状态。服务器会话管理要求负载平衡器将同一个用户会话内来自一个客户端的所有请求定向到同一个服务器实例。此机制通常称为"服务器关系"。
会 话管理本身的一个问题是：如果服务器因出现错误或进行维护而脱机，则可能会丢失客户端的工作，而且客户端必须重新发送丢失的会话中已经发送的所有请求。在 某些情况下，偶然丢失会话对用户来说不是大问题。例如，在联机地图搜索应用程序中，如果服务器丢失用户刚键入的地址，用户重新键入该地址不会是一件太麻烦 的事情。但是，在其他情况下，会话丢失可能是极其不便的。例如，在具有无状态客户端的联机租用应用程序中，用户可能要花费 10 分钟的时间才能将几页有价值的信息键入到合约表格中。如果负载平衡组中的一台服务器脱机，您当然不希望用户再花费 10 分钟重新键入所有信息。为避免因负载平衡组中的服务器出现故障而导致的会话丢失，可以使用以下两种方法：集中式状态管理和异步会话状态管理。图 2 显示集中式状态管理。
图 2:负载平衡和集中式状态管理
集 中式状态管理方法将会话状态信息存储在一台与应用程序服务器处于不同层的集中式服务器上。应用程序服务器每次收到作为会话一部分的请求时，它先从会话管理 服务器提取会话状态，然后处理该请求。会话管理服务可以是运行在存储了共享资源并且具有高可靠性配置的服务器上的数据库或另一类型的应用程序。有关如何改 进共享资源上的容错的详细信息，请参阅 Failover Cluster 模式。
图 3 显示异步会话状态管理。
图 3:负载平衡和异步会话状态管理
使 用异步会话状态管理方法时，每台服务器只要发生会话状态更改，就会将其会话状态广播给所有其他服务器；因此，每台服务器都包含所有会话的状态信息，而且任 何服务器都可以处理包含在会话中的请求。会话状态还会在单独的服务器出现故障之后继续存在。因为不需要额外的设备，所以此解决方案更经济；但是，因为它涉 及异步调用，所以其配置和维护更困难。在每台服务器上存储所有会话的状态还会导致效率更低。
实现
负载平衡实现的两种主要类别是：
- 基于软件的负载平衡。基 于软件的负载平衡包括在负载平衡群集中安装在服务器上的特殊软件。软件根据不同的算法分派或接受客户端向服务器发出的请求。算法可以是简单的循环算法，也 可以是考虑服务器关系的更复杂的算法。例如，Microsoft® Network Load Balancing 是用于 Web 场的负载平衡软件，而 Microsoft Component Load Balancing 是用于应用程序场的负载平衡软件。
- 基于硬件的负载平衡。基于硬件的负载平衡是由以软件为其提供负载平衡功能的专用交换机或路由器组成的。此解决方案将交换功能和负载平衡功能集成到单个设备中，从而减少了实现负载平衡所需的额外硬件数量。但是，将这两项功能组合在一起，也会使设备的故障排除工作变得更困难。
示例
为了帮助您更好地了解如何使用负载平衡实现可伸缩性，下面的讨论将现有的非负载平衡解决方案（该方案在应用程序层中包含单个系统，即故障单点）与保持性能并提供可用性的高伸缩解决方案进行比较。
非负载平衡层
一开始，组织可能采用类似于图 4 中所描述的解决方案体系结构，该体系结构可能满足最初的性能要求。但是，随着负载的增加，应用程序层必须适应增加的负载，才能保持可接受的性能。
图 4:具有单台应用程序服务器的基本解决方案
在图 4 中，应用程序层只包含一台为客户端请求提供服务的应用程序服务器 (AppServer20)。如果该服务器超载，则解决方案的性能将降至不可接受的级别，或变得不可用。
负载平衡层
要提高可伸缩性并保持性能，组织可能会使用负载平衡器来扩展应用程序层。在下面的示例（如图 5 所示）中，将两台服务器添加到应用程序层以创建负载平衡群集，该群集将访问数据层数据，并为客户端层中的客户端提供对应用程序的访问服务。
图 5:具有可伸缩应用程序层的解决方案
这 将得到一个标准的负载平衡设计。硬件设备或运行在主机上的软件将虚拟主机名 (AppServer20) 和 IP 地址分配给 AppServer1、AppServer2 和 AppServer3。负载平衡的群集向网络公开此虚拟 IP 地址和主机名，并在组内的正常运行服务器之间均衡地分配传入请求的负载。如果 AppServer1 出现故障，则只需将请求定向到 AppServer2 或 AppServer3 即可。取决于提供此功能的技术，可以将一定数目的额外服务器添加到负载平衡的群集中，以最大限度地提高可伸缩性，并超前满足不断增长的需求。
结果上下文
Load-Balanced Cluster 模式具有下列优缺点：
优点
- 改进的可伸缩性。可伸缩的负载平衡层使系统可以在提高可用性的同时保持可接受的性能级别。
- 更高的可用性。通过负载平衡，可以使服务器脱机进行维护，而不会让应用程序不可用。
- 可能会降低成本。与更高成本的多处理器系统相比，多台低成本服务器通常会降低成本。
缺点
- 开发过程复杂。如果解决方案必须维护各个事务或用户的状态，则开发负载平衡的解决方案会是很困难的。
没有解决网络故障问题。如果在客户端会话过程中服务器或网络出现故障，则可能需要重新登录才能重新验证客户端和重新建立会话状态。