ASP.NET 3.5企业级项目开发 第一章(续)：企业级项目框架解决方案的提出
| 不经过特殊化和优化，回报会相当少。
特殊化允许您根据需要分配一 些较小的应用程序片段。例如，如果您分离了图像服务器，则可以独立于应用程序的其余部分轻松扩展图 像服务。 优化还可以减少执行指定操作时所需的工作量，为分配提供回报。这将会减少扩展到相 同数量的用户所需的服务器数量。 负载平衡 要实施分配，需要添加服务器、在各服务器间复制应用程序以及实施负载平衡。为使 负载平衡，您可以使用“网络负载平衡”(NLB)，所有版本的 Windows Server® 2003 都 带有此服务。有了 NLB，在负载平衡关系中每个服务器都是平等的伙伴关系。它们都使用相同的平衡算法 ，并且它们都侦听所有流量的共享虚拟 IP 地址。根据负载平衡算法，每个服务器都知道应由哪一个服务 器来处理给定的请求。群集中的每个服务器都会发出一个检测信号，以使其他服务器知道自己正处于活动 状态。如果服务器发生故障，该服务器的检测信号将会停止，其他服务器会自动进行补偿。 如果 有大量用户提出相似的请求，这时 NLB 会非常适用。但是，如果某些请求产生的负载要比其他请求多很 多，则补偿机制也不能解决问题。幸运的是，对这种情况可采用硬件负载平衡解决方案。 相似性 从根本上讲，有效地进行分配所面临的主要问题是如何消除相似性。例如，如果您只有一个 Web 服务器，则将会话数据存储在其中是合情合理的。但是，如果您有多个 Web 服务器，那么应将会话信息 存储在哪里呢？ 一种方法是将其保留在一个 Web 服务器上，然后使用相似性。实质上，这意味着 来自给定用户的第一个请求是处于负载平衡状态的，之后，来自该用户/会话的所有后续请求都与第一个 请求一样被发送到同一个服务器。这是一种简单的方法，每个负载平衡解决方案都支持这种方法，在某些 情况下它会更合理一些。 但从长远来看，相似性会带来麻烦。使会话数据保留在进程中可能会加 快速度，但如果回收 ASP.NET 工作进程，则所有这些会话都将处于无效状态。在很多情况下都需要回收 工作进程。在负载过高时，IIS 可能会回收 ASP.NET 的工作进程，因为它认为该进程出现了问题。实际 上，在 IIS 6.0 中，默认情况下会每隔 23 小时回收一次工作进程。您可以对此进行调整，但无论如何 ，用户都可能会丢失进程中的会话数据。如果站点规模较小，这不算是个大问题，但随着站点变得越来越 大、越来越繁忙，此问题就会变得愈发突出。还有更多其他情况。 如果您是按 IP 地址进行负载 平衡的，则一个服务器可能会成为 megaproxy 代理（如 AOL）的目标，导致无法支持其自身的整个负载 。而且，将服务器更新为新版本的应用程序会变得越来越困难；您或者必须等待数小时以便让用户退出站 点，或者冒着激怒这些用户的风险将其挤出会话。您的可信赖性将大打折扣：不仅丢失了服务器，还丢失 了许多会话。 消除相似性是主要的分配目标。这需要将会话状态数据移出进程，而这意味着通过 牺牲性能来增加可伸缩性。将会话移出进程后，会话数据将被记录在所有 Web 服务器都可以访问的位置 （例如 SQL Server® 服务器或 ASP.NET 状态服务器上）。这是在 web.config 中进行配置的。 要支持进程外会话还需要进行一些编码工作。将要存储在 Session 对象中的任何类都必须标有 Serializable 属性。这表示该类中的所有数据都必须是可序列化的或标有 NonSerialized 的，以便可以 将其忽略。如果未对类进行标记，则在运行序列化程序以将会话数据存储在进程外时会出现错误。 最后，如果发现会话对象中的数据过多，则将会话移出进程是一个非常好的方法，因为现在对于 每个页面请求，都需要付出代价将大量数据跨越整个网络传送两次（一次是在页面开头检索数据，一次是 在页面结尾返回数据）。 确定了 S |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
