负载均衡的英文是Load Balancing，直译过来就是“负载的平衡分配”，在IT领域特指把网络请求、计算任务或流量按照某种策略分发到多台服务器上处理，从而避免单点过载、提升整体可用性与响应速度的技术。在Active Directory（活动目录，简称AD）领域，负载均衡同样无处不在：客户端需要找到可用的域控制器、DNS解析需要在多台服务器之间分摊、验证请求需要合理调度。这篇文章就把这些概念和技术方案掰开揉碎讲清楚。
负载均衡的英文与基本概念
Load Balancing是负载均衡的标准英文写法，负责执行这项工作的设备或软件称为Load Balancer（负载均衡器）。在一些厂商文档里，你还会看到SLB（Server Load Balancing）这样的缩写，指的是服务器负载均衡，本质上是同一类技术在不同语境下的叫法。
负载均衡的核心目标有三个：一是高可用，当某台服务器宕机时流量能自动切换到其他节点；二是高性能，通过并行处理提升整体吞吐量；三是可伸缩，可以根据业务压力动态增加或减少后端节点。常见的调度算法包括轮询（Round Robin）、加权轮询（Weighted Round Robin）、最少连接（Least Connections）、源地址哈希（Source IP Hash）等，不同的算法适合不同的业务形态，比如长连接业务更适合最少连接算法，而需要会话保持的场景则常用源地址哈希。
负载均衡从实现层面可以分为两类：软件负载均衡，例如Nginx、HAProxy、LVS以及Windows自带的NLB；硬件负载均衡，例如F5 BIG-IP、A10等专用设备。硬件方案性能强、功能全但价格昂贵，软件方案灵活便宜，是当前互联网公司的主流选择。
AD领域中常见的负载均衡技术
Active Directory是微软的目录服务，域中的每台域控制器（Domain Controller，DC）都承担着身份验证、目录查询、组策略下发等工作。当企业规模变大、域控制器数量增多时，如何让客户端的请求均匀落到各台DC上，就成了必须解决的问题。AD领域主要有以下几种负载均衡手段。
1. SRV记录与DC Locator机制
AD底层深度依赖DNS，域控制器会在DNS中注册一系列SRV记录，例如_ldap._tcp.domain.com和_kerberos._tcp.domain.com。客户端登录时通过DC Locator过程查找这些SRV记录，系统会随机打乱返回的记录顺序，从而在多台DC之间实现事实上的负载分担。这种方式不需要额外部署任何设备，是AD自带的“天生”负载均衡，但它的粒度较粗，无法感知各台DC的实际负载状况。
2. DNS轮询（Round Robin）
DNS轮询是最简单的负载均衡方式，DNS服务器对同一个域名返回多个A记录，并按顺序轮换排列。例如：
dc01.corp.com A 192.168.1.10 dc02.corp.com A 192.168.1.11 dc03.corp.com A 192.168.1.12
客户端每次解析拿到的IP顺序不同，请求就会被分散到不同服务器。它的优点是零成本、配置简单；缺点也很明显：无法检测服务器健康状态，如果某台DC宕机，DNS依然可能把请求分过去，导致部分用户访问失败。因此生产环境中通常要配合健康检查或手动摘除故障记录。
3. NLB网络负载均衡集群
Windows Server自带的Network Load Balancing（NLB）是一种软件负载均衡集群技术，最多支持32台节点。它通过虚拟IP（VIP）对外提供服务，集群内所有节点共同响应ARP请求，再根据各自的主机优先级和端口规则决定由谁处理特定流量。NLB常用于IIS Web farm、终端服务等场景。需要注意的是，微软官方并不建议把域控制器本身加入NLB集群，因为DC的数据库复制和登录验证对网络行为有特殊要求，NLB的流量分摊机制可能与AD复制产生冲突。
4. 硬件或软件负载均衡器代理
对于LDAP查询、AD CS证书服务、ADFS联合身份验证这类对外的AD相关服务，企业经常在前面架设F5、Nginx或HAProxy做统一入口。以HAProxy代理多台域控制器的LDAP端口为例：
listen ad-ldap
bind *:389
mode tcp
balance roundrobin
server dc01 192.168.1.10:389 check
server dc02 192.168.1.11:389 check
server dc03 192.168.1.12:389 check
这种方案的优势是具备健康检查能力，能自动剔除故障节点，还支持会话保持和更精细的调度策略。ADFS场景下尤其推荐这样做，因为ADFS的令牌签发必须由同一台服务器完成完整流程，负载均衡器配置源地址亲和性可以避免验证异常。
部署AD负载均衡的常见问题与注意事项
首先是Kerberos协议的兼容问题。Kerberos对时间戳和服务主体名（SPN）非常敏感，如果通过负载均衡器访问AD服务，必须确保SPN注册在正确的账号上，并且各节点时间同步误差不超过5分钟，否则会出现验证失败。其次，不要对域控制器之间的复制流量做负载均衡，AD复制有自己独立的拓扑和连接协议，人工干预反而容易出问题。
另一个常见坑是“负载不均”。有的管理员发现某台DC总是承受大量请求，这通常是因为客户端的DC Locator缓存了结果，或者某些应用硬编码指向了特定DC。排查时可以用nltest /dsgetdc:domain.com命令查看客户端实际定位到哪台DC，用nltest /statistics查看DC端的请求统计。此外，子网与站点的映射关系如果配置不当，也会导致跨站点访问，形成隐性负载倾斜。
最后提醒几点：优先利用AD原生的多DC机制分担负载，只有在有明确需求时才引入额外负载均衡器；对面向互联网的ADFS、AD CS等服务务必配置健康检查；定期监控各DC的CPU、内存和LSASS进程负载；变更负载均衡策略前先在测试环境验证，避免影响全域登录。理解了Load Balancing的本质与AD的目录服务特性，两者结合使用才能既稳又快。
负载均衡Load BalancingAD负载均衡修改时间：2026-09-04 18:52:38