在当今企业级应用部署中，服务的连续性与可靠性是衡量IT架构成熟度的核心指标。对于许多依赖Windows Server生态的团队而言，面对关键业务系统，如何构建一套既能抵御单点故障，又能灵活扩展的Web服务架构，是一个既现实又颇具挑战的课题。Linux世界有Nginx、HAProxy、Keepalived等成熟方案，而在Windows平台上，微软同样提供了强大的原生工具链，其中网络负载均衡（Network Load Balancing, NLB） 与 应用程序请求路由（Application Request Routing, ARR） 的组合，便是构建高可用、可伸缩Web服务的“黄金搭档”。
这套方案的精妙之处在于其层次化的设计思想：NLB工作在传输层（第4层），负责在多个服务器节点间分发网络流量，提供基础的高可用性保障；而ARR则工作在应用层（第7层），能够理解HTTP/HTTPS协议，基于URL、主机头、Cookie等丰富信息进行智能路由，并管理后端服务器农场（Server Farm）的健康状态。两者协同，既能解决服务器硬件或操作系统层面的故障转移（NLB的职责），又能处理应用程序（如IIS站点、.NET应用）自身无响应但服务器仍在运行的问题（ARR的职责），从而实现从基础设施到应用服务的全方位保护。
本文旨在为有一定Windows Server和IIS管理经验的IT运维人员、系统架构师，提供一份从原理到实战的深度指南。我们将不仅一步步搭建环境，更会深入探讨其协同工作机制、配置逻辑、性能调优以及故障排查，帮助你构建一个真正稳定、可靠且易于维护的Windows高可用Web架构。
在动手配置之前，我们必须先厘清NLB和ARR各自扮演的角色以及它们如何协同工作。这绝非简单的功能堆叠，而是一种经过深思熟虑的架构分层。
网络负载均衡（NLB） 是Windows Server的一项内置功能。它通过创建一个虚拟IP地址（VIP）对外提供服务，并将传入的网络请求（通常是TCP/UDP流量）分发到集群中的多台物理或虚拟服务器上。NLB工作在OSI模型的第4层（传输层），这意味着它主要基于IP地址和端口号进行决策。其核心价值在于：
- 高可用性：当集群中某台节点服务器发生故障（如蓝屏、断电、网络中断），NLB能在数秒内检测到并将其从活动节点中移除，流量将自动导向其他健康节点，实现快速故障转移。
- 可伸缩性：可以通过向集群中添加更多服务器来水平扩展处理能力，以应对增长的流量。
- 无单点故障：NLB本身可以配置为多播或单播模式，结合多台服务器，消除了入口层的单点故障。
然而，NLB有一个显著的局限性：它通常只能检测到服务器节点是否在线（通过心跳检测），但无法感知运行在该服务器上的特定应用程序（如某个IIS网站）是否健康。如果IIS工作进程崩溃但服务器操作系统依然运行，NLB会继续将请求分发到这台“僵尸”服务器，导致用户请求失败。
这正是 应用程序请求路由（ARR） 大显身手的地方。ARR是IIS的一个扩展模块，本质上是一个基于IIS的反向代理和负载均衡器。它工作在OSI模型的第7层（应用层），能够深度解析HTTP/HTTPS请求。ARR的核心能力包括：
- 应用层健康检查：ARR可以定期向后端服务器发送特定的HTTP请求（如
GET /healthcheck.aspx），根据响应状态码和内容来判断应用服务是否真正健康。 - 智能路由：可以根据HTTP请求头（如主机名、URL路径、Cookie、客户端IP等）将请求路由到不同的后端服务器或服务器组。
- 服务器农场管理：轻松地添加、移除后端服务器，并设置每台服务器的权重。
- 响应缓存与压缩：可以缓存静态内容，甚至动态内容，并实施压缩，减轻后端服务器压力，提升响应速度。
那么，NLB和ARR如何协同？典型的部署架构是一个两层负载均衡模型：
- 第一层（NLB层）：由两台或多台安装了IIS和ARR的服务器组成一个NLB集群。它们共享一个虚拟IP（VIP）。外部用户和客户端只访问这个VIP。NLB负责在这一层实现高可用：如果其中一台ARR服务器宕机，流量会自动切换到另一台。
- 第二层（ARR层）：NLB集群中的每台ARR服务器，都配置了相同的服务器农场（Server Farm），指向实际运行业务代码的后端Web服务器（可能有多台）。ARR负责在这一层实现智能负载均衡和应用健康检查。
这种架构的优雅之处在于职责分离：NLB确保入口点的高可用，ARR确保应用服务的高可用与智能分发。即使某台后端Web服务器上的应用崩溃，ARR会将其标记为不健康并停止向其转发请求，同时NLB层依然保持可用，用户访问不受影响。
为了更清晰地对比两者，我们通过下表来总结其关键差异与协作关系：
